[Metro Exodus] GPU and CPU underutilized when looking at different scenes

vkd3dclosed

HansKristian-Work/vkd3d-proton#2550 · opened 2025-07-23 by sim590 · updated 2026-04-19 · 10 comments · github

Ssim590 2025-07-23 github

When looking at different scenes, the CPU and GPU start to be underutilized and performance degrade. Here is a video demonstrating the issue: https://youtu.be/_n_eYGZaDSk. I could not film during the fight that just preceded this scene, but during this fight, things were even worst. I'm looking for ideas as to why this could happen. May be I'm at fault...

Software information

Game: Metro Exodus

Steam flags used:

env PROTON_LOG=1 VKD3D_CONFIG=dxr11 DXVK_ASYNC=1 VKD3D_FEATURE_LEVEL=12_2 gamemoderun mangohud %command%

My gamemode.ini config. But the same happens if I don't launch the game with gamemoderun, so that must not be it.
I also use these response time tweaks suggested by the Arch Wiki.

System information

GPU: AMD Radeon RX 7800 XT
Driver: mesa (version 25.3.0_devel.208904.d59c22b6e1a.d41d8cd-1)
Wine version: GE-Proton10-10
VKD3D-Proton version: 2.14.1
Distribution: Archlinux

Mesa/Vulkan related packages installed

local/adriconf 2.7.2-1
    GUI tool to configure Mesa drivers by setting options and writing them to the standard drirc file
local/amd-vulkan-prefixes 2-1
    Select needed vulkan implementation with vk_radv, vk_amdvlk or vk_pro prefix
local/glu 9.0.3-2
    Mesa OpenGL utility library
local/lib32-glu 9.0.3-2
    Mesa OpenGL utility library (32 bits)
local/lib32-mesa 1:25.1.5-1
    Open-source OpenGL drivers - 32-bit
local/lib32-vkd3d 1.16-1
    Direct3D 12 to Vulkan translation library By WineHQ
local/lib32-vulkan-icd-loader 1.4.313.0-1
    Vulkan Installable Client Driver (ICD) Loader (32-bit)
local/lib32-vulkan-radeon 1:25.1.5-1
    Open-source Vulkan driver for AMD GPUs - 32-bit
local/mangohud 0.8.1-1
    A Vulkan overlay layer for monitoring FPS, temperatures, CPU/GPU load and more.
local/mesa 1:25.1.5-1
    Open-source OpenGL drivers
local/mesa-demos 9.0.0-7
    Mesa demos
local/mesa-utils 9.0.0-7
    Essential Mesa utilities
local/nvidia-utils 575.64.03-1
    NVIDIA drivers utilities
local/obs-vkcapture-git r322.40fbe24-1
    OBS Linux Vulkan/OpenGL game capture
local/qt6-shadertools 6.9.1-1 (qt6)
    Provides functionality for the shader pipeline that allows Qt Quick to operate on Vulkan, Metal, and Direct3D, in addition to OpenGL
local/spirv-tools 1:1.4.313.0-1 (vulkan-devel)
    API and commands for processing SPIR-V modules
local/vkd3d 1.16-1
    Direct3D 12 to Vulkan translation library By WineHQ
local/vkmark 1:2025.01-2
    Vulkan benchmark
local/vulkan-headers 1:1.4.313.0-1 (vulkan-devel)
    Vulkan header files and API registry
local/vulkan-icd-loader 1.4.313.0-1 (vulkan-devel)
    Vulkan Installable Client Driver (ICD) Loader
local/vulkan-radeon 1:25.1.5-1
    Open-source Vulkan driver for AMD GPUs
local/vulkan-tools 1.4.313.0-1 (vulkan-devel)
    Vulkan tools and utilities

Log files

steam-1449560.log

Ssim590 2025-07-23 github

I removed my "response time tweaks" file and it didn't change anything.

Nnokia8801 2025-07-25 github

This could also be Fsync related. I had very similar stuff in some other games which were completely fixed by using NTsync instead. When I looked at certain stuff, FPS would tank and GPU would be at half power and half MHz. But it was fixed by NTsync.

I see you're using GE-Proton10-10 and kernel 6.15.6 but you're still using Fsync instead of NTsync? You should load the ntsync module with sudo modprobe ntsync and add it to mkinitcpio.conf inside MODULES=()so it automatically loads at boot in the future. GE-Proton10-10 automatically uses NTsync, so you don't have to do anything else.

Worth a try.

Ssim590 2025-07-26 github

I tried it. I alternated multiple times with and without NTSync. I wanted to believe it could help. I have not found a particular spot where I saw the same drastic performance loss, but I found spots where I had some drops and with both NTSync and FSync, I had the same behaviour. Like here:

I'll need to get back to the exact same scene to be sure, but I'll have to finish the campaign first because I don't have a save where I reproduced the bug.

KK0bin 2025-07-26 github

Is there any chance you could test this on Windows on the same system?

It's possible that it's just CPU bound combined with threads waiting for each other.

