Bug 344433

Created attachment 91204 [details]
Output of "qdbus org.kde.kwin /KWin supportInformation"

please try
   KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &

regarding the double buffer situation:
what's the output of
   tr '\0' '\n' < /proc/`pidof kwin_x11`/environ | grep __GL_YIELD

Thanks for the quick response!  KWIN_EXPLICIT_SYNC=0 has no effect; I still get the jerkiness in exactly the same manner.  The output of the other command is "__GL_YIELD=USLEEP".  I set that value manually when I put it in double-buffering mode because I know I will get tearing without it.

I have also noticed that if I start glxgears immediately after the system boots, it will run smoothly for 30-45 seconds before it gets jerky.

This is still happening with kwin 5.2.2.

This is still happening and has actually gotten significantly worse with Kwin 5.3.

can you check what happens if you add

RefreshRate=60

to the [Compositing] section of ~/.config/kwinrc?

I recently get a RR of 50Hz reported, what leads to a slow repaint interval, systematiclly missing every second frame.

Thanks, that clears up the new jerkiness that was introduced in 5.3.  Now it is back to the same jerkiness as in 5.2.

I printed some timings and every now and then the painting lasts far to long (> 20ms where it's usually < 4ms)

Doesn't seem related to special effects (turned off blur & contrast), but might be due to interference with X11 - it's however not (explicitly) due to KWIN_EXPLICIT_SYNC - or we flood the buffer (ie. occasionally swap too fast, causing more than 3 frames in the pipe, thus an unexpected blocking sync)

Not seeing blocking swaps, what seems to take most of the time is
GLVertexBuffer::streamingBuffer()->endOfFrame();

The pattern seems roughly "1-2" SceneOpenGL::paint() calls that take > 4ms followed by one where the glFenceSync() call takes > 16ms

This is still going on with kwin 5.3.2 and NVIDIA 355.06.

I think I experience the same bug. I can fix it by setting MaxFPS and RefreshRate to 70 in kwinrc as described in another bug report but this leads to windows lagging behind the mouse cursor when moving them.

Another bug report that might be the same bug.
https://bugs.kde.org/show_bug.cgi?id=351700

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

I was able to reproduce the problem on an Intel Haswell iGPU. However, there was much less stutter than on my NVIDIA card. On the Haswell iGPU, the stutter was almost unnoticeable. Still, I was able to reproduce stutter with triple buffering enabled that did not occur without it, so it might be better to disable triple buffering especially on the hardware that has serious stutter if feasible.

Created attachment 116314 [details]
video for testing 60fps playback

Attached is a great video for testing 60fps playback. It is very easy to see when frames are dropped with compositing enabled vs. disabled. Original video here: https://www.youtube.com/watch?v=Cyxixzi2dgQ

I prefer to test using the webm file in VLC, as I find VLC's playback to be more consistent than YouTube.

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

This issue should be solved in 5.18 with patches in:
https://phabricator.kde.org/T11071.

There will be no more KWin "triple buffering" available, instead everything hopefully just works right away without any configuration necessary. If it doesn't reopen.

You can also build KWin from master to test the current state. (there is one patch missing yet though for optimizing the Nvidia case).

I would give it a try, but building master fails:

kwin/effects/startupfeedback/startupfeedback.cpp: In Elementfunktion »virtual void KWin::StartupFeedbackEffect::reconfigure(KWin::Effect::ReconfigureFlags)«:
kwin/effects/startupfeedback/startupfeedback.cpp:125:39: Fehler: »class KConfigWatcher« hat kein Element namens »config«
  125 |     KConfigGroup c = m_configWatcher->config()->group("FeedbackStyle");
      |                                       ^~~~~~
kwin/effects/startupfeedback/startupfeedback.cpp:128:26: Fehler: »class KConfigWatcher« hat kein Element namens »config«
  128 |     c = m_configWatcher->config()->group("BusyCursorSettings");
      |                          ^~~~~~
make[2]: *** [effects/CMakeFiles/kwin4_effect_builtins.dir/build.make:1202: effects/CMakeFiles/kwin4_effect_builtins.dir/startupfeedback/startupfeedback.cpp.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet....
make[1]: *** [CMakeFiles/Makefile2:4372: effects/CMakeFiles/kwin4_effect_builtins.dir/all] Fehler 2
make: *** [Makefile:130: all] Fehler 2
==> FEHLER: Ein Fehler geschah in build().
    Breche ab...

Yea, you need other projects to be built from master as well. It's easy for example on KDE Neon Dev Unstable edition and Manjaro with kwin-git package.

That sounds awesome, thanks for the work!  I do have one question though.  I noticed in there one of the changes you made was to make KWIN_USE_INTEL_SWAP_EVENT default to 1.  I have actually tried this with 5.17.x and it usually makes my framerate fall to 30 or 40 FPS instead of 60.  Has the rest of your work fixed that, or will I have to force it back off?

(In reply to Michael Marley from comment #20)
> That sounds awesome, thanks for the work!  I do have one question though.  I
> noticed in there one of the changes you made was to make
> KWIN_USE_INTEL_SWAP_EVENT default to 1.  I have actually tried this with
> 5.17.x and it usually makes my framerate fall to 30 or 40 FPS instead of 60.
> Has the rest of your work fixed that, or will I have to force it back off?

The compositing pipeline has been fully overhauled so you can't guess from 5.17 behavior to how it will work in 5.18.

Of course if you can try it on master and report back if it's fine there or you have a similar problem, that would be very helpful.

OK, I will see if I can find time to test it with the Kubuntu automated nightly PPAs or something of that sort.  Thanks again!

I went through dependency hell and compiled recent kwin git-master on Arch.
Indeed, the stutter issue seems to be completely gone, just like it previously was when using the intel swap event feature.

There is one issue though, which is similar to the freezing issues of previous intel swap event setting: When I change animation speed or window shadow properties in system settings, KWin compositing freezes to death and turns black. Sometimes the desktop can still be accessed by turning off compositing via shift + alt + F12, but sometimes one is completely locked out.

I remember that previously intel swap event could freeze when turning compositing on or off, this hasn't yet occurred. Would need more testing to be certain though.

Could instantly make it freeze by starting a fullscreen game, turning compositing off via hotkey and then re-enable it.

(In reply to tempel.julian from comment #24)
> Could instantly make it freeze by starting a fullscreen game, turning
> compositing off via hotkey and then re-enable it.

Thanks for testing! Please open a new bug report for that and mention what hardware you are testing it with. I will try to reproduce it asap. There were a multitude of changes to the compositing pipeline so it might be unrelated to intel swap event.

Here we go:
https://bugs.kde.org/show_bug.cgi?id=415262

So I have done some more testing and I have found that the frame-rate-halving issue I reported with KWIN_USE_INTEL_SWAP_EVENT earlier affects only that one system and none of my others.  On the others, the result is actually rather amazing, dramatically reducing input lag and stuttering and eliminating micro-stuttering.  For that one problematic system, I have also had other frame rate and stuttering-related issues, so I think there must be something specific to that system.  Sorry for the noise, and again, thanks for the work!

(In reply to Michael Marley from comment #27)
> So I have done some more testing and I have found that the
> frame-rate-halving issue I reported with KWIN_USE_INTEL_SWAP_EVENT earlier
> affects only that one system and none of my others.  On the others, the
> result is actually rather amazing, dramatically reducing input lag and
> stuttering and eliminating micro-stuttering.  For that one problematic
> system, I have also had other frame rate and stuttering-related issues, so I
> think there must be something specific to that system.  Sorry for the noise,
> and again, thanks for the work!

Thank you, but if I understood you correctly you were testing it with 5.17 on these systems, right? Or did you test it with KWin from master branch?

Yep, that's still with 5.17.  I was just reporting back to make sure you knew not to worry about my problem, since it seems specific to that one computer I have.

Roman, I'm now with Plasma 5.17.90-1 from Arch KDE unstable repo, and unlike with my previous git-master builds, the issue is not fixed. It's like with 5.17.

Ok, I found the revert commits and your comment about it:
https://mail.kde.org/pipermail/kwin/2020-January/002999.html

Well, now KWin compositing is back to totally unusable. :(

Yeah, that's quite disappointing.  I was looking forward to this patchset quite a bit.

I have found, though, that many of the same benefits of the patchset can be acquired simply by setting "export KWIN_USE_INTEL_SWAP_EVENT=1" before starting kwin.

Roman, even if the rest of the patchset is completely dead, is there any chance of getting the patch for fixing the problem where the screen blacks out when toggling compositing with swap events enabled?

Sorry for not having the patches in 5.18. The patchset is not dead. In my opinion it was fine, but there are organizational issues with KWin development I want to have solved before I commit myself to any more large changes like this that also always induce the risk of breaking things.

would it still be possible to include a fix for the freezes with KWIN_USE_INTEL_SWAP_EVENT=1, as proposed by Michael Marley?
That would probably be quite helpful already.

The PoC patch still works for current kwin git-master:
https://bugs.kde.org/show_bug.cgi?id=415262
With that applied, intel_swap_event really seems to work nicely in KWin compositing, as far is I can tell.

May I ask if it is possible to land this rework for 5.19?

See also https://subdiff.org/blog/2020/the-k-win-ft-project/

I have been noticing occasionally screen tearing when scrolling in Firefox with different KDE setups and versions on I think both NVIDIA and Intel graphics. Just confirmed it with Intel and KDE 5.19 on Wayland.

After doing some searching, I landed on this issue. I only don't really know whether this is also causing the problems I see or whether that is a different issue. Thought I will ask here first before creating a new issue for it.

Performance issues this old are likely fixed or are better suited to a new ticket if issues remain.