The problematic buffer is ~300kb. It doesn't crash anymore because DXVK limits the amount of staging memory that can be used for buffer uploads but performance is atrocious with 30+ gpu syncs per frame taking a combined 30+ms.
Unfortunately the game uses SizeToLock = 0, so we end up uploading the entire 300kb buffer over and over and over again.
The solution to this would be to only upload the parts of dynamic sysmem buffers that are used for drawing.
Nine does this now:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451
https://github.com/K0bin/dxvk/tree/dynamic-smol-uploads fixes the issue but I'm not sure if I want to land that.
Nothing extracted yet.
Flammable Freddy, a game made by a Youtuber I regularly watch, runs very poorly with DXVK and runs out of address space. The game is made with a game engine called Clickteam Fusion, I assume other games using it have the same issue.
The problem is that the game heavily relies on D3DLOCK_NOOVERWRITE when uploading data before every draw. The buffer is a vertex buffer in the systemmem pool with the usages D3DUSAGE_WRITEONLY | D3DUSAGE_DYNAMIC. DXVK ignores D3DLOCK_NOOVERWRITE for everything that isn't in D3DPOOL_DEFAULT, so we do a ton of copying and eventually run out of address space.
The game itself isn't really important but it highlights that we still havent gotten the D3DLOCK flags right.
Software information
Flammable Freddy
System information
Log files