Known engine bug. The correct fix for us would be to maintain an LRU list of resources and move unused resources out of VRAM on the fly, but it's far from trivial if we don't want to cripple CPU-bound performance, and not a particularly high priority right now.
This gets especially complicated on GPUs that have multiple VRAM memory types (especially Intel).
I don't know if this has anything to do with, but I noticed on a couple of unity games that using the 32bit dlls, despite the app being 64bit, actually makes the game more stable and sometimes a bit more fps.
Yeah that's because you're not actually using dxvk when derping 32-bit dlls into a 64-bit game....
Yeah that's because you're not actually using dxvk when derping 32-bit dlls into a 64-bit game....
Logs, cache are being created. FPS hud working + the fact that when games run with dxvk it acts more like borderless than fullscreen. I think it is unity related as some 64bit games are even affected by 4gb patch when they shouldn't. More I don't know, I'm a tinkerer not a dev.
Well I have no idea what you're doing then, but 32-bit DLLs will simply not get loaded at all by 64-bit executables and vice versa.
@mkrsym1 Try giving this build a test https://github.com/doitsujin/dxvk/actions/runs/15523148840
@mkrsym1 Try giving this build a test https://github.com/doitsujin/dxvk/actions/runs/15523148840
@Blisto91
The issue appears to be resolved on this build. However, there is now a huge amount of resources accumulating in system memory. They do not affect performance so I guess it's fine, but it feels like the game's allocator is behaving better without the eviction mechanism, somehow (well, not like it worked great, but it did at least try to free things).
Eviction is entirely transparent to the game, and the resources would spill over into system memory before as well, it would just happen at a driver level.
The whole point of this branch is to do this explicitly inside DXVK so that we have control over keeping actively used resources in VRAM.
Nothing extracted yet.
I have encountered a peculiar effect in some Unity games. Initially, the game starts with only the required resources in device memory, but when they become unneeded, it does not free them immediately. Instead, it tries to keep VRAM as full as possible - only unloading resources when it has to make room for new ones. That usually results in a no longer needed resource being replaced by a now-needed one, however, if the resources it freed to make room were in different chunks, DXVK may not be able to suballocate for the replacement, and will put it into fallback system memory instead. Over time, a large amount of such failed replacements accumulates (as the game fills the gaps in device memory left by the "failed replacement" first, only starting to free resources again once it has been filled), and the game slows down to a crawl. On my 3GB GTX 1060, this can happen as fast as in 15 minutes, although it highly depends on how many new resources the game tried to put into device memory.
I tried mitigating this by forcing a defragmentation if suballocation fails, and then retrying again. Not sure if I actually succeeded in doing this, but the change has resulted in a massive improvement nonetheless: in the small amount of testing i did, the game is much less prone to slowing down, remaining playable even after multiple hours. The issue is however still not eliminated completely, and "failed replacements" still seem to occur at times. See patch (not opening a PR because this is just for testing, I'm not implying this code should go into upstream).
I am still not sure if it's a good idea, whether it can cause issues elsewhere, or if it does what I think it does. I lack any experience with Direct3D or DXVK internals. But at least it does seem to mitigate the issue well enough for me to keep using it on a local fork.
Maybe someone has a better idea of what's going on, or perhaps a better way to solve it?