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.
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.
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 ***
I don't agree, I have absolutely no graphical corruption on Wayland, only stutters.
Ok, un-marking for now. Hopefully the KWin developers can sort this out.
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).
Created attachment 173851 [details] kwin perf statistics the stutters start roughly 10s from the end
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.
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.
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