High VRAM usage, especially in multiplayer
In the following cases the VRAM usage is high and/or overshoots for me and makes the game slower (@ ~95%+ VRAM) or even very unresponsive (@ ~190% VRAM).
The cases are either: A) high-fidelity plane models (like the F/A-18C) + detailed map (like Syria) and the high graphics presets. Or a multiplayer match (even with a low-fidelity plane (like the SU25T) + low detail map (like Caucasus) ).
Tested with an AMD Radeon RX 6650 XT, 8GB VRAM via a Thunderbolt 3 eGPU enclosure. (Tests with the internal AMD/ATI Radeon 680M iGPU, without the eGPU, still ToDo)
Previous, maybe related mentions:
- https://github.com/doitsujin/dxvk/issues/1984#issuecomment-818081517
Workarounds:
For singleplayer either reducing texture quality or closing the web browser (the latter frees around 1GB of VRAM) helps a bit. For multiplayer, neither of this is sufficient unfortunately.
Setting "dxgi.maxDeviceMemory = 4096" or "d3d9.maxAvailableMemory = 4096" + "d3d9.memoryTrackTest = True" in dxvk.conf makes no difference. (setting "dxgi.maxFrameRate = 23" works though, used to check if dxvk.conf is used)
Hardware description:
- Laptop: Lenovo Thinkpad T14s AMD Gen3
- CPU: AMD Ryzen 7 PRO 6850U with Radeon Graphics
- GPU0: 33:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev d1) - 1GB sytem RAM as VRAM
- GPU1: 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6650 XT / 6700S / 6800S] (rev c1) - 8GB VRAM
- GPU1 eGPU enclosure: Razer Core X Chroma (Thunderbolt 3 via the T14s' 40gbit/s USB4 port)
- System Memory: 32 GiB
- Display(s): Laptop's display and LG Ultra HD 27" (LG 27MU67-B)
- Type of Display Connection: HDMI
System information:
- Distro name and Version: Debian Sid
- Kernel version: Linux linus-lptp 6.1.0-6-amd64 #\1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05) x86_64 GNU/Linux
- Video driver: opensource amdgpu drive + firmware-amd-graphics 20230210-2
- Steam vs. Lutris? -> Lutris
- Wine/Proton Runner: lutris-GE-Proton7-39-x86_64
- Mesa: 22.3.6-1
- Xserver/Wayland: xserver-xorg-video-radeon 1:19.1.0-3
- Window manager: xmonad
Example screenshots, AMD Radeon RX 6650 XT @\4k, low presets, DXVK 2.1:
Multiplayer, Caucasus:

Singleplayer, F/A-18C, Caucasus, free flight:

Singleplayer, F/A-18C, Syria, free flight:

Singleplayer, Su-25T, Caucasus, free flight:

Singleplayer, Su-25T, Syria, free flight:

Initial menu:

Example screenshots, AMD Radeon RX 6650 XT @\4k, medium presets, DXVK 2.1:
Multiplayer, Caucasus:

Singleplayer, F/A-18C, Caucasus, free flight:

Singleplayer, F/A-18C, Syria, free flight:

Singleplayer, Su-25T, Caucasus, free flight:

Singleplayer, Su-25T, Syria, free flight:

Initial menu:

Example screenshots, AMD Radeon RX 6650 XT @\4k, high presets, DXVK 2.1:
Multiplayer, Caucasus:

Singleplayer, F/A-18C, Caucasus, free flight:

Singleplayer, F/A-18C, Syria, free flight:

Singleplayer, Su-25T, Caucasus, free flight:

Singleplayer, Su-25T, Syria, free flight;

Notes for those screenshots:
- Bottom left corner: Press Right-Ctrl + Pause twice to get the DCS World internal statistics (interestingly, "Video mem" always says 0.00MB?)
- Top left corner: Set "DXVK_HUD=version,api,devinfo,fps,memory,gpuload,submissions,drawcalls,compiler,samplers,descriptors,pipelines,cs" and "DXVK_LOG_LEVEL=none" in Lutris at "System options"->"Environment variables" to get the statistics in the top left corner. And enable DXVK in Lutris in "Runner options"->"Enable DXVK"
- Top right corner: In Lutris enable "System options"->"FPS counter (MangoHud)" and install MangoHud and add the following config file:
~/.config/MangoHud/MangoHud.conf
legacy_layout=false
gpu_stats
gpu_temp
gpu_load_change
gpu_load_value=50,90
gpu_load_color=FFFFFF,FFAA7F,CC0000
gpu_text=GPU
cpu_stats
cpu_temp
cpu_load_change
core_load
core_load_change
cpu_load_value=50,90
cpu_load_color=FFFFFF,FFAA7F,CC0000
cpu_color=2e97cb
cpu_text=CPU
io_color=a491d3
vram
vram_color=ad64c1
ram
ram_color=c26693
fps
engine_color=eb5b5b
gpu_color=2e9762
wine_color=eb5b5b
frame_timing=1
frametime_color=00ff00
media_player_color=ffffff
table_columns=3
background_alpha=0.4
font_size=24
background_color=020202
position=top-right
text_color=ffffff
round_corners=0
toggle_hud=Alt_R+F12
In the Matrix chat someone found this article which might be relevant for this issue: https://www.gamingonlinux.com/2023/03/amd-radv-driver-will-soon-stop-eating-ram-with-some-games/
We'll need to check if it might be related. Is DXVK using this "new Graphics Pipeline Library [...] VK_EXT_graphics_pipeline_library"? And does the according fix for Mesa linked in this article help and reduce VRAM usage for us?
Edit: On the other hand, the issue in those articles seems to be about system RAM, not GPU VRAM. So maybe/likely not related.
Maybe #27 is related to this? Although I dont have an ATI card, i am experiencing the same issues you described.
@enjoycowboy thanks for the feedback! Yes, I'm usually using multi-threading. I'll check in the next days if multiplayer performance is better for me without multi-threading.
Meanwhile, I had been playing a bit with flamegraphs and got this result:
(The SVG should be interactive. On Firefox I need to download it first and then open it via "file:///home/linus/Downloads/<file.svg> to have it interactive though.)
In this picture the ntdll.so->clock_gettime() call seems to take quite a lot of time. I'm wondering if that could have something to do with the issue.
Might be interesting to compare flamegraphs between single-threaded vs. multi-threaded.
You can create them as follows:
$ git clone https://github.com/brendangregg/FlameGraph # or download it from github
$ cd FlameGraph
# Start DCS.exe and load the scenario you want to investigate
$ perf record -F 99 -a -g -- sleep 60
$ perf script | ./stackcollapse-perf.pl > out.perf-folded
$ ./flamegraph.pl out.perf-folded > perf.svg
$ firefox perf.svg # or chrome, etc.
And maybe might be interesting to use "-C" instead of "-a" to monitor individual cores, to better see if a core gets saturated (might become a bit tricky if the kernel scheduler decides to move threads to different cores, so best try to keep the load relatively similar/constant.).
And secondly, unrelated to multiplayer, had started to investagate GTT<->VRAM swapping behaviour with the ATI/AMD open source driver:
https://github.com/GpuZelenograd/memtest_vulkan/issues/10 https://lists.freedesktop.org/archives/amd-gfx/2023-May/093007.html
Also an update of Mesa from v22 to v23 seems to have better performance when around 100% VRAM usage. Probably due to the eGPU related patch mentioned in the reply to my question on the linked amd-gfx mailing list. But at highly overallocated VRAM usage the performance still isn't good.
@enjoycowboy I updated DCS to the latest version (2.8.6.41363) and did the single-threaded vs. multi-threaded test now and also created flamegraphs. But the result seem very similar and I see no performance difference between the two. I still seem to be GPU bottlenecked:
Multithreaded:
Singlethreaded:
So maybe a different issue than yours? But still could be interesting to investigate some FlameGraphs for your case, I think. To check what might be bottlenecking in the multiplayer + multithreaded for you.