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

[sim590]

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

[sim590]

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

[nokia8801]

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.

[sim590]

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.

[K0bin]

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.

[sim590]

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.

[sim590]

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.