SUMMARY Issue observed on Fedora Asahi Remix when updated manually to Fedora Rawhide. Special platform notes: this is observed on an apple silicon system, with the Asahi GPU/DCP drivers. This may result in "strange" interactions not observed on other platforms. This is a strange/unsupported configuration, but may be useful to catch this "early". At a desktop with default effects enabled, interactions are "juttery", consistent with a low framerate. The FPS kwin plugin does not appear to regress the observed "feel" any further, and shows results consistent with the observed behavior. "Typical" refresh rate (average) appears to stay consistently at 30fps. Frametimes are consistent within the FPS plugin view (do not vary significantly), and the system is under very low compositing load. The monitor is set to refresh at 60 fps. If the monitor is set to refresh at 48hz, the observed average FPS drops to 24 (though this is inconsistently reproducible). The "juttery" feel is observed when moving between desktops (desktop swipe), as well as when resizing any window or scrolling within any tested application (firefox, kde settings, dolphin, nautilus). STEPS TO REPRODUCE: 1. Upgrade a Fedora Asahi Remix install to Rawhide 2. Set internal display refresh rate to 60hz (this is the default behavior already) 3. Interact with an application or the desktop OBSERVED RESULT Display has an observed (by "feel") refresh rate consistent with a 30hz panel EXPECTED RESULT Display should refresh at up to 60hz under low compositing load SOFTWARE/OS VERSIONS Linux/KDE Plasma: kernel '6.6.3-411.asahi.fc40.aarch64+16k' (available in About System) KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION Considering compositing load is so light in this setting, and that the issue continues to appear when ~all kwin effects are disabled as well, this seems very unlikely to simply be a product of too much load. This feels like a matter of some "this buffer is ready to display" message being delayed by a frame, pushing back the start of the next draw and halving the observed refresh rate.
There's three ways this could happen: 1. OpenGL render time queries are broken 2. the buffer becomes readable later than the render time queries say 3. KWin does the atomic commits too late You can test if it's the second one by setting KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS=1. Does that improve the refresh rate? Afaik the Asahi driver currently doesn't support hardware cursors (that are moved without OpenGL or buffer readability tests being involved), so testing possibility 3 requires patching KWin
(In reply to Zamundaaa from comment #1) > There's three ways this could happen: > 1. OpenGL render time queries are broken > 2. the buffer becomes readable later than the render time queries say > 3. KWin does the atomic commits too late > > You can test if it's the second one by setting > KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS=1. Does that improve the refresh > rate? > > Afaik the Asahi driver currently doesn't support hardware cursors (that are > moved without OpenGL or buffer readability tests being involved), so testing > possibility 3 requires patching KWin No "feel" improvement and the FPS effect doesn't display any obvious change with KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS set. Last time I tried kdesrc-build the head-desk-banging went to a 9 on the Richter scale but I can absolutely try building just Kwin with some modifications to test some stuff. You're right that the asahi drivers don't yet support hardware cursors, and I can note that I see refreshes at 30hz in the FPS plugin when I move the mouse (that doesn't bring it any higher)
Is there a good way of checking what response I'm getting for render time queries for #1 as well?
With https://invent.kde.org/plasma/kwin/-/commits/work/zamundaaa/performance-logging you get logging about the render times and dropped commits. Make sure to run it without KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS.
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!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone!
*** This bug has been marked as a duplicate of bug 482064 ***