SUMMARY In Wayland, but not X11, displays run at half the refresh rate that they're meant to be, running the BlurBusters UFO test on my 60 Hz secondary monitor shows that it's running at 30 fps and dragging the test to the 165 Hz primary monitor causes it to run at 82 fps. Running any vsync application also corroborates the issue, and even the cursor is obviously running at half the refresh rate. However, a fullscreen application that triggers adaptive sync on the primary monitor runs at the full refresh rate. Setting adaptive sync to "Always" also allows the primary monitor to run at the full refresh rate, but not the secondary monitor as it does not have adaptive sync support. STEPS TO REPRODUCE 1. Have an Intel Battlemage GPU running the Xe driver 2. Set adaptive sync on your display to "Off" or "Adaptive" 3. Run anything that can display the vsync framerate or just observe the cursor movement OBSERVED RESULT Displays run at exactly half the selected refresh rate EXPECTED RESULT Displays run at the selected refresh rate ADDITIONAL INFORMATION Despite also being an Intel (UHD 620) GPU, my laptop has no such issue - may be driver dependent, but kwin-wayland is at fault as well because it doesn't happen on X11
*** Bug 500096 has been marked as a duplicate of this bug. ***
This sounds like the driver takes a very long time from commit to pageflip. Please put KWIN_LOG_PERFORMANCE_DATA=1 into /etc/environment, reboot, use the computer for a minute and then attach the csv file from your home folder here; with that we should be able to judge whether or not this is a driver issue.
(In reply to Zamundaaa from comment #2) > This sounds like the driver takes a very long time from commit to pageflip. > Please put KWIN_LOG_PERFORMANCE_DATA=1 into /etc/environment, reboot, use > the computer for a minute and then attach the csv file from your home folder > here; with that we should be able to judge whether or not this is a driver > issue. Hello, I captured this info, please check. :)
Created attachment 178492 [details] KWIN_LOG_PERFORMANCE_DATA
Created attachment 178495 [details] KWin performance CSVs DP-2 is my primary (1440p @ 165Hz with adaptive sync available) and HDMI-A-3 is my secondary (1080p @ 60Hz without adaptive sync available) monitor. For testing purposes, I fullscreened a game on DP-2 for a bit, which triggered automatic adaptive sync and the performance improvement was immediately obvious - this is visible in the vrr=1 segment.
My tool to look at that data says 67% of frames are dropped on DP-2, and 100% on HDMI-A-3. In both cases, the very vast majority because of commits being too late. That means KWin seems to be doing everything correctly, and the kernel is just too late. There is a second possible cause, which we've hit with Intel GPUs before. If you set https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#kwin_drm_disable_buffer_readability_checks to 1, does that change anything?
(In reply to Zamundaaa from comment #6) > Mi herramienta para analizar esos datos indica que el 67 % de los fotogramas > se pierden en DP-2 y el 100 % en HDMI-A-3. En ambos casos, la gran mayoría > se debe a que las confirmaciones se realizan demasiado tarde. > Eso significa que KWin parece estar haciendo todo correctamente y que el > kernel llega demasiado tarde. > > Existe una segunda causa posible, que ya hemos encontrado antes con las GPU > Intel. Si configura > https://invent.kde.org/plasma/kwin/-/wikis/Environment- > Variables#kwin_drm_disable_buffer_readability_checks en 1, ¿eso cambia algo? What about My log file? U.u
(In reply to Mario from comment #7) > What about My log file? U.u Sorry, I forgot to put it in the same folder to be analyzed. The tool reports that basically no frames are dropped in your case, but looking at the file myself, something weirder happens. The pageflips happen with a distance of 21ms, which is a multiple of 8.33ms. So that's a driver issue - it's not actually changing the refresh rate, but just pretending to. As KWin doesn't know the real refresh rate, things don't work out nicely. You can follow https://gitlab.freedesktop.org/drm/amd/-/issues/2501 for that.
(In reply to Zamundaaa from comment #6) > My tool to look at that data says 67% of frames are dropped on DP-2, and > 100% on HDMI-A-3. In both cases, the very vast majority because of commits > being too late. > That means KWin seems to be doing everything correctly, and the kernel is > just too late. > > There is a second possible cause, which we've hit with Intel GPUs before. If > you set > https://invent.kde.org/plasma/kwin/-/wikis/Environment- > Variables#kwin_drm_disable_buffer_readability_checks to 1, does that change > anything? This didn't solve the problem for me on either monitor, and what's strange is that I'm pretty sure the issue only started with Plasma 6.3, I don't think there was a corresponding change to the Intel driver.
(In reply to Nathan F. from comment #9) > This didn't solve the problem for me on either monitor, and what's strange > is that I'm pretty sure the issue only started with Plasma 6.3, I don't > think there was a corresponding change to the Intel driver. Well, there were no frame scheduling changes in Plasma 6.3 either. Other than the kernel being a lot slower than expected, I have no explanation for it. With VRR enabled, the pageflips also arrive at the expected time, so that makes me quite certain that this is on the kernel side. So please report this at https://gitlab.freedesktop.org/drm/xe/kernel/-/issues
*** Bug 500754 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7249
Git commit ea0a7f0a43f4808155c3bf4b6258b015274ea8ac by Xaver Hugl. Committed on 28/02/2025 at 14:37. Pushed by zamundaaa into branch 'master'. backends/drm: allow overriding the safety margin This can be useful for debugging issues with slow drivers. M +11 -1 src/backends/drm/drm_commit_thread.cpp https://invent.kde.org/plasma/kwin/-/commit/ea0a7f0a43f4808155c3bf4b6258b015274ea8ac
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7251
Git commit 8b4237bc6a1bb1fe0bbd7cbfd2cfee1283bc4c69 by Xaver Hugl. Committed on 28/02/2025 at 23:55. Pushed by zamundaaa into branch 'Plasma/6.3'. backends/drm: allow overriding the safety margin This can be useful for debugging issues with slow drivers. (cherry picked from commit ea0a7f0a43f4808155c3bf4b6258b015274ea8ac) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +11 -1 src/backends/drm/drm_commit_thread.cpp https://invent.kde.org/plasma/kwin/-/commit/8b4237bc6a1bb1fe0bbd7cbfd2cfee1283bc4c69
(In reply to Zamundaaa from comment #15) > Git commit 8b4237bc6a1bb1fe0bbd7cbfd2cfee1283bc4c69 by Xaver Hugl. > Committed on 28/02/2025 at 23:55. > Pushed by zamundaaa into branch 'Plasma/6.3'. > > backends/drm: allow overriding the safety margin > > This can be useful for debugging issues with slow drivers. > > > (cherry picked from commit ea0a7f0a43f4808155c3bf4b6258b015274ea8ac) > > Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> > > M +11 -1 src/backends/drm/drm_commit_thread.cpp > > https://invent.kde.org/plasma/kwin/-/commit/ > 8b4237bc6a1bb1fe0bbd7cbfd2cfee1283bc4c69 Yep seems to help when setting KWIN_DRM_OVERRIDE_SAFETY_MARGIN to atleast 2200, now im getting 165HZ in ufotest
*** Bug 505371 has been marked as a duplicate of this bug. ***
This was fix me for me with plasma 6.4
Yeah, https://invent.kde.org/plasma/kwin/-/merge_requests/7438 basically works around the driver being so slow by automatically increasing latency instead of you having to do it manually with the env var.