Open T-X opened 1 year ago
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:
~/.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/
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.
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:
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:
System information: