Bug 443872 - Inconsistent adaptive sync behavior in KWin Wayland session
Summary: Inconsistent adaptive sync behavior in KWin Wayland session
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.23.0
Platform: Debian testing Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-17 04:17 UTC by Shmerl
Modified: 2021-11-08 07:54 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.23.3


Attachments
debug logging for vrr enable/disable (852 bytes, text/plain)
2021-10-21 22:16 UTC, Zamundaaa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shmerl 2021-10-17 04:17:17 UTC
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)
Comment 1 Zamundaaa 2021-10-18 20:14:26 UTC
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
Comment 2 Shmerl 2021-10-18 20:23:54 UTC
(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.
Comment 3 Zamundaaa 2021-10-18 20:39:12 UTC
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.
Comment 4 Shmerl 2021-10-18 20:46:26 UTC
(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.
Comment 5 Shmerl 2021-10-18 20:49:13 UTC
I can try to set that env variable in the profile and see if it makes a difference.
Comment 6 Shmerl 2021-10-18 21:09:07 UTC
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.
Comment 7 Zamundaaa 2021-10-19 18:58:31 UTC
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)
Comment 8 Shmerl 2021-10-21 21:22:35 UTC
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.
Comment 9 Zamundaaa 2021-10-21 22:15:27 UTC
> 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.
Comment 10 Zamundaaa 2021-10-21 22:16:10 UTC
Created attachment 142746 [details]
debug logging for vrr enable/disable
Comment 11 Shmerl 2021-10-22 03:14:07 UTC
(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)?
Comment 12 Zamundaaa 2021-10-22 08:47:02 UTC
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
Comment 13 Shmerl 2021-10-22 08:55:41 UTC
OK, I can try building custom kwin with this patch.
Comment 14 Shmerl 2021-10-24 01:31:47 UTC
Where will that log appear btw? Is it $HOME/.local/share/sddm/wayland-session.log
Comment 15 Zamundaaa 2021-10-24 23:17:59 UTC
Unless you're using the systemd session integration (only Fedora has it enabled by default AFAIK), yes
Comment 16 Shmerl 2021-10-31 20:13:16 UTC
OK, trying to build the custom KWin now. I suppose in Debain that would be producing modified kwin-wayland-backend-drm package.
Comment 17 Shmerl 2021-10-31 21:57:45 UTC
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.
Comment 18 Shmerl 2021-10-31 21:58:57 UTC
I definitely don't see such spikes in X11 session though, so something must be different.
Comment 19 Zamundaaa 2021-11-04 16:10:56 UTC
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
Comment 20 Zamundaaa 2021-11-04 16:13:37 UTC
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
Comment 21 Bug Janitor Service 2021-11-04 16:36:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1607
Comment 22 Zamundaaa 2021-11-04 16:37:14 UTC
The patch fixes it for me; do test it yourself as well though to make sure
Comment 23 Shmerl 2021-11-07 04:08:46 UTC
Let me try to apply that to KWin 5.23.2.
Comment 24 Shmerl 2021-11-07 06:43:28 UTC
Tested the patch, it fixed the spikes for me too with CP2077!
Comment 25 Zamundaaa 2021-11-08 07:53:35 UTC
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
Comment 26 Zamundaaa 2021-11-08 07:54:02 UTC
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