Bug 344433 - SceneOpenGL::paint() occasionally lasts > 16ms (triple buffering enabled)
Summary: SceneOpenGL::paint() occasionally lasts > 16ms (triple buffering enabled)
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kwin
Classification: Plasma
Component: scene-opengl (show other bugs)
Version: 5.17.90
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 386333 397850 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-21 20:41 UTC by Michael Marley
Modified: 2024-05-14 21:33 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Output of "qdbus org.kde.kwin /KWin supportInformation" (4.54 KB, text/plain)
2015-02-21 20:41 UTC, Michael Marley
Details
video for testing 60fps playback (2.80 MB, video/webm)
2018-11-14 20:20 UTC, S. Christian Collins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Marley 2015-02-21 20:41:16 UTC
If I use kwin 5.2 on a system with an Nvidia graphics card using the binary drivers and with triple buffering enabled in Xorg.conf (and forced in kwin using "export KWIN_TRIPLE_BUFFER=1"), I get jerky animations from all applications.  It is more noticeable for 3D applications like glxgears, but happens with 2D things like Firefox scrolling as well.  The jerks occur at seemingly random intervals.  It might be smooth for a few seconds and then drop several frames within a few more seconds.  (The system is otherwise idle during the test.)

This same setup was completely smooth in kwin 4.x.  Also, if I disable triple buffering in Xorg.conf (and remove the "export KWIN_TRIPLE_BUFFER=1") it becomes smooth again with kwin 5.  Forcing buffer_age on or off with export KWIN_USE_BUFFER_AGE has no effect.

I have been able to reproduce this issue on three different systems, all running Kubuntu 15.04 x86_64.  One has a Quadro NVS 5400m with driver 346.35, one has a GeForce 9500GT with driver 340.76, and the last has an 8600m GT also with driver 340.76.

Reproducible: Always
Comment 1 Michael Marley 2015-02-21 20:41:52 UTC
Created attachment 91204 [details]
Output of "qdbus org.kde.kwin /KWin supportInformation"
Comment 2 Thomas Lübking 2015-02-21 21:42:31 UTC
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
Comment 3 Michael Marley 2015-02-21 22:34:31 UTC
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.
Comment 4 Michael Marley 2015-02-25 13:18:16 UTC
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.
Comment 5 Michael Marley 2015-03-26 13:12:16 UTC
This is still happening with kwin 5.2.2.
Comment 6 Michael Marley 2015-05-02 16:53:18 UTC
This is still happening and has actually gotten significantly worse with Kwin 5.3.
Comment 7 Thomas Lübking 2015-05-02 22:22:08 UTC
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.
Comment 8 Michael Marley 2015-05-03 00:22:32 UTC
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.
Comment 9 Thomas Lübking 2015-05-03 19:46:29 UTC
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)
Comment 10 Thomas Lübking 2015-05-03 22:28:44 UTC
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
Comment 11 Michael Marley 2015-08-13 12:44:25 UTC
This is still going on with kwin 5.3.2 and NVIDIA 355.06.
Comment 12 Steffen Coenen 2017-09-01 13:53:50 UTC
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
Comment 13 Martin Flöser 2017-10-30 06:43:43 UTC
*** Bug 386333 has been marked as a duplicate of this bug. ***
Comment 14 Steffen Coenen 2017-10-30 13:31:39 UTC
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.
Comment 15 S. Christian Collins 2018-11-14 20:20:10 UTC
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.
Comment 16 Nate Graham 2019-12-01 19:30:33 UTC
*** Bug 397850 has been marked as a duplicate of this bug. ***
Comment 17 Roman Gilg 2019-12-16 18:21:18 UTC
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).
Comment 18 tempel.julian 2019-12-16 18:46:29 UTC
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...
Comment 19 Roman Gilg 2019-12-16 18:49:04 UTC
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.
Comment 20 Michael Marley 2019-12-16 18:59:28 UTC
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?
Comment 21 Roman Gilg 2019-12-16 19:08:36 UTC
(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.
Comment 22 Michael Marley 2019-12-16 19:09:58 UTC
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!
Comment 23 tempel.julian 2019-12-16 20:00:49 UTC
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.
Comment 24 tempel.julian 2019-12-16 20:07:32 UTC
Could instantly make it freeze by starting a fullscreen game, turning compositing off via hotkey and then re-enable it.
Comment 25 Roman Gilg 2019-12-16 20:28:53 UTC
(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.
Comment 26 tempel.julian 2019-12-16 21:25:58 UTC
Here we go:
https://bugs.kde.org/show_bug.cgi?id=415262
Comment 27 Michael Marley 2019-12-16 23:58:58 UTC
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!
Comment 28 Roman Gilg 2019-12-17 00:33:53 UTC
(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?
Comment 29 Michael Marley 2019-12-17 00:48:40 UTC
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.
Comment 30 tempel.julian 2020-01-16 19:02:45 UTC
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.
Comment 31 tempel.julian 2020-01-17 09:48:52 UTC
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. :(
Comment 32 Michael Marley 2020-01-17 11:48:12 UTC
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?
Comment 33 Roman Gilg 2020-01-18 10:13:57 UTC
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.
Comment 34 tempel.julian 2020-01-18 11:25:22 UTC
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.
Comment 35 tempel.julian 2020-01-18 14:00:31 UTC
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.
Comment 36 tempel.julian 2020-04-11 11:42:38 UTC
May I ask if it is possible to land this rework for 5.19?
Comment 37 Christoph Feck 2020-05-10 14:05:01 UTC
See also https://subdiff.org/blog/2020/the-k-win-ft-project/
Comment 38 Claudius Ellsel 2020-06-12 11:50:35 UTC
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.
Comment 39 David Edmundson 2024-05-14 21:33:24 UTC
Performance issues this old are likely fixed or are better suited to a new ticket if issues remain.