Bug 488843

Also, my display don't have anything fancy like VRR its just an old  fullhd 60hz display.

Similar thing to what was reported in Bug 488821. This one is AMD though, not NVIDIA.

I can confirm this.

I have stuttery animations with Plasma 6.1 a lot more often than I did with Plasma 6 or 5 (but when they are smooth, they are REALLY smooth!).

This ist most noticable when moving windows, minimizing windows, showing the list menu in the task manager or when sub windows open in Dolphin (confirmations, renames, etc.).

Setting "KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1" fixes it.

SOFTWARE/OS VERSIONS
Operating System: EndeavourOS 
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Mesa: 24.1
Processors: AMD Ryzen 7 7700X 8-Core Processor
Memory: 31,0 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX

Also happens on Intel hardware for me, see https://bugs.kde.org/show_bug.cgi?id=488860

Setting "KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1" fixes it on both of my machines.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5973

Git commit a169114fee661e61519f06c0567f4daa486dc336 by Xaver Hugl.
Committed on 24/06/2024 at 13:26.
Pushed by zamundaaa into branch 'master'.

core/renderloop: log frame statistics into a file

Data like target vs. actual pageflip time, and render times is often needed for
debugging or optimizing render time predictions, so this commit makes KWin print
that information to a file in the home directory whenever KWIN_LOG_PERFORMANCE_DATA
is set.

M  +10   -5    src/core/renderbackend.cpp
M  +4    -3    src/core/renderbackend.h
M  +18   -2    src/core/renderloop.cpp
M  +5    -1    src/core/renderloop_p.h

https://invent.kde.org/plasma/kwin/-/commit/a169114fee661e61519f06c0567f4daa486dc336

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5975

Can someone that's affected by this please run KWin with the linked MR applied, and upload the file it puts into the home directory? It should contain pretty much all information we need to debug this properly

*** Bug 488860 has been marked as a duplicate of this bug. ***

*** Bug 488821 has been marked as a duplicate of this bug. ***

Git commit 060db4cc7c30451522a595d3f6ce6f320409f133 by Xaver Hugl.
Committed on 24/06/2024 at 13:40.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core/renderloop: log frame statistics into a file

Data like target vs. actual pageflip time, and render times is often needed for
debugging or optimizing render time predictions, so this commit makes KWin print
that information to a file in the home directory whenever KWIN_LOG_PERFORMANCE_DATA
is set.


(cherry picked from commit a169114fee661e61519f06c0567f4daa486dc336)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +10   -5    src/core/renderbackend.cpp
M  +4    -3    src/core/renderbackend.h
M  +18   -2    src/core/renderloop.cpp
M  +5    -1    src/core/renderloop_p.h

https://invent.kde.org/plasma/kwin/-/commit/060db4cc7c30451522a595d3f6ce6f320409f133

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5979

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5982

If anyone affected could test https://invent.kde.org/plasma/kwin/-/merge_requests/5982, that would also be good. Preferably with https://invent.kde.org/plasma/kwin/-/commit/a169114fee661e61519f06c0567f4daa486dc336 logs with and without this MR

Git commit c5fb21fd8baa7033a7828805ab937146c7af2480 by Xaver Hugl.
Committed on 25/06/2024 at 13:07.
Pushed by zamundaaa into branch 'master'.

core/renderloop: assume high render times if the last frame has been a while ago

This helps avoid some frame drops after the GPU may have went into a lower power
state. While this isn't generally noticeable, avoiding this makes noticing and
debugging actually relevant frame drops easier

M  +6    -1    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/c5fb21fd8baa7033a7828805ab937146c7af2480

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5993

Git commit d2cbdbab307957b7284141e30dd9829a37413bed by Xaver Hugl.
Committed on 25/06/2024 at 16:57.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core/renderloop: assume high render times if the last frame has been a while ago

This helps avoid some frame drops after the GPU may have went into a lower power
state. While this isn't generally noticeable, avoiding this makes noticing and
debugging actually relevant frame drops easier


(cherry picked from commit c5fb21fd8baa7033a7828805ab937146c7af2480)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +6    -1    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/d2cbdbab307957b7284141e30dd9829a37413bed

