So the game allocates a heavy resource when the menu is accessed and keeps it on VRAM instead of clean it ? Because if you just play without accessing the menu, the issue doesn't happen.

I can confirm that the same issue happens on AMD, opening the menu leads to a severe performance drop. Not sure if it's a DXVK or a game bug.

I found out that changing any of the graphics settings (texture quality, shadows quality or anything else, doesn't matter) restores the performance, temporarily. Opening the menu next time drops the performance again, but changing the graphics settings restores it again. So changing the graphics settings every time is sort of a workaround.

AMD RX 560, 4 GB VRAM.

To be clear, i played the game a few months ago with Mesa 21.3.0 and DXVK 1.9.2. I don't have it installed right now, so can't test it again with newer Mesa and DXVK versions.

@doitsujin I've followed the project's wiki to generate the API trace (added d3d11.dll, dxgi.dlland dxgitrace.dll to the executable folder). Is there any missing DLL ? Should I try a different method ?

Guys, it doesn't seem to be a VRAM issue. I've captured some pictures from the heap and RAM before and after accessing the menu. Perhaps a Wine or game bug ?

Before:

• Heap:
  
• RAM
  

After:

• Heap
  
• RAM
  

I've also tried changing the device memory available (dxgi.maxDeviceMemory = 1024) and the issue vanishes, but the textures loaded are terrible. With a higher value (2560) the issue remains.

nvidia-settings displays only 70% of the dedicated memory used (same as DXVK's hud)

5% used only

Some tests from my system. R9 380 4GB, mesa 22.0, proton 7.0-1, medium settings 1080p.
Note that origin which steam boots uses 300 - 400MB vram on it's own before the game even gets started.

In order of appearence:
Desktop GPU stats pre launch
Stats from when i get into the main menu.
Stats for when i load into the actual game.
Stats for when i enter the menu from within the game.
Stats for when i exit the menu and get back in game

A little quirk is that you can alter the fps slightly each time you go in and out of the menu. Sometimes i drops even more and sometimes it rises a bit again (tho not to original levels).

Doesn't happen if i launch the game in 1024x768. Note the resolution selection is a bit weird and i had to click the fullscreen button for it take effect.
The escape menu still takes my GPU to 100%. It drops to around 60% when back in game.

Would be nice to trim origins vram usage a bit tho hehe.

Would be nice to trim origins vram usage a bit tho hehe.

It's a Chrome-based, GPU accelerated app, as far as I know. It will use VRAM for surface buffers. But maybe wine-proton could be tweaked to pass an option to disable GPU acceleration for Chrome processes, similar to how Proton disables Chrome sandboxing by injecting command line arguments.

I see.

It goes through dxvk if that matters since the hud also shows up in the corner of it's interface when it shortly pops up.
I think i tried disabling GPU acceleration in it's own settings too see if it helped, but i don't think i got that working properly.

To me it looks like an unlucky combination of bad vram memory budget management of the game and the chunk allocator. I now tried dxgi.maxDeviceMemory = 4096 in multiple games which show similar issues, and the problems are gone.

I have a 6 GB card, accounting for Xorg usage (around 0.8 - 1.5 GB varying) and for chunk allocator slack and some buffer, I subtracted 2 GB from my 6 GB VRAM and are left with 4096 MB. YMMV, depending on your system. Minimizing browsers and other VRAM-hungry programs helps a little to keep usage under control.

I think the chunk allocator already received a very good update by de-allocating completely free chunks from the graphics driver. I think this could only further improved by a repacker which is probably very difficult to implement.

But OTOH, maybe there are some stats of how much "slack" memory is typically generated by games? This could be subtracted from the max device memory offered to the game automatically. I'm not sure if Xorg memory should also be subtracted or if games actually can handle that: I see that some games are actually aware of applications using VRAM, while others maybe ignore it and rely on DirectX behavior to swap application allocations from fast VRAM to slow sysmem?

As a start, the DXVK HUD could offer additional stats about memory chunks: How much slack memory is there (I think this value is almost there already: used vs allocated)? How many chunks have been allocated and freed in total (to see how aggressively a game allocated and freed huge amounts of data)? How many active chunks are there per chunk size (to get an idea what the optimal chunk size for a game would be)? It may give some insight on how to optimize this further and introduce tunables for chunk size or some sort of "slack memory accounting" (to subtract from the actual device memory size). This reminds me a little of btrfs and its allocation chunks, and it keeps a global reserve for times when deleting data would require an additional chunk to be allocated. Just subtracting some amount of device memory could account for a similar purpose (just that dxvk would never make use of that reserve because it could not move allocations away from it later).

Hi all,
So I tried to use the workaround(which didn't work at all for me) with dxgi.maxDeviceMemory = 6144 in a dxvk.conf but game still went the usage above 6GB went up to 6.3GB, but again it didn't go over the budget, I have nvidia-smi on the 2nd monitor and even when the framerate degrades I still have 0.7GB free in total(as my total VRAM is 8GB).
At all times the game goes up to 7.4GB of total VRAM usage(same if I lower the texture setting to high which can't reproduce the problem at least to my testing). There is no indication of this going over the budget(as some other games which cause this issue such as gears 5 with vkd3d).

I can confirm exactly the same issue here on Gentoo Linux / Proton experimental / Geforce GTX1060 + Ryzen 9 5900X. Are there any other known workarounds? I do not find a file named "dxvk.conf" on my system. Is this windows specific?

Create it yourself then change the game launch parameters to look like this:
DXVK_CONFIG_FILE=/path/to/your/file/dxvk-lowmem.conf %command%

I did exactly that and the result was, that there is still a fps drop but less severe than before. My video card has 6Gb of memory. Might it be possible that I need to use a different value than 6144?

I have 8GB of VRAM and my file has it set to 4096. Don't remember if it actually fully solved it or not...

@erdies Yes, try 4096 because your desktop will use around 2 GB - at least with compositing enabled and having a browser running. As a result, the game will probably load higher quality textures slower but it should work much better. Especially in this game, it CAN still result in occasional low fps when accessing the menu.

There are a few games (including this) which still go easily past this limit because the DXVK limit only affects the REPORTED memory for the game. DXVK allocates memory in chunks of different types, and only frees memory in size of the same chunks (the game doesn't know about this). If the game has unusual allocation patterns this may lead to a lot of chunks of certain types with only a few MB of render data in a chunk, and lots of MB left unused in the chunk by the game (external fragmentation), which creates the overhead you're seeing. There's nothing DXVK can do about that due to how the translation from DirectX to Vulkan has to work.

You may try fine tuning the memory limit per game by reducing the limit by the amount of memory the game overshoots. You'd need to repeat this multiple times until the limit settles at some sweet sopt, and also ensure that your environment is always around the same (read: same amount and types of windows open).

If you place such individual dxvk.conf files right in the same directory as the game EXE, it will be automatically picked up by DXVK without pointing it to it with DXVK_CONFIG_FILE. You may also place it in the base folder of the game, DXVK will look the parent folders, too, as far as I remember. If you set PROTON_LOG=1 and look in the log file, DXVK should log if it could find and read the file.

Background: In native Windows DirectX, Windows can kind of "swap out" idle application video memory (but it keeps around 512 MB for desktop compositing) when there is VRAM pressure by the game. This is integrated with the Windows kernel to synchronize memory management and relocation with games and applications. For obvious reasons, DXVK cannot do that.

If you're using NVIDIA, you can verify if your game uses memory from the system instead of video memory (after it overshot the budget) by watching the bus bandwidth usage (GPU page, PCIe Bandwidth Utilisation) in nvidia-settings. It should usually hover around 3-5% while playing the game, if it is higher, fps will slow down and that indicates that important render resources are loaded from system memory. If this happens, lower the memory limit by 256-512 MB and try again.

Some render resources are always allocated from system memory, so don't panic if DXVK says it's using some amount of system memory for the game. Games can actually ask for that because some resources are mostly used by the CPU and thus are better placed local to the CPU rather than the GPU. The important indicator is the bandwidth usage of the bus.

TL;DL: use AMDVLK or rebuild mesa with this !6833 (merged) disabled, i've made a quick patch to add an environment variable to toggle that (off by default).

So, i wanted to test it today this game again the main reason is these tests I've been doing since i have a 4GB VRAM GPU, so i remembered that this game in particular had similar issues...

So i was going to do that, I've locally build mesa and added an environment variable to disable !6833 (merged), but for whatever reason steam decided to use AMDVLK, which i didn't notice at first and when in-game these slowdowns were gone, so i thought that DXVK fixed, but it was just AMDVLK, because it handles low VRAM better than RADV.

but disabling !6833 (merged) also fixes this issue, it actually works better than AMDVLK on my tests on a RX 6500 XT (Epic settings- 1080p 60fps vsynced)

@ranplayer Hi again. Can you give this a try with latest master? Vram usage and management received a bunch of improvements in dxvk

Hi @Blisto91 , sorry for the late response. I've replaced my GTX 970 (4Gb) by a RX 6700 XT (12Gb), so unfortunately I'm not able to retest with the same hardware. For my RX this game has no such issue due to the large amount of VRAM available.

No problem.
This should hopefully work better now with all the video memory work that has gone in to 2.5.
If anyone still experiences the same issue feel free to comment here again.

So with 2.5+, we should no longer need to tweak dxgi.maxDeviceMemory?

Hopefully. But you'll have to try yourself.

So with 2.5+, we should no longer need to tweak dxgi.maxDeviceMemory?

Unfortunately it still seems to be necessary with dxvk 2.5.1, at least on my NVIDIA GPU (1060)

I'm not quite sure how to create an apitrace as I'm unable to start the game outside of Steam (getting some error about "uncooked" content when I launch the binary directly). If someone can give me a pointer how to circumvent that I can try again.

I've created some log files, in case they are helpful in some way:

1. Created using VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation DXVK_LOG_LEVEL=debug
   1.1. starwarsjedifallenorder_d3d11.log : https://gist.github.com/Staudey/191458b8a5712f128b5c5287bbfcc4ec
   1.2. starwarsjedifallenorder_dxgi.log : https://gist.github.com/Staudey/6ed42a631fcff0a9abe1dbbe6b1a8fa8
2. Created using just DXVK_LOG_LEVEL=debug
   2.1. starwarsjedifallenorder_d3d11.log : https://gist.github.com/Staudey/f92ed2dc651f627daa8273c42b3712a
   2.2. starwarsjedifallenorder_dxgi.log : https://gist.github.com/Staudey/b763790e8650fe12e8792456a284a3f7

The first run using VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation was so slow in general that I'm unsure whether it actually triggered the issue or not, but I've included the resulting logs for completeness' sake. Both represent launching the game and entering the menu a couple of times to trigger the issue.

Edit: Oops, forgot Proton log: https://gist.github.com/Staudey/413895e7beb5f32bb890fd1c6925650c
With Proton logs enabled the issue seems somewhat harder to trigger, curiously.

This is also the problem with Elite Dangerous: I cannot remove the dxgi.maxDeviceMemory hack. It's even worse than before: Without this hack, I get extremely uneven frame pacing once the VRAM budget fills. With previous versions, it just dropped to a lower fps but at least frame pacing was mostly consistent.

Should we file a new bug report? Or should this one be re-opened?

If it is a different game then open a new issue yes

@Staudey @kakra Try to give this build a go https://github.com/doitsujin/dxvk/actions/runs/15556199067

Edit: Updated link
Edit 2: Again
Edit 3: Final merged version

@Blisto91 I'm no longer playing Fallen Order but I wonder if it would fix Elite Dangerous, too?

You can try at least yes

Try to give this build a go https://github.com/doitsujin/dxvk/actions/runs/15523148840

After redownloading the game and first testing it in Steam Proton first without modifications, then with the DXVK 2.6.1 in Proton-GE, and finally with the build from that PR you linked I can confirm that the last one does indeed seem to fix the issue, while the others still show the intense frame drops.

(Note: There still seems to be a half-second or so frame drop right after exiting the menu, but then it immediately turns fluid again)

You can try at least yes

I tried this instead as a probably improved version with Elite Dangerous (not Jedi Fallen Order):
https://github.com/doitsujin/dxvk/actions/runs/15594357679

So far, it seems to work wonders. OTOH, I didn't try with a VRAM-constrained dxvk config for a long time. According to mangohud, the game goes up to 11.8 GB of VRAM on 12 GB GPU (RTX 3080 Ti). This is the point where I see increasing latency spikes, and the game now no longer can keep 60 fps in all places. But that's mostly it: It stays there and doesn't degrade further as far as I could try. I even had an OBS recording session opened - and I certainly could not run that concurrently unconstrained before. When switching between game modes (ship, on-foot, surface vehicle), VRAM usage still shortly spikes, and there are certainly still heavy lag spikes (like can be seen on Windows) - but it actually now recovers after a few seconds and VRAM usage goes down again.

I even opened and closed some windows while running the game without issues.

That's an improvement! :-)

There are still a lot more frame time spikes than without limiting VRAM (dxgi.maxDeviceMemory = 6144), and the game more easily goes below 60 fps (I limited to 60 fps via mangohud) - BUT: Improvement! \o/

Keep up the good work, we are certainly approaching the finishing line finally.

You're still going to be better off with the config to make the game think you have less VRAM so it doesn't do stupid shit to begin with.

Yep, I know. I just wanted to point out that behavior is now a lot more like on Windows - regarding the latency spikes, e.g. when switching cockpit menus, or going out of / back into the ship. So what DXVK now does, looks a lot more correct and mimics better what is happening on Windows.

There's probably still room for tuning, and I know that Elite Dangerous has its own quirky behavior that won't go away by whatever DXVK could do.

Using my config to make the game think I had less VRAM actually makes in run with less frame time spikes (almost none) compared to Windows. This is clearly a misbehavior in that particular game. But with the latest patches, DXVK seems to mimic Windows behavior good enough that Elite Dangerous' behavior no longer creates a complete performance mess when running under Linux DXVK. And I wanted to say thanks for that. :-)