[d3d11] Jedi Fallen Order: fps has a massive drop after acessing the menu

[ranplayer]

If you access the menu during gameplay and then return to action, there is a massive fps drop (even if you don't change anything). Everything slows down. I'm on Nvidia, not sure if the issue happens on AMD as well.

This issue also happens if you change any graphics property (before start playing or during gameplay).

Software information

• Name: Star Wars: Jedi Fallen Order
• Settings: everything on medium (cosmetic effects (like filmgrain) disabled)

System information

• GPU: GTX 970 4Gb
• 16Gb RAM
• Core i15 4690s (3.2 Ghz -> 3.9 Ghz)
• Driver: 510.54
• Wine version: Proton 7.0-1
• DXVK version: 1.9.4
• Kernel: 5.15 (futex2 patched)
• O.S: Manjaro

Apitrace file(s)

api trace

Log files

• d3d11_dxgi_logs.tar.gz

Please, let me know if any more information or testing is required.

[K0bin]

You're most likely just running out of VRAM.

[ranplayer]

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.

[Kron4ek]

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.

[doitsujin]

The trace doesn't work since DXGI wasn't traced.

It's more likely that the game probably recreates a bunch of render targets after leaving the menu, and since your VRAM is already full, those will end up in system memory.

I can confirm that the same issue happens on AMD

Please specify your GPU and how much memory it has.

[Kron4ek]

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.

[ranplayer]

@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 ?

[ranplayer]

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

[ranplayer]

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.

[doitsujin]

Sounds like VRAM being full then. Note that on Nvidia, any background app that consumes VRAM significantly reduces the amount of memory that's available to Vulkan applictions, including DXVK. You should be able to see high PCI-E bandwidth usage in nvidia-settings when this happens.

[ranplayer]

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

[doitsujin]

And what about PCIe bandwidth?

[ranplayer]

5% used only

[K0bin]

Could also be related to the 0.5GB of lower bandwidth memory that the GTX 970 has IIRC.

[Blisto91]

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

Desktop stats


Main menu

 

Loaded the game

 

Went into the menu

 

Exit menu into 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).

[Blisto91]

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.

[kakra]

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.

[Blisto91]

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.

[kakra]

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).

[kodatarule]

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).

[erdies]

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?

[ammgws]

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

[erdies]

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?

[ammgws]

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

[kakra]

@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.

[Hadrianneue]

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)