Open mkopec opened 1 year ago
Are you playing with a controller? I've heard mouse inputs can cause issues with vrr, so maybe unplug keyboard and mouse and try playing with only a controller, to see if that makes a difference.
Hmm, yes, I'm playing with an Xbox Series X/S controller via the official dongle, but the same issue appears when I use a mouse polling at 1000Hz.
Is this problem present on other VRR implementations for you? I can't see anything that'd cause this on our side and it definitely doesn't happen on my display. Likely something kernel sided?
VRR works well in Sway for me with the same games.
Did some more testing, started removing options from my gamescope command until the problem disappeared. It looks like --hdr-enabled
is the culprit, if enabled I see this weird behavior, if disabled, VRR works perfectly again.
So with this, VRR works perfectly:
gamescope -O HDMI-A-1 --adaptive-sync -W 3840 -H 2160 -e -r 120 -- steam -bigpicture
and with this it stops:
gamescope -O HDMI-A-1 --adaptive-sync -W 3840 -H 2160 -e -r 120 --hdr-enabled -- steam -bigpicture
Can't really test HDR + VRR in any other compositors 😅 Do you think this might be a kernel bug @Joshua-Ashton ?
Same thing happens on my 5950X + 6800XT PC while running gamescope i DRM mode. --hdr-enabled
breaks VRR and it jumps between 120 Hz and 61 Hz. Sometimes it just gets stuck at 66 Hz when using steam with -steamdeck -steamos3
arguments
Seems to be a recent regression as I was playing Horizon Zero Dawn recently and VRR with HDR worked correctly. Tested on Archlinux + 6.5.9 / 6.1 LTS kernels.
Issue appears to be fixed as of commit d434d86c0d8a569af518c6bdd9ff2616f5a784c9 , Linux 6.6.7-arch1-1, Mesa 23.3.1. Thanks!
I did some further testing and HDR + VRR is still broken, even with 6.7 kernel. What's weird is that VRR + HDR works with nested gamescope needed to enable HDR gaming on plasma 6 (+ wsi layer).
Indeed the issue seems to still be there as of the latest revision and kernel 6.7.0. I only tested Doom Eternal when I reported that the issue is fixed, but after some further testing, other games still have the same issue, and with the latest revisions, so does Doom Eternal again.
As of commit https://github.com/ValveSoftware/gamescope/commit/e8f3b355875dbd1eb5e9cff164428d6f733023b7 , it is no longer possible to enable HDR and VRR simultaneously. When HDR is enabled in Steam UI, the TV reports 120Hz HDR input without Freesync, and the VRR toggle doesn't do anything (VRR state is Disabled
in Steam UI). When HDR is disabled, the VRR toggle works correctly.
I've reverted to stable gamescope release v3.13.19 temporarily, where HDR + VRR can be enabled and is functional. I guessed that when HDR is enabled, some compositing / tonemapping is taking more time and hits some sort of timeout in the Vblank manager code, so I've started playing with parameters in vblankmanager.hpp.
I bumped the value of kDefaultVBlankDrawTimeMinCompositing
from 2.4 ms all the way up to 6.4 ms, as the comment suggested it may be relevant in this case. I can now get stable framerates with VRR working as it should, for example in Forza Horizon 5 I get ~90 FPS, but when I reach 100FPS the framerate starts to stutter heavily, jumping between 88 and 120 FPS.
So my theory is that compositing 4K HDR content on my 6700XT takes way more time than expected for some reason (maybe because layers / color management ASICs / whatever specialty hardware relevant here is not used? I'm not familiar with color management enough to tell.)
Then again 6.4ms seems like way too much time for compositing, so I guess something else could be the problem.
@Joshua-Ashton as there are DiplayPort->HDMI 2.1 PCONs that are whitelisted to support VRR in the amdgpu, HDR + VRR in gamescpoe should become a big priority, as this is (or will be) supported by the SteamDeck. The VRR allowlist was backported to 6.1 LTS kernel.
We don't composite in the Steam Deck as we have everything for HDR multiplane scanout in SteamOS.
If composite is taking 4+ ms, then something is horribly wrong.
Is it possible that you're doing something in SteamOS that wouldn't be in stock ArchLinux? It's the same amdgpu + gamescope in DRM mode after all
@Lawstorant I guess so, Steam Deck kernel has some color management patches that aren't upstream yet. I'll try building linux-neptune-6.5 and see if it makes a difference, I'm hoping the amdgpu patches will also work on non-Deck hardware.
Yeah, with linux-neptune-65 from SteamOS, gamescope can now make use of hw planes for HDR, and VRR works correctly again. I guess I'll just keep using the SteamOS kernel until all of the color mgmt patches land upstream
@mkopec thanks for confirming that. Sadly, only 6.7 fixes HDR colorspace on DisplayPort with amdgpu, so I think I'll have to apply these patches manually on top of 6.7
I can confirm I'm seeing the same issue on stock Arch with an RX 6800XT, and using the neptune kernel fixes it for me. This is with a Cable Matters 102101 DP -> HDMI 2.1 adapter, with an LG B9 with a patched EDID to add the missing freesync range.
I can confirm I'm seeing the same issue on stock Arch with an RX 6800XT, and using the neptune kernel fixes it for me. This is with a Cable Matters 102101 DP -> HDMI 2.1 adapter, with an LG B9 with a patched EDID to add the missing freesync range.
How did you manage to run neptune kernel with RX 6800XT? I'm on 6700XT and tried linux-neptune-65 from AUR, but I had to edit config so that it included BTRFS explicitly (otherwise mounting btrfs volumes on boot would fail), but even then amdgpu isn't loaded, there's nothing in dmesg about it and Plasma 6 uses llvmpipe as its renderer (gamescope session obviously wouldn't work).
I've got the same Cable Matters adapter with flashed firmware (that was linked in the well known Freedesktop's Gitlab issue about HDMI 2.1 support) and I managed to get it working using linux-amd-color and gamescope-amd-color (which as I understand, includes your patches from https://github.com/ValveSoftware/gamescope/pull/1149), but it's unstable with Gamescope, and Plasma 6 has messed up colors with HDR turned on (on a contrary, Plasma 6 worked nicely with HDR enabled and VRR on stock kernel), and sometimes the system freezes completely. When I just launch a game and keep playing it without changing any settings/showing Steam overlay, it works really well.
I am using a philips 55oled807 with an hdmi 2.1 cord, and an i5 12400f processor, an amd RX 7800 XT graphics card with gnome shell os, and when I switch my TV to hdr + vrr mode, I see flickering images, when I wake up from sleep I can get a black screen while I turn off my TV to hdr only mode (without vrr). Then everything will work stably. I installed the latest OS and updated everything that was updated) hdr+ vrr does not work stably for me, even with the latest hardware unfortunately.
I am using a philips 55oled807 with an hdmi 2.1 cord, and an i5 12400f processor, an amd RX 7800 XT graphics card with gnome shell os, and when I switch my TV to hdr + vrr mode, I see flickering images, when I wake up from sleep I can get a black screen while I turn off my TV to hdr only mode (without vrr). Then everything will work stably. I installed the latest OS and updated everything that was updated) hdr+ vrr does not work stably for me, even with the latest hardware unfortunately.
This issue is about running Gamescope in DRM mode, aka SteamDeck mode, which has support for both features on SteamOS, but it malfunctions on mainline kernel. GNOME doesn't support VRR or HDR yet (though VRR looks like is close)
Problem:
When running games via steam in gamescope in DRM mode with HDR and VRR enabled, the screen's refresh rate is very unstable and jumps between 61 and 120 instead of being consistent with the game's framerate. This results in visible stuttering instead of smooth gameplay.
My setup is:
Games tested:
All of these run below the screen's native 120Hz refresh rate, mostly around 80-90FPS. I'm checking the TV's refresh rate via its builtin OSD, it's telling me that Freesync is enabled and the refresh rate is rapidly switching between 120 and 61. If a game is running at 120FPS stably, then the issue does not occur.
Interestingly, in Steam UI I don't see this problem, instead I see a stable 110 FPS and no stutter at all.