I've been doing some testing with the FPS counter on my screen.  I know this isn't meant to be 100% accurate but in this case the user experience is reflected within the desktop effect.

I've done quite a bit of testing and think it may have something to do with the desktop blur effect, or at least the issue seems to be exaggerated when a window that uses blur is in view. Launching konsole with a blurred background tanks my FPS to 30-40fps while no blurred windows are visible I sit about 100-160fps. I'll include my system details just in case.

Operating System: EndeavourOS 
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.6-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 20 × 13th Gen Intel® Core™ i7-1370P
Memory: 62.5 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: Framework
Product Name: Laptop (13th Gen Intel Core)
System Version: A7

I haven't tried to run the mentioned merge requests to gather debug data because I'm not actually 100% sure how to run it on my system.

Created attachment 171074 [details]
KWIN_Performance_Data_Triple_Buffering.zip

Updated to Plasma 6.1.1 today and recorded the performance data for both my AMD desktop and Intel notebook.

Updated to Plasma 6.1.1
Enabled performance logging
Cleared Plasma related caches
Rebooted

For the Intel notebook I recorded with 3 different kernels (Arch normal, Arch LTS and Arch Zen) with triple buffering enabled and one time with it disabled.

For the AMD desktop I recorded with 2 different power profiles for the GPU (3D Fullscreen and Compute), both being more aggressive in raising the clocks than the default profile and Compute being more aggressive than 3D Fullscreen. 2 times with triple buffering enabled and one time with triple buffering disabled.

Plasma 6.1.1 already shows improvements with triple buffering enabled on both my desktop and notebook. But stutters can still be noticed on both, especially when maximizing / minimizing windows (often when done in quick succession) or when the notebook has been idle for a bit.

Disabling triple buffering again improves things on the notebook and completely removes stutters on the desktop.

