I just tried Plasma 5.23.0 (built for Debian testing) since it has a number of major Wayland related bugs fixed, and noticed a problem with adaptive sync. When running Cyberpunk 2077 game (Wine-staging + vkd3d-proton), framerate hovers around 70-85 fps in the game for me. Monitor's built in refresh rate meter shows that adaptive sync is working (most of the time it indeed matches the framerate fluctuating around 70-85 Hz), but it also periodically jumps to 144 Hz which looks strange, since Mesa HUD which I use with the game to compare never shows framerate jumping that high and it's my monitor's limit. In X11 Kwin session I don't see such behavior in the same place in the game and monitor's built in meter never shows such spikes in refresh rate. Configuration details: * Plasma / KWin: 5.23.0 * Display setting for adaptive sync: automatic. * GPU: Sapphire Pulse RX 6800 XT. * Display: LG 27GL850 (144 Hz, adaptive sync capable, DisplayPort connection). * Wine-staging: 6.16 (the game runs in XWayland) * Wayland: 1.19.0 * XWayland: 1.20.11 * Kernel / amdgpu: 5.14.12 * Mesa: recent main build - 22.0.0-devel (git-d31ca63527)
Does the refresh rate jump in response to moving a visible hardware cursor or really periodically, without input? The former would be expected behavior atm
(In reply to Zamundaaa from comment #1) > Does the refresh rate jump in response to moving a visible hardware cursor > or really periodically, without input? The former would be expected behavior > atm It might be in response to some mouse input that's causing movement in the game. How do I check if it's using hardware cursor? I don't think I set anything special for that or even looked into this setting.
It has to be visible and usually has the system theme (but that's not a given). While this can be considered a bug, you can force this behavior off with the environment variable KWIN_FORCE_SW_CURSOR=1.
(In reply to Zamundaaa from comment #3) > It has to be visible and usually has the system theme (but that's not a > given). I this case I only see in-game UI and cursor, no system UI. Reading about CP2077, it doesn't look like it supports using hardware cursor either.
I can try to set that env variable in the profile and see if it makes a difference.
OK, I run some tests with that env variable set. It's still happening. And I also tried not to use mouse and keyboard during the test. Those spikes still periodically occur.
I think I can reproduce this with vrrTest - every second or so there's small stutter when I have it set to 100fps (120Hz display)
If it's stutter may be it's something with LFC kicking in? I.e. low framerate compensation where monitor runs at refresh rate that's multiple of the framerate below certain point? But I didn't notice framerate dropping that low in the Mesa HUD and it's still suspicious that it runs at exactly max refresh rate during those spikes, looks more like adaptive sync just turns off during those moments.
> LFC kicking in? With vrrTest it's running at a constant 100fps, that can't be it. > looks more like adaptive sync just turns off during those moments I tried to add debug logging for when it toggles vrr... and could no longer reproduce it. I'll add the patch here (should apply cleanly to master and 5.23) if you want to try it yourself - it'll simply print "vrr changed to 0/1" in your wayland session.log.
Created attachment 142746 [details] debug logging for vrr enable/disable
(In reply to Zamundaaa from comment #10) > Created attachment 142746 [details] > debug logging for vrr enable/disable Will this land in the upcoming Plasma bugfix releases? And how do I run something with such debug logging enabled (if this change is in the compositor already)?
It will not. It probably wouldn't hurt much to add some debug logging for the VRR property state in a release but I doubt its usefulness, I mainly just want to double check this somewhat unlikely thing before we do other tests. This logging is enabled by default, all that's needed is a recompilation of KWin with the patch. What distro are you using? As an alternative to patching you could probably run drm_info in a script, grep the vrr_enabled property and see if it toggles back and forth. Tbh that seems like more effort though
OK, I can try building custom kwin with this patch.
Where will that log appear btw? Is it $HOME/.local/share/sddm/wayland-session.log
Unless you're using the systemd session integration (only Fedora has it enabled by default AFAIK), yes
OK, trying to build the custom KWin now. I suppose in Debain that would be producing modified kwin-wayland-backend-drm package.
Run the test with CP2077. I only see that value flipping in the long when I minimize the game window (then vrr turns off) kwin_wayland_drm: vrr changed to 0 and restore it back (then vrr turns on) kwin_wayland_drm: vrr changed to 1 But when those spikes to max refresh rate on the display built in HUD happen, it's not logging any of those, so as far as that code goes, it assumes VRR is on during the spikes.
I definitely don't see such spikes in X11 session though, so something must be different.
I could now for some reason reproduce it again. Some digging revealed that KWin is scheduling repaints for windows regardless of whether or not they're covered by a fullscreen window - when those trigger a frame earlier than the fullscreen app then you see stutter. This is probably also the cause why
Ugh, didn't mean to send yet. I wanted to write: This could also be one reason for why there can be small stutter in general when gaming. Fixing this could also yield some efficiency improvements
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1607
The patch fixes it for me; do test it yourself as well though to make sure
Let me try to apply that to KWin 5.23.2.
Tested the patch, it fixed the spikes for me too with CP2077!
Git commit 75863454a0c16e8713fab5662801fd1d15d4e89a by Xaver Hugl. Committed on 06/11/2021 at 23:41. Pushed by zamundaaa into branch 'master'. RenderLoop: restrict repaint scheduling with fullscreen windows With an opaque fullscreen window we can be sure that items under it don't actually require us to repaint. This should yield some small efficiency improvements and resolves stutter with adaptive sync. FIXED-IN: 5.23.3 M +4 -4 src/item.cpp M +5 -5 src/renderloop.cpp M +3 -3 src/renderloop.h M +1 -1 src/renderloop_p.h https://invent.kde.org/plasma/kwin/commit/75863454a0c16e8713fab5662801fd1d15d4e89a
Git commit 638f5482a854d4538fa3e58588d8d33d9e938618 by Xaver Hugl. Committed on 08/11/2021 at 07:53. Pushed by zamundaaa into branch 'Plasma/5.23'. RenderLoop: restrict repaint scheduling with fullscreen windows With an opaque fullscreen window we can be sure that items under it don't actually require us to repaint. This should yield some small efficiency improvements and resolves stutter with adaptive sync. FIXED-IN: 5.23.3 (cherry picked from commit 75863454a0c16e8713fab5662801fd1d15d4e89a) M +4 -4 src/item.cpp M +5 -5 src/renderloop.cpp M +3 -3 src/renderloop.h M +1 -1 src/renderloop_p.h https://invent.kde.org/plasma/kwin/commit/638f5482a854d4538fa3e58588d8d33d9e938618