Bug 493073

Summary: low (idle) fps/stutters with dynamic triple buffering
Product: [Plasma] kwin Reporter: Bernhard <micraft.b>
Component: performanceAssignee: KWin default assignee <kwin-bugs-null>
Status: CONFIRMED ---    
Severity: major CC: kde, nate, xaver.hugl
Priority: NOR    
Version: 6.1.5   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=492319
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: kwin perf statistics
perf stats no readability checks

Description Bernhard 2024-09-13 17:43:06 UTC
SUMMARY
Dynamic triple buffering sometimes drops the frame-rate to what feels like 20 fps. It will mostly stay there if you use the system at all, with sometimes a couple seconds of smooth 120fps

STEPS TO REPRODUCE
1. Have this Laptop, or possibly any 120Hz laptop with Radeon 880M
2. Boot your system, do anything like scroll a webpage open panel applets 
3. Notice the very low framerate, even when just moving the cursor

The kernel version might be important, with I can't test with older kernels because they don't work right with the hardware.

OBSERVED RESULT
kwin seems to switch between rendering okay and then suddenly, without being under any significantload dropping frames massively, and staying there even while idle. That's not something that should happen with working hw-decode on one of the most powerful iGPUs to date.
When measuring with the "Show FPS" effect kwin reports 52fps but I don't trust it. It feels more like 20fps, probably due to the frame timing. Those reportedly 52 fps do stay suspiciously constant too (when it's doing the thing).
I suspect something with the hysteresis is wrong, which makes kwin not want to go back once it starts triple buffering. Maybe triple buffering is just crazy expensive with this GPU so it mostly can't go back except for the occasional blip, but that's just a guess. 

An oddity I've seen is that you can sometimes see a config option for VRR in Display Configuration, but sometimes it's gone. To remove this variable I keep it is set to "never".

EXPECTED RESULT
A smooth 120fps with maybe a couple frames dropped at most during light webbrowsing, not stuttering along with what feels like 20

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.11.0-rc7-3-mainline-um5606-dirty (64-bit)
Graphics Platform: Wayland
Processors: 20 × AMD Ryzen AI 9 365 w/ Radeon 880M
Memory: 22.6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ASUS Zenbook S 16 UM5606WA_UM5606WA

ADDITIONAL INFORMATION
Somebody else with similar hardware also had this exact problem: https://github.com/BNieuwenhuizen/zenbook-s16/issues/7
I've set severity major because most of the time you can't even really watch videos fullscreen without very noticable stuttering, or move the cursor. Also, a lot more people will have this gpu pretty soon, seeing as it launched a month ago.
If this isn't easy to fix (which it might not be), please at least expose the setting as an option (since Plasma 6.1 the whole compositor kcm page is gone?), but idk.
Comment 1 Bernhard 2024-09-13 17:46:08 UTC
Sorry, I forgot to add: I have no problems at all with "KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1" set in plasma-kwin_wayland.service, which is how I absolutely know that it is the problem.
Comment 2 Nate Graham 2024-09-17 21:26:39 UTC
This sounds very much like Bug 492319. The symptoms you're reporting are identical, and in that case, it's also an AMD laptop, with two generations ago's CPU and GPU (7840U + 780M). Tentatively marking as a duplicate.

*** This bug has been marked as a duplicate of bug 492319 ***
Comment 3 Bernhard 2024-09-17 23:21:11 UTC
I don't agree, I have absolutely no graphical corruption on Wayland, only stutters.
Comment 4 Nate Graham 2024-09-18 16:39:16 UTC
Ok, un-marking for now. Hopefully the KWin developers can sort this out.
Comment 5 Zamundaaa 2024-09-18 23:43:11 UTC
Please set `KWIN_LOG_PERFORMANCE_DATA=1` and attach the csv file KWin puts in your home directory here. It would be useful if you'd cut them off at a time where the lags are happening (just duplicate the file when it happens).
Comment 6 Bernhard 2024-09-19 06:16:53 UTC
Created attachment 173851 [details]
kwin perf statistics

the stutters start roughly 10s from the end
Comment 7 Bernhard 2024-09-19 06:22:26 UTC
I've attached the file, hope it helps.

As you probably noticed, it doesn't take long to trigger for me. As soon as I start firefox, kwin it starts lagging and mostly doesn't recover.
If there is anything else I can help with to make debugging easier please let me know.
Comment 8 Zamundaaa 2024-09-19 18:19:13 UTC
In those last 10s more than 50% of frames are dropped. According to my debug tool, rendering finishes in time though.
This could be caused by
1. the commit thread not getting enough CPU time and missing the deadline that way
2. commit scheduling delaying commits wrongly sometimes
3. OpenGL render time queries not matching buffer readability checks

We've seen 3 happen before, caused by a driver bug on Intel. Please test with KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS=1 set, which should rule it out.
Comment 9 Bernhard 2024-09-19 18:37:33 UTC
Created attachment 173892 [details]
perf stats no readability checks

(In reply to Zamundaaa from comment #8)
> We've seen 3 happen before, caused by a driver bug on Intel. Please test
> with KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS=1 set, which should rule it
> out.

Looks pretty much the same to me unfortunately