Also, because it's a pet peeve of me: Don't just use random environment variables you read somewhere.

VKD3D_CONFIG=dxr11 That gets enabled by default on compatible hardware.

DXVK_ASYNC=1 That does nothing in D3D12 games.

VKD3D_FEATURE_LEVEL=12_2 It'll also pick the highest feature level automatically on compatible hardware. RDNA 3 should get 12_2 automatically unless I'm forgetting something.

Ssim590 2025-07-26 github

I just went back to the exact same scene this morning and I didn't have the same experience now:

Sometimes, the GPU usage would go down to 80-85%, but go back up. That was different from what I experienced the other day. I don't know why. Seems like it was the same behaviour

Is there any chance you could test this on Windows on the same system?

It's possible that it's just CPU bound combined with threads waiting for each other.

I could try to do that soon. I actually get a similar behaviour in Gray Zone Warfare which I have reported on Proton's github ticket for the game. I was wondering if the discussion about this would be more fruitfull on a ticket over here at vkd3d-proton since I'm talking performance. I was thinking to try the game on my Windows partition, so may be I could report on that here? Or should I stick to the same game for this ticket and open another one for GZW?

Also, because it's a pet peeve of me: Don't just use random environment variables you read somewhere.

VKD3D_CONFIG=dxr11 That gets enabled by default on compatible hardware.

DXVK_ASYNC=1 That does nothing in D3D12 games.

VKD3D_FEATURE_LEVEL=12_2 It'll also pick the highest feature level automatically on compatible hardware. RDNA 3 should get 12_2 automatically unless I'm forgetting something.

Alright, I'll take note of this. You know, sometimes, when you don't know what's going on, you just get desperate and try stuff.

Ssim590 2025-07-27 github

I did a test with GZW and I uploaded this video https://www.youtube.com/watch?v=gla8TSOIToE where we can see both performance of Windows and Linux.

Observations

Windows
- GPU usage goes down at a lowest of 93%
- CPU usage is around 40-45%
Linux
- GPU usage does down at a lowest of 83%
- CPU usage is around 50-60%

This is not as drastic as what I first reported on this ticket. However, I'm curious though why I get 20FPS less on Linux vs. Windows.

TTk-Glitch 2025-08-28 github

On my 32 threads CPU, I fixed this on the enhanced edition (I assume behavior might be similar on the non EE version) by using VKD3D_CONFIG=no_upload_hvv and WINE_CPU_TOPOLOGY=8:0-7. More than 8 threads and the framerate dropped heavily but no_upload_hvv seemingly was needed too as only limiting the game to 8 threads didn't help too much (rebar enabled at all times, so we can assume this wouldn't affect a system without rebar or with it disabled). no_upload_hvv also didn't fix it by itself, and only both gave "expected" performance.
Tested on both a 7800XT and a 9070XT with similar results.
Hopefully you'll be able to reproduce those gains on your end.

Also, just in case, make sure to disable PROTON_LOG=1 when actually playing to prevent additional unwanted overhead.

Ssim590 2026-03-02 github

@Tk-Glitch: thanks for that answer! I tried it and it made a world of difference on Gray Zone Warfare. I can't say for Metro Exodus, but I guess it would have the same effect. Now, my GPU is used at 98%!

By the way, I'm not sure if the setting WINE_CPU_TOPOLOGY=8:0-7 did what it should have done because when I was looking at my CPUs being used, I saw all of them being used at the same level. I would have expected this setting to make it so cores 0-7 would have been used more than the others, but it was not the case.

Also, of course enabling resizable bar in the BIOS was crucial. I think that I tried your suggestion back a couple months ago, but I didn't turn on resizable bar then, so I didn't see a difference. That's why.

Ssim590 2026-03-03 github

I guess I could close this issue since using rebar with the mentioned DXVK flags seems to fix the issue.

Ssim590 2026-04-19 github

Update: force_host_cached resolves GPU underutilization in Shadow of the Tomb Raider (DX12)

I'm seeing the same GPU underutilization pattern in Shadow of the Tomb Raider (DX12, VKD3D-Proton) on my RX 7800 XT (RADV NAVI32):

Without force_host_cached: GPU usage sits at ~50-55%, FPS drops to ~44-50 in certain scenes. CPU-bound despite low GPU load. Lowering graphics settings has minimal impact.
With VKD3D_CONFIG=no_upload_hvv,force_host_cached: GPU usage jumps to 80-100%, FPS improves to ~60. The CPU bottleneck is resolved.

Claude Opus 4.6's interpretation: This suggests the default memory allocation path in VKD3D-Proton creates a CPU-side bottleneck on NAVI32, where the CPU stalls on memory transfers to device-local VRAM. Forcing host-cached allocations makes CPU writes more efficient (going through CPU cache), which unblocks the GPU submission pipeline.

This is the same pattern I reported with Metro Exodus and Gray Zone Warfare — GPU starved because the CPU can't feed it fast enough through the default memory path.