The Division 2 500ms frametime spikes

[nutta-git]

Hi, I am feeling high frame spikes (500ms) when using vkd3d with The Division2 This usually happens in the using the menu or inside buildings. I cant reproduce this issue with dxvk.

Game: The Division 2 In game settings: lowest settings possible or off expect the following: render resloution: 100 sharpening: 10 anisotropic filtering: 4x projected texture resolution: 512 terrain quality: high anti-alising: ultra

Environment: OS: Archlinux, 6.8.2-zen2-1.1-zen CPU: 12700k GPU: 6600xt WM: Hyprland PKG: Flatpak Steam using this build for mangohud WINE: Proton experimental-9.0-2024038c

I am not using REBAR, VRR, tearing or directscanout.

steam-2221490.zip

https://github.com/HansKristian-Work/vkd3d-proton/assets/59726608/e5afd408-b224-4f2c-a631-1192167cc9be

[nutta-git]

In this clip:

https://github.com/HansKristian-Work/vkd3d-proton/assets/59726608/4528f841-432b-4487-8040-b822490d953d

I am not sure which of these setting (tearing,rebar and directscanout) were turned on. but I don't think it matters. It just highlights how bad the stuttering can get.

[nutta-git]

This issue seems similar to what I am facing, https://github.com/ValveSoftware/gamescope/issues/1205#issuecomment-2017835136
Here is a bug report in amdgpu driver https://gitlab.freedesktop.org/drm/amd/-/issues/2372 I noticed [drm] Fence fallback timer expired on ring comp_1.^.^ being spammed in journalctl when it stutters

^ marks different numbers

[pingubot]

I am facing the same frametime spikes with the same error message in dmesg. In addition to Div2 it also happens very prominent for me in Dirt 5.

[EmptyVisual]

Unsure if this is even a mesa or vkd3d regression at this point, since this is the only game it happens to. Run Division 2 in DX12 mode (make sure DX12 renderer is enabled in the in-game settings) and then watch the '[drm] Fence fallback timer expired on ring comp_1.' log spam.

No game crash though, but it definitely causes some weird hang behaviour ingame where, within a few minutes of gameplay, your character freezes momentarily while traversing around the open world. Doesnt happen if you switch the DX12 renderer off and go back to DX11.

6900 XT

[pingubot]

Unsure if this is even a mesa or vkd3d regression at this point, since this is the only game it happens to. Run Division 2 in DX12 mode (make sure DX12 renderer is enabled in the in-game settings) and then watch the '[drm] Fence fallback timer expired on ring comp_1.' log spam.

No game crash though, but it definitely causes some weird hang behaviour ingame where, within a few minutes of gameplay, your character freezes momentarily while traversing around the open world. Doesnt happen if you switch the DX12 renderer off and go back to DX11.

6900 XT

The game also does not crash for me nor do i get a gpu hang, its "only" those freezes which cause an issue. Division 2 sadly is not the only affected game, for me it also happens in Dirt 5 and Avatar. I think we also can rule out mesa/radv, as the same issue is happening when using amdvlk in Dirt 5.

[nutta-git]

I think I found a potential fix, With wsi: Implement explicit sync for Wayland merged. I decided to compile mesa-git with steam-runtime, and xorg-xwayland-explicit-sync-git. I am also using udev rule found here @Myned writes: START QUOTE As far as I know, the recommended method to change hardware attributes is through udev, not systemd. This allows the attributes to be applied with each initialization of the hardware. I based the below on the Arch Wiki's udev rule but using power profiles instead of performance levels:

/etc/udev/rules.d/30-amdgpu.rules

KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="manual", ATTR{device/pp_power_profile_mode}="1"

The 1 corresponds to the PROFILE_INDEX listed by cat /sys/class/drm/card0/device/pp_power_profile_mode So if you still get issues with 3D_FULL_SCREEN, I've had success with using the COMPUTE mode instead, which is index 5 If you have multiple cards, you may need to change card0 to another in ls /dev/dri You can hot-reload the rule by triggering a udev change event with sudo udevadm trigger --name-match=/dev/dri/card0. Otherwise, a reboot is required. Check if it applied properly with cat /sys/class/drm/card0/device/pp_power_profile_mode | grep '*', which should list the current profile (or, as mentioned above, look for the asterisk without grep):

1 3D_FULL_SCREEN*: END QUOTE For me instead of 1, i am using 5 (COMPUTE).

I hope someone test this and see if this is valid.

[pingubot]

I think I found a potential fix, With wsi: Implement explicit sync for Wayland merged. I decided to compile mesa-git with steam-runtime, and xorg-xwayland-explicit-sync-git. I am also using udev rule found here @Myned writes: START QUOTE As far as I know, the recommended method to change hardware attributes is through udev, not systemd. This allows the attributes to be applied with each initialization of the hardware. I based the below on the Arch Wiki's udev rule but using power profiles instead of performance levels:

/etc/udev/rules.d/30-amdgpu.rules

KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="manual", ATTR{device/pp_power_profile_mode}="1"

The 1 corresponds to the PROFILE_INDEX listed by cat /sys/class/drm/card0/device/pp_power_profile_mode So if you still get issues with 3D_FULL_SCREEN, I've had success with using the COMPUTE mode instead, which is index 5 If you have multiple cards, you may need to change card0 to another in ls /dev/dri You can hot-reload the rule by triggering a udev change event with sudo udevadm trigger --name-match=/dev/dri/card0. Otherwise, a reboot is required. Check if it applied properly with cat /sys/class/drm/card0/device/pp_power_profile_mode | grep '*', which should list the current profile (or, as mentioned above, look for the asterisk without grep):