(In reply to pyro_kde_bugs from comment #18)
> I've been doing some testing with the FPS counter on my screen.  I know this
> isn't meant to be 100% accurate but in this case the user experience is
> reflected within the desktop effect.
> 
> I've done quite a bit of testing and think it may have something to do with
> the desktop blur effect, or at least the issue seems to be exaggerated when
> a window that uses blur is in view. Launching konsole with a blurred
> background tanks my FPS to 30-40fps while no blurred windows are visible I
> sit about 100-160fps. I'll include my system details just in case.
> 
> Operating System: EndeavourOS 
> KDE Plasma Version: 6.1.0
> KDE Frameworks Version: 6.3.0
> Qt Version: 6.7.2
> Kernel Version: 6.9.6-arch1-1 (64-bit)
> Graphics Platform: Wayland
> Processors: 20 × 13th Gen Intel® Core™ i7-1370P
> Memory: 62.5 GiB of RAM
> Graphics Processor: Mesa Intel® Graphics
> Manufacturer: Framework
> Product Name: Laptop (13th Gen Intel Core)
> System Version: A7
> 
> I haven't tried to run the mentioned merge requests to gather debug data
> because I'm not actually 100% sure how to run it on my system.

Ignore this one, I figured out my issue was not related to this bug at all, it turns out my RAM got slightly de-seated and was causing my CPU to run at its minimum idle frequency all the time (400mhz). After I re-seated the RAM my low fps issues went away completely.  Sorry for adding confusion into the mix, disregard the comment this is in reply to.

Updated to Plasma 6.1.2 today and recorded performance data again for the notebook and desktop.

On the notebook I can't really see a difference anymore between triple buffering enabled or disabled. The severe stutters are gone.

On the desktop the severe stutters also seem to be gone. But animations still seem to be a bit smoother with dynamic triple buffering disabled.

Created attachment 171380 [details]
KWIN_6_1_2_Performance_Data_Triple_Buffering.zip

Performance data from Plasma 6.1.2 attached.

Created attachment 171409 [details]
perf stats csv files running KWin with MR 5982 and without

I built KWin with the hysteresis MR (https://invent.kde.org/plasma/kwin/-/merge_requests/5982) applied and ran it with logging.
I also ran stock 6.1.2 KWin with logging. This was done on a notebook with intel UHD 630 integrated gpu in the 1080@60Hz mode.

I didn't notice improvements in either cases on my end, framerate still gets halved until certain types of large screen updates happen (pulling the overview, alt-tabbing, switching vdesktops, etc), at which point it goes back to 60fps for a short time. just like the others, disabling triple-buffering fixes it. This is much less of an issue in 144Hz mode.

Git commit 0672313c209232341581459c656b8e8fa1cf8158 by Xaver Hugl.
Committed on 16/07/2024 at 14:21.
Pushed by zamundaaa into branch 'master'.

core/renderloop: add some hysteresis to triple buffering

Switching to triple buffering requires dropping a frame, so if we constantly
switch back and forth between double and triple buffering, that can cause
very visible performance issues

M  +31   -7    src/core/renderloop.cpp
M  +2    -0    src/core/renderloop_p.h

https://invent.kde.org/plasma/kwin/-/commit/0672313c209232341581459c656b8e8fa1cf8158

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6114

Thanks for the measurements. Seems like the MR doesn't make much of a difference except (like expected) keeping triple buffering enabled more often, so your problem is elsewhere.

My analysis tool says that 0.45% of frames are dropped, and half of those are from late commits. For those I suspect they happen when scheduling goes really bad in combination with more commits needing to be processed in the commit thread. If you increase the 1500us safety margin at https://invent.kde.org/plasma/kwin/-/blob/0672313c209232341581459c656b8e8fa1cf8158/src/backends/drm/drm_commit_thread.cpp#L296, does that reduce the stutter?

Git commit ce1ba4252552c7f314149e8be87d5d63fca0210c by Xaver Hugl.
Committed on 16/07/2024 at 15:53.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core/renderloop: add some hysteresis to triple buffering

Switching to triple buffering requires dropping a frame, so if we constantly
switch back and forth between double and triple buffering, that can cause
very visible performance issues


(cherry picked from commit 0672313c209232341581459c656b8e8fa1cf8158)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +31   -7    src/core/renderloop.cpp
M  +2    -0    src/core/renderloop_p.h

https://invent.kde.org/plasma/kwin/-/commit/ce1ba4252552c7f314149e8be87d5d63fca0210c

Thanks for the response!

So I tested different values for the extra safety margin on a Plasma/6.1 build, and increasing it does help reduce dropped frames.
I need to make it pretty high, closing in on the frame time itself (not counting vblank), to have a noticeable effect though.
Anything lower than ~10ms still makes the framerate eventually tank, but above ~14ms the 60fps target is consistently maintained.

I also took the liberty of running the analysis tool myself:
- 6 000 us
> - total of 46008 frames
> - dropped 40 frames (0.087%)
>    - 11 because of too late commits (0.024%)
>    - 16 because of late rendering start (0.035%)
>    - 13 because of render times (0.028%)
> - 2257us average render time
> - 2000us median render time
> - 363s total 'unnecessary' latency
> - would've estimated render times too low in 59 frames (0.13%)
> - would've estimated 50+% too much render time in 40951 frames (89%)
- 13 000 us
> - total of 48274 frames
> - dropped 24 frames (0.05%)
>    - 8 because of too late commits (0.017%)
>    - 9 because of late rendering start (0.019%)
>    - 7 because of render times (0.015%)
> - 2224us average render time
> - 2000us median render time
> - 259s total 'unnecessary' latency
> - would've estimated render times too low in 88 frames (0.18%)
> - would've estimated 50+% too much render time in 43972 frames (91%)
- 15 000 us
> - total of 50195 frames
> - dropped 23 frames (0.046%)
>    - 2 because of too late commits (0.004%)
>    - 14 because of late rendering start (0.028%)
>    - 7 because of render times (0.014%)
> - 2081us average render time
> - 2000us median render time
> - 183s total 'unnecessary' latency
> - would've estimated render times too low in 71 frames (0.14%)
> - would've estimated 50+% too much render time in 21862 frames (44%)

hmm yeah I was more thinking about increasing it by 0.5ms, making it that high is not an option as it increases latency by a whole frame too. It not making much of a difference also means that the commit thread isn't the problem.

If you increase the "1ms" in https://invent.kde.org/plasma/kwin/-/blob/2340470a9a298e1bdb157a3cd4cc948727d3f657/src/core/renderloop.cpp#L55 a bit instead, does that help as well?

Though I see you're already at less than 0.1% of frames being dropped; a few dropped frames is always expected because that just happens when CPU or GPU load suddenly and unexpectedly increase a bunch. So idk if we can improve things a lot for you specifically.

Increasing the 1ms extra is the same deal; it helps but I need to make it very high.
so it doesn't seem to be related to dropped frames.
> - total of 42978 frames
> - dropped 105 frames (0.24%)
>     - 87 because of too late commits (0.2%)
>     - 12 because of late rendering start (0.028%)
>     - 6 because of render times (0.014%)
But my issue isn't stuttering due to dropped frames per se; it's that the frame rate drops to 30fps for long periods of time, like a starved double-buffered vsync, unless I (apparently) add myself a frame of latency or turn off triple-buffering altogether, and only at 60Hz. and somehow this doesn't show in the perf stats.

if there's no obvious solution to this I can just disable tb indefinitely, but it's still a weird issue.

looking at RenderLoopPrivate::scheduleRepaint more closely it seems that if I make the safety margin

Sorry, ignore that.

*** Bug 490358 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6168

Does the halved refresh rate issue go away with that MR?

I think I found the core of the issue, and I added a commit to the linked MR that I'm relatively confident should finally actually fix this bug. Please test it!

Testing with the new patches I no longer see the drops to 30fps that I saw previously, so that part seems fixed to me.  I'm still getting some stuttering that I wasn't previously with Plasma 5.x though, so I'm going to re-open https://bugs.kde.org/show_bug.cgi?id=490358.

Git commit 457b3a47ffe91b335ab18170cfb830d35217b9a8 by Xaver Hugl.
Committed on 26/07/2024 at 12:59.
Pushed by zamundaaa into branch 'master'.

core/renderloop: don't move the target presentation timestamp back when rescheduling

Re-doing the frame scheduling for an already scheduled composite cycle was meant to
adjust to small timing changes in the presentation timestamp, but if the expected
compositing time was close to vblank, it could happen that this would instead move
the target presentation timestamp and effectively drop a frame.

To fix that, this commit makes the presentation timestamp be adjusted only to be more
accurate, but still target the same vblank interval.

M  +11   -1    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/457b3a47ffe91b335ab18170cfb830d35217b9a8

Git commit d0f0481860ca0d8ebb88121c61544fbdc7a04d2f by Xaver Hugl.
Committed on 26/07/2024 at 12:59.
Pushed by zamundaaa into branch 'master'.

core/renderloop: fix triple buffering hysteresis

The way it was implemented it only changed the target pageflip, but not the time at which
KWin would start compositing, which could make it skip scheduling a frame for each second
vblank and drop the refresh rate to half of what it should be that way

M  +2    -0    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/d0f0481860ca0d8ebb88121c61544fbdc7a04d2f

Git commit 7b8f24698f797143531f0d5723cc6c263b9175e8 by Xaver Hugl.
Committed on 26/07/2024 at 13:10.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core/renderloop: don't move the target presentation timestamp back when rescheduling

Re-doing the frame scheduling for an already scheduled composite cycle was meant to
adjust to small timing changes in the presentation timestamp, but if the expected
compositing time was close to vblank, it could happen that this would instead move
the target presentation timestamp and effectively drop a frame.

To fix that, this commit makes the presentation timestamp be adjusted only to be more
accurate, but still target the same vblank interval.

M  +11   -1    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/7b8f24698f797143531f0d5723cc6c263b9175e8

Git commit aad82e9c772d52e853e7fa36a97620e41172df95 by Xaver Hugl.
Committed on 26/07/2024 at 13:10.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core/renderloop: fix triple buffering hysteresis

The way it was implemented it only changed the target pageflip, but not the time at which
KWin would start compositing, which could make it skip scheduling a frame for each second
vblank and drop the refresh rate to half of what it should be that way

M  +2    -0    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/aad82e9c772d52e853e7fa36a97620e41172df95