[PERF] Subpar GPU performance due to wrong power profile mode

[kivoli]

//EDIT: Changed the title to reflect findings and most likely cause

Original title: Frametimes just above selected threshold even after GPU upgrade

Describe the bug When playing around with 90Hz, 120Hz and 144Hz I noticed that the frame times in SteamVR Home at 120 Hz miss the 8.3 ms mark but stay below 11.1 ms. Yet when switching to 90 Hz they would be constantly at above 12 ms.

This is particularly peculiar since I recently upgraded from an AMD Radeon Vega 56 to a 6800 XT which should deliver more than double the performance yet it feels like nothing changed.

To Reproduce Steps to reproduce the behavior:

1. Start SteamVR Home @ 90 Hz
2. Check frame times
3. Start SteamVR Home @ 120 Hz
4. Check frame times

Expected behavior Performance should not differ, average frame times should stay the same, especially if the target frame times cannot be met.

System Information:

• Distribution: Arch
• SteamVR version: 1.20.3 [Beta]
• Steam client version: Oct 1 2021, at 21:32:23, Package versions: 1633137464
• Opted into Steam client beta?: Yes
• Graphics driver version: Mesa 21.2.3
• Gist for SteamVR System Information: https://gist.github.com/kivoli/cd74b44aae224b50ba9101931f86cc9a

Note:

• Async Reprojection has been disabled via steamvr.vrsettings due to #395.
• Turning on/off TearFree and VariableRefresh did not change the outcome (there are currently a static 60Hz and an 165Hz VRR display attached)

Performance Data:

• CPU: AMD Ryzen R7 3700X
• GPU: AMD Radeon 6800 XT
• Gist for perf top: N/A
• Link to gpuvis trace: https://github.com/kivoli/debug-file-share/raw/master/gpuvis_traces.tar.bz2

Screenshots

Additional context

The “loading room” between applications does not have any performance issues.

“Half Live: Alyx” suggests only the second-highest graphics settings after the upgrade. Also frame-times are perfect (about 4 ms) during the initial save-game loading screen when only the city map is seen but tank as soon as the maps is shown in the background. I haven’t played much yet so I can only guess what happens at level loading screens.

From what’s happening I would suspect something trying to hit the target frame rate but there’s other components that add a couple of extra milli seconds on top leading to the miss.

I scoured other issues for pointers or work arounds hence turning off VRR and TearFree but came up empty. Hope I did not miss a similar ticket.

Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" and "Perf Data" sections in their replies.

[ChristophHaag]

With my 6900XT I've seen it do something like this, especially in openbrush it's bad. The reason was power management.

As root, try echo 4 > /sys/class/drm/card0/device/pp_power_profile_mode. The power profile settings can be read with cat /sys/class/drm/card0/device/pp_power_profile_mode, number 4 should be a profile called VR. echo 0 > ... to reset to the default.

Or the blanket one, echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level with echo auto > ... to reset.

[kivoli]

Thank you so much, much better. :)

[ChristophHaag]

How do you feel about keeping this issue open? I think there are two things about it

1) Fixing the power management so it works properly on the default profile. This might be more an amdgpu thing, but still very relevant to SteamVR. My theory is that because VR applications are throttled down to the HMD refresh rate by the WaitGetPoses() call and the compositor running "asynchronously" to that, the power management is deceived into clocking down too much. 2) Even with better default power management the VR profile is there and should be used. We don't actually want SteamVR switching power profiles though because when SteamVR is killed or crashes we don't want it to not switch back to the default and consume more power. Perhaps there could be a systemd service monitoring process start/stop and switch profiles based on start/stop of the process vrcompositor (or also monado-service).

[Zamundaaa]

Perhaps there could be a systemd service monitoring process start/stop and switch profiles based on start/stop of the process vrcompositor (or also monado-service).

CoreCtrl is such a service and I use it to set the VR profile, and also increase the power limit and overclock a little.

I don't think that's a great long term solution though with mobile VR headsets being a thing; always using max power would be bad for battery life there.

[kivoli]

Hmm, what about Feral’s GameMode? I actually have it installed but forgot about it. ^^

https://github.com/FeralInteractive/gamemode

[dsalt]

Perhaps there could be a systemd service monitoring process start/stop and switch profiles based on start/stop of the process vrcompositor (or also monado-service).

As a user of a distribution which does not have systemd as init, I for one am against providing (only) a systemd-specific solution to this.

Hmm, what about Feral’s GameMode? I actually have it installed but forgot about it. ^^

That relies on systemd. It won't work here.

[ChristophHaag]

Nobody prevents you from running

while true; do pgrep vrcompositor && echo 4 > /sys/class/drm/card0/device/pp_power_profile_mode || echo 0 > /sys/class/drm/card0/device/pp_power_profile_mode; sleep 1; done

with your favorite init system, but it can probably be done nicer without spawning pgrep processes etc. all the time with an event based system monitoring service.

[farmboy0]

I use corectrl so set the power profile to VR for vrcompositor.

[ClearlyClaire]

Just a note that until today I did not know about power profiles and I couldn't get some games to give me decent performance despite my hardware. Thanks to this issue I have enabled the VR power profile to play some games that previously ran with abysmal performances and it is much, much better. Thanks for the info!

[Goofybud16]

I use Radeon-Profile to set the VR profile, and find that it seemingly randomly bounces back to "Bootup Default." I usually open Radeon-Profile, set the value, and close it. It will reset with Radeon-Profile open or closed. Sometimes an entire VR session goes fine without it, sometimes it resets.

Not entirely sure why, but it is rather annoying because performance suddenly suffers (and frames become very stuttery, as the GPU seems to be aggressively clocking up/down every frame or two, resulting in frametimes that look roughly like 1, 0.5, 1, 0.5, 1, 0.5 and so on).

If it at all matters, I use a 6700XT. I usually have RadeonTop running as well in another terminal window (so that I can watch VRAM usage and check for the shader clock dropping, indicating the GPU has 'slipped out of gear' and gone back into Bootup Default)

[Goofybud16]

I did figure out what seems to be causing it to change from VR mode back to Bootup Default.

It seems when Firefox plays a video (I use it for music sometimes) it will set the GPU to "Video" mode, and then afterwards reset it back to "Bootup Default"

Not sure why, possibly because I have it set up to use GPU accelerated video decode.

[pfych]

I can confirm that installing radeon-profile, running it as root, and changing the power profile to VR fixes most issues I was experiencing relating to GPU performace.

This fix does not work on linux_v1.14 which sadly is the last version where I did not have to apply this fix: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/175#issuecomment-481492131

I've got the startup ritual down now though.

[Redemption198]

It happened to me too, I have a 6700XT and managed to get around this bug by using CoreCtrl.

Edit: it appears to be a Mesa bug that should be fixed in Mesa 23.

[Atemu]

The power profiles are not a mesa bug that was fixed in mesa 23.

It's actually an upstream AMDGPU bug that affects other framerate-locked scenarios aswell: https://gitlab.freedesktop.org/drm/amd/-/issues/1500