Bug 446478 - Plasma desktop unusable due to stuttering with compositing enabled on VRR display with gsync enabled
Summary: Plasma desktop unusable due to stuttering with compositing enabled on VRR dis...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.23.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-04 15:27 UTC by Eduard
Modified: 2023-09-06 10:39 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
perf at 145Hz for 10s on kwin_x11 when gsync-enabled (269.99 KB, image/svg+xml)
2021-12-04 15:27 UTC, Eduard
Details
perf at 145Hz for 10s on kwin_x11 when gsync-disabled (131.24 KB, image/svg+xml)
2021-12-04 15:28 UTC, Eduard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eduard 2021-12-04 15:27:59 UTC
Created attachment 144213 [details]
perf at 145Hz for 10s on kwin_x11 when gsync-enabled

SUMMARY
On my single-monitor x11 setup, enabling (a.k.a. "not disabling") gsync in the nvidia-settings causes everything to stutter. This is new since my distro upgrade (see versions below). Happens both logged-in and when sddm is running.

It gives the impression that "processing speed" is coupled with the refresh rate. For example, with an empty desktop/no visual movement, triggering krunner takes multiple seconds ... every time. When I trigger it while quickly dragging a window (thus raising the VRR) it happens ~instantly. (It's almost as if it takes a fixed number of frames to show it.)

When disabling gsync or compositing, fps is at a locked 144 and no problems occur.

This bug sounds somewhat overlapping with #445330 but they explicitly say "x11 is fine" and don't mention VRR.

STEPS TO REPRODUCE
1. Have plasma5 desktop running on X11
2. Open nvidia-settings
3. Toggle "Allow G-SYNC/G-SYNC Compatible" from off to on

OBSERVED RESULT
1. FPS counter (built into the display itself) unlocks from 144 to a variable number roughly proportional to amount of movement on screen, as low as 1 FPS.
2. During "low FPS times" everything stutters, there are large delays (e.g. krunner or kickoff)

EXPECTED RESULT
1. either locked max fps (windows does this) 
2. or instant fps scaling without any delays (phones do that I believe)

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.23.3 (prev: 5.21.5)
KDE Frameworks Version: 5.87.0 (prev: 5.81.0)
Qt Version: 5.15.3 (prev: 5.15.2)

ADDITIONAL INFORMATION
Kernel: 5.15.4 (prev: same)
Distro: NixOS 21.11.333896.a640d8394f3 (prev: 21.05)
Nvidia driver: 495.44 (prev: 470.63.01)

I was curious as to how kwin is handling this internally so peeked at it a bit, see attachments. [gsync-on variant seems to eat quite a bit more cycles and spend a lot of time within destructors?]
Comment 1 Eduard 2021-12-04 15:28:42 UTC
Created attachment 144214 [details]
perf at 145Hz for 10s on kwin_x11 when gsync-disabled
Comment 2 Eduard 2021-12-04 15:40:01 UTC
I forgot to mention: There's nothing obvious in the logs for kernel, X, krunner, kwin, xsession, etc. But one of the symptoms becomes visible once gsync is enabled: You start seeing entries like

    (EE) event3  - DELL Dell USB Entry Keyboard: client bug: event processing lagging behind by 31ms, your system is too slow

for mouse and keyboard despite <5% cpu utilization per core.
Comment 3 David Edmundson 2023-09-06 10:39:00 UTC
This bug was reported against an outdated version of KWin. We have made many changes since the. 
If the issue persists in newer versions can you reopen the bug report updating the version number.