1 3D_FULL_SCREEN*: END QUOTE For me instead of 1, i am using 5 (COMPUTE).

I hope someone test this and see if this is valid.

Hi,

i tested with

pp_power_profile_mode set to 3D_FULL_SCREEN (this is my default setting for gaming) and also with pp_power_profile_mode set to COMPUTE*: and it does not help here with my 6900xt.

I haven't tested the explicit sync things which you mentioned. Would be good to know which of your changes actually fixed the issue for you ?

Br, Pingubot

[mbriar]

Pretty sure the explicit sync stuff does nothing for games without also merging https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27226 (and even then it's doubtful that it would help with these issues, I think)

[nutta-git]

@pingubot I removed the udev rule and saw no change in performance, so its just the explicit stuff (can you try it out and see if it helps). I am using tkg's mesa-git.

@mbriar I am not sure, but that merge request is for x11. I am running on hyprland with xwayland.

[pingubot]

Have you tested long enough btw ? I had the case were I didn't have a spike for 10 mins and then it started to happen.

In addition if you did not patch X11 for explicit sync, can you try if you see the issue still there ? ( For me the issue is the same on wayland/xwayland and X11)

Thx !

duevo @.***> schrieb am Mi., 3. Apr. 2024, 18:32:

@pingubot https://github.com/pingubot I removed the udev rule and saw no change in performance, so its just the explicit stuff.

@mbriar https://github.com/mbriar I am not sure, but that merge request is for x11. I am running on hyprland with xwayland.

— Reply to this email directly, view it on GitHub https://github.com/HansKristian-Work/vkd3d-proton/issues/1956#issuecomment-2035068536, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPVS43DHQBACQFUIXRZYFLY3QVIBAVCNFSM6AAAAABFPKM7AOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVGA3DQNJTGY . You are receiving this because you were mentioned.Message ID: @.***>

[mbriar]

I am not sure, but that merge request is for x11. I am running on hyprland with xwayland.

shouldn't matter, Mesa will still use the x11 wsi on xwayland. I don't think it should affect game perf anyways.

[nutta-git]

@pingubot
I played for more than 3 hours yesterday and I don't think i recall getting a stutter. I didn't patch x11 for explicit sync, i wouldn't know how too :(

@mbriar ¯_(ツ)_/¯, All i know it works for me, unless someone tests it other than me I wouldn't know if this is a vaild fix or if i got lucky.

[pingubot]

You don't need to do it for x11, just play and X11 and see if it still happens there compared to your Wayland setup now.

duevo @.***> schrieb am Mi., 3. Apr. 2024, 18:50:

@pingubot https://github.com/pingubot I played for more than 3 hours yesterday and I don't think i recall getting a stutter. I didn't patch x11 for explicit sync, i wouldn't know how too :(

@mbriar https://github.com/mbriar ¯(ツ)/¯, All i know it works for me, unless someone tests it other than me I wouldn't know if this is a vaild fix or if i got lucky.

— Reply to this email directly, view it on GitHub https://github.com/HansKristian-Work/vkd3d-proton/issues/1956#issuecomment-2035102969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPVS44IZ67L7YETECM4O4DY3QXPDAVCNFSM6AAAAABFPKM7AOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVGEYDEOJWHE . You are receiving this because you were mentioned.Message ID: @.***>

[nutta-git]

@pingubot I really don't want to go back to x11, its going to a pain to set up and manage .config for kde. Please try mesa-git with xorg-xwayland-explicit-sync-git, If you are not on arch, I can see it being a pain to set up.

[pingubot]

@pingubot I really don't want to go back to x11, its going to a pain to set up and manage .config for kde. Please try mesa-git with xorg-xwayland-explicit-sync-git, If you are not on arch, I can see it being a pain to set up.

I can easly use mesa-git but for the xwayland part i will wait for an up2date package, i do not use aur.

[mbriar]

(besides the compositor also needing to support linux-drm-syncobj-v1 for explicit sync to work, so you'd need to use git versions of your wayland compositor as well, another reason to believe explicit sync did exactly nothing here)

[nutta-git]

I don't have time today, but I will do some testing tmr and report back.

Conditions are: mesa + xwayland (the default packages on arch) mesa + xwayland-explicit mesa-git + xwayland mesa-git + xwayland-explict

Area:
Submit level 1-10.
I will play 30 minutes in each one and report if there was a 500 ms spike, 500 ms spikes, or continuous 500 ms spikes.

[nutta-git]

Okay I did some tests here are the results. Test 1 lasted 26+ minutes Test 2 lasted 11+ minutes I have the footage for each run, if anyone wants it I can provide a magnet link.

For each test, I ran this script to wipe away any caches.

#! /usr/bin/bash 

rm -rf   ~/.cache/mesa_shader_cache  
rm   ~/.cache/radv_* 
rm       ~/.local/share/Steam/steamapps/common/Tom\ Clancy\'s\ The\ Division\ 2/vkd3d-proton.cache* 
rm       ~/.local/share/Steam/steamapps/common/Tom\ Clancy\'s\ The\ Division\ 2/TheDivision2.dxvk-cache  

From the test results, with the default packages (mesa + xwayland) the issue seems to appear; however, when using the default packages with the udev rule (found above) seems to have fixed the issue. This suggest the issue was not fixed by mesa-git and xwayland-explicit-sync-git, but the udev rule. Special thanks to AMD for prioritizing this issue for the past 3 years.

@mbriar I am sorry, I made you doubt yourself, but you were right.

This doesn't seem like a vkd3d issue, so I am going to close this.