Created attachment 170669 [details] fps drop SUMMARY After changing the refresh rate from higher to lower, Plasma gets stuck at 30 FPS. Switching to another virtual desktop temporarily restores the correct FPS values, but they drop again after a while. This doesn't happen when I switch to 144 FPS - Plasma works flawlessly. STEPS TO REPRODUCE 1. Change the refresh rate from higher to lower (in my case 144 → 60) OBSERVED RESULT Plasma reduces the FPS value to 30. Switching to another virtual desktop temporarily restores the correct FPS value. EXPECTED RESULT Plasma should maintain a constant 60 FPS. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, KDE Plasma 6 Wayland KDE Plasma Version: Plasma 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Intel TigerLake-H GT1 [UHD Graphics] Mesa Intel® UHD Graphics NVIDIA GeForce RTX 3050 Mobile, Driver Version: 555.52.04
Is it really just Plasma, or everything on the system?
(In reply to Nate Graham from comment #1) > Is it really just Plasma, or everything on the system? Oh, this affects everything on the system - for example while playing games FPS drops to 30 every few moments and then returns to 60 - and this cycle repeats continuously. I looked for some solutions and it turns out that adding KWIN_DRM_NO_AMS=1 to the environment variables makes the problem disappear.
Thanks! Xaver, I was about to mark this as a duplicate of Bug 452219; does that look correct?
As there's no issues at 144Hz, it seems different. I think this could either be a driver bug, or our calculation for the commit deadline still isn't 100% correct for all modes.
Can you please set KWIN_LOG_PERFORMANCE_DATA=1 and attach the csv file with performance data KWin generates in your home folder after a bit of usage?
Created attachment 171077 [details] performance data Sure!
Created attachment 171221 [details] performance data with KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1 Another potentially important piece of information: I removed the KWIN_DRM_NO_AMS=1 flag because it noticeably affected system performance, but I added KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1 and now Plasma runs smoothly at any refresh rate.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
hmm, my tool for analyzing the data says way more frames get dropped with that config vs. AMS disabled: - dropped 681 frames (13%) - 2 because of too late commits (0.037%) - 674 because of late rendering start (12%) - 5 because of render times (0.093%) It seems like the very vast majority of dropped frames comes from rendering starting too late, which might be scheduling going wrong, or something before rendering actually happens not being accounted for in the compositing scheduling. Could you also attach the perf data for a default configuration (remove all env vars + reboot), for comparison?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6128
Created attachment 171755 [details] performance data with no env vars Sure, I've attached the file
Git commit c3d202b0d251de46cce2ff1c8274e7b843b9abcf by Xaver Hugl. Committed on 18/07/2024 at 13:25. Pushed by zamundaaa into branch 'master'. compositor_wayland: count rendering time for all steps of compositing Otherwise, prePaintPass, postPaintPass and possible future overhead like overlay plane matching aren't accounted for, which can cause frames to be dropped. M +3 -0 src/compositor_wayland.cpp https://invent.kde.org/plasma/kwin/-/commit/c3d202b0d251de46cce2ff1c8274e7b843b9abcf
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6136
Git commit d7385d441417d8f43cfb09341b5c0ae449ccd219 by Xaver Hugl. Committed on 18/07/2024 at 14:39. Pushed by zamundaaa into branch 'Plasma/6.1'. compositor_wayland: count rendering time for all steps of compositing Otherwise, prePaintPass, postPaintPass and possible future overhead like overlay plane matching aren't accounted for, which can cause frames to be dropped. (cherry picked from commit c3d202b0d251de46cce2ff1c8274e7b843b9abcf) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +3 -0 src/compositor_wayland.cpp https://invent.kde.org/plasma/kwin/-/commit/d7385d441417d8f43cfb09341b5c0ae449ccd219
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
That commit should be in Plasma 6.1.4, which will be released tomorrow. Once it's out, could you test if it helps?
Created attachment 172434 [details] performance data 6.1.4 Plasma 6.1.4 just landed in the Arch repos and it looks like the bug has been fixed! I'm attaching the performance data to be sure.
Yeah that looks a lot better.