The situation on KDE/Kwin/Plasma performance

Graphics / Linux Linux
1

Hi everyone !

First : I’m very grateful to NVIDIA for bringing for about 2 decades the best GPUs and providing us with constant & fast Linux support. Been using Nvidia since the post Voodoo 2 days… Riva TNT I think.

Now : I know this subject has probably been constantly brought up for a decade but…

Could an NVIDIA developer step in and tell us the situation on the desktop performance when using the Nvidia proprietary driver with the KDE Desktop (KWin/Plasma) ?

Here’s my experience which is apparently widespread. Please tell me if I’m wrong. Of course I’m referring to a Plasma 5 desktop with composition by it was already mostly true in Plasma 4 as well.

  1. by default, tearing occurs
  2. by default, kwin animations are jerky
  3. by default, CPU usage is very high

To work around those, one can either

  1. enable triple buffering
  2. set GL_YIELD=USLEEP
  3. force the (full or not) composition pipeline

However…

When applying 1) or 2), kwin animations are very inconsistent. From butter smooth to temporarily jerky. It feels “OK” but far from as good as it could be.

→ as a reference, I get a constant 60 FPS in all conditions with a super slow Intel HD 3000 or a more recent Intel HD 530… Nvidia GPU gets below that all the time. ←

When applying 3), KWin animations / desktop effects are significantly more consistent. Some desktop effects that were very slow before are OK now (i.e. : moving the window decoration to the top or side of the screen to maximize it) but I still get (less) frequent occasional stutter. I have absolutely none with an Intel HD Graphics for instance.

Still, the result I get with 3) is the best I got with the Nvidia driver. However it raises different issues like slowing down a lot the startup of KDE (15-20 seconds) when the Force(Full)CompositionPipieline is set in xorg.conf ; or displaying a black desktop (still active though) or when there is apparently some inconsistency with the KDE display settings, starting Steam with this option enabled freeze the screen (still active though…).

Last but not least, ForceFullCompositionPipeline is supposed to add input latency, cf. Talk:NVIDIA/Troubleshooting - ArchWiki
And also the following test fails : http://www.vsynctester.com/

So well… I know the main KWin developer kinda decided to stop making specific fixes for NVIDIA and also doesn’t test it himself anymore because it’s difficult for him to work with closed-source drivers, because in the past when he did it he created regressions elsewhere (and also because NVIDIA doesn’t support gbm for Wayland and the focus in now on Wayland). He’s doing a hell of a great job nonetheless and so do you.

My question is : what is the official situation about all this ? Are KDE users doomed ? I really want to continue buying from NVIDIA as in the past 20 years but it’s getting really frustrating ! A casual “joe” user just wouldn’t care and would probably just drop KDE or NVIDIA, which would be a real pity.

[Apart from that, games performance is stellar ! But of course I use my desktop way more than I play games :)

PS : reference : this KDE bug report : 322060 – Synced swapping on double buffered nvidia GPUs cause high CPU load

Bug 322060 - Synced swapping on double buffered nvidia GPUs cause high CPU load
Reported in 2013.

1 Like
2

Yeah. The experience on KDE/Plasma is somewhat poor when using NVidia. It is very difficult to tell where the issue is. Well, that’s an understatement, actually. In reality, we have absolutely no idea.

Are these KWin bugs? NVidia bugs? Both? Neither?

We just don’t know. All we can tell is that KWin developers are claiming that NVidia is not interested in working with them.

3

I’ve not had any issues with GL_YIELD=USLEEP on my 980ti running 2x 3840x2160 displays.

forcefullcompositionpipeline works great in KDE but causes me to get strange stuttering in games. Even though the FPS counter says 60fps, it feels jerky. Replacing it with GL_YIELD=USLEEP or vsync makes the games feel smooth again.

4

Yes GL_YIELD=USLEEP is smooth (at least was with 387.34) when applied to KWin while forcecomposition introduces micro stutter and causes other problems for me.

5

Strange, I get the opposite (390.x drivers though). For instance, BioShock is butter smooth when forcing composition pipeline but I don’t get a constant 60 FPS, depending on the scenes, with USLEEP. I kinda have the feeling the desktop is less stable with the former, which is another dilemma for me. Didn’t compare forcing composition pipeline with full composition pipeline.

But you both refer to games performance I guess. What about KDE desktop performance ? Consistency & smoothness of windows animations ? Here, and it’s been the case for years, it’s clearly not a constant 60 FPS and quite inconsistent (contrary to what I get with an old Intel GMA GPU for instance).

Do you all agree that 1) one still has to apply tweaks after many years 2) desktop is not as smooth as it should 3) we might never get wayland support for KDE ?

6

I’ve got terrible performance with 390.x (see the other thread) so can’t compare using them but with the earlier driver I never had any issues using USLEEP.

On the desktop animations are smooth, though I never have an FPS counter running.

I did have performance issues when I was using a 750ti. The 2gb VRAM just didn’t cut it even for desktop use with a 4k display. With more than a few applications open I’d have 60%+ VRAM usage. Switching virtual desktops would be jerky. Since I switched to the 980ti I can’t say I’ve noticed a single performance problem on the desktop.

Triggering a few animations now (3d cube, moving windows around, etc) everything seems perfectly smooth. No different to my intel graphics laptop.

The biggest issue for me is the lack of future wayland support. However, never say never. Although it’s unlikely nvidia will do anything. The kwin developer posted this: Plasma/Wayland and NVIDIA – 2017 edition – Martin's Blog which says

XWayland also uses gbm and does not have support for NVIDIA’s proprietary solution. Due to that one does not have OpenGL for any legacy X application. This probably includes most games, but currently also browsers such as Firefox and Chromium. I don’t think that this would give a satisfying experience to NVIDIA users. And it is also hardly better than rendering everything through the QPainter compositor. This is another reason for the KDE Community to not spend any time on implementing support for EGLStreams.

Since XWayland now support (or is working to support) nvidia, we might see some slow progress. Don’t expect to be running a wayland desktop any time soon.

If the next AMD video card is nearly comparable to nvidia’s in performance I’ll be switching next time around unless nvidia sort their drivers out.

7

Yes mahen, I agree on all 3 points you mention. My intel hd4000 maintains a full 60 fps and is buttery smooth all the time. The nvidia can also be as smooth as the intel and usually was (with pre 390 drivers). But it would depend on the effect as there would be some stutter with certain animations at times but at alternate times they would be fully smooth. Nvidia is unpredictable and doesn’t seem as well optimized for KWin.

Using USLEEP however meant that the apps themselves would be buttery smooth and without tearing. Keep in mind that you don’t use the desktop itself, you use other apps. So the rare stutter on desktop animations was an accepted tradeoff to me so long as other stuff runs perfectly and vsyncs without stutters.

That having been said, with my next computer being a high end desktop, built within 2 years, I’m going to go with AMD unless Nvidia makes major progress. These cards are around $1000 in Canada and for this kind of money you expect first class support which I don’t feel nvidia is delivering to Unix based users.

8

I have found that ForceCompositionPipeline is necessary to have Vsync working in Vulkan games. It is also necessary to have Vsync working in OpenGL, when you configure Kwin to suspend compositing when a fullscreen application asks (as most games do). __GL_YIELD=USLEEP and Vsync in nvidia-settings have zero effect on Vsync in my experience, and in most games the in-game option also tend to not work. In some games (e.g. The Talos Principle) the in-game option works half-way, i.e. it reduces tearing but does not eliminate it completely. My uneducated guess, it synchronizes to a wrong display. In those cases, the animation may look smoother but tearing is occasionally visible.

All in all, ForceCompositionPipeline seems to be the only way to reliably eliminate tearing completely, which is what I want.

9

Force composition pipeline introduces stuttering when the game si rendering more fps than the monitor refresh rate.
(I would tell that to nvidia devs, but i doubt they would put effort on this…)
So if the software doesnt limit fps per se, nor has an half worling vsync setting, you have to relay on an external compositor, paying a performance hit a bit higher than forcecompositionpipeline.
For opengl there is another solution that limits fps, it is libstrangle.
…or just go with usleep and kwin tearing prevention, but it is suboptimal. For me it is evident when watching videos.

10

@kokoko3k

Force composition pipeline introduces stuttering when the game si rendering more fps than the monitor refresh rate.

I don’t see any stuttering, just verified now with Talos. I disabled the in-game Vsync and I got >100 fps and a very smooth animation in the benchmark. No tearing either because of the ForceCompositionPipeline. I’m on 390.25, GTX980.

…or just go with usleep and kwin tearing prevention, but it is suboptimal.

I used to rely on Kwin, but it doesn’t help with tearing with Vulkan.

11

@Lastique

The micro-stutter seems to happen differently in different games. In both WoW and Skyrim under WINE I noticed it, and it’s not just when the FPS is greater than the monitor’s refresh rate. Getting 40fps in WoW under WINE feels like 20fps with force composition pipeline. Getting 40fps with it turned off feels much, much smoother. It’s hard to describe but it is immediately noticeable.

12

For Plasma users experiencing micro-stuttering in games: do you still get the micro-stuttering with compositing disabled? You can use SHIFT-ALT-F12 to toggle compositing on/off e.g. before starting the game to test.

If turning off compositing fixes the micro-stuttering, verify that System Settings → Hardware → Display and Monitor → Compositor → “Allow applications to block compositing” is enabled. With this setting enabled, most fullscreen games will suspend the compositor when running, but some won’t. For the games that don’t, you can make a window rule to block compositing per-game. I usually do this by temporarily running the game in windowed mode, then clicking the window menu button (app icon) at the top-left of the window border, and choosing More Actions → Special Application Settings…, then under Appearances, I set “Block compositing” to “Force” “Yes”, and then restart the game.

You can tell if compositing is blocked during a game by adjusting the volume using your system’s volume hotkeys. If the volume adjustment indicator has a drop shadow, then compositing is enabled. If there is no drop shadow, then compositing is disabled.

13

Thanks for the tips !

Yeah there are 2 subjects in one actually : micro-stuttering in KWin/Plasma (in my experience, there is less - but there still is more than there should - when forcing the composition pipeline than when using GL_YIELD. And the second subject is games performance : most games disable the composition automatically but some don’t. Also I have better performance when forcing the composition as well. Well, I got no obvious improvement in TR benchmark for instance, but the difference was tremendous in Bioshock Infinite…

BUT that raises yet another issue.

My desktop gets quite unstable when forcing the composition pipeline. Flickering stuff (black areas for a fraction of a second). Sometimes it even restarts kwin. Did you notice it too ? I used to think that would happen more when setting the “force composition pipeline” in xorg.org (contrary to setting it with nvidia-settings at startup). What is your experience ? Did you find a difference between como pipeline and full compo pipeline ?

ALSO I’m looking for a tip because I need to apply this option to my both screens that are mirrored (DVI & HDMI). I found the right syntax for xorg.conf but not from the nvidia-settings command line.

When I set it only on one screen, there is tearing on the second one.

All this is so much more complicated that it should !!

14

For me, __GL_YIELD=USLEEP combined with enabling vsync in System Settings and in all games, plus “sync to vblank” in Nvidia settings seems to solve tearing and (almost all) stutter. For the remaining microstutter, which is seldom, it’s hard to say whether it comes from the game engine.

Where do you set __GL_YIELD=USLEEP? I did it in ~/.config/plasma-workspace/env/kwin.sh so I would be sure it’s early enough.

I tried games that are very sensitive to stutter in this context like autoscrolling vertical shoot-em-ups in MAME, displayed via OpenGL. From things scrolling by at a constant rate it’s very easy to find stutter, and it’s rare. Autoscrolling 3D games like Sky Force Anniversary are also good for testing this. There is a bit of stutter there as well but not nearly as bad as it seems to be for some of you.

ForceFullCompositionPipeline introduces heavy stutter and what feels like very uneven frame pacing and makes all games unplayable and the desktop jerky.

This is 390.25 with a GTX 1060, Debian 9 with Plasma 5.8.6, kernel 4.9.

15

Hi !
I set GL_YIELD=USLEEP in /etc/profile.d/kwin.sh
Well, I have no idea why our experiences differ. I’m using Neon with Plasma 5.12.1 and kernel 4.13 so that’s quite a lot of differing factors. Here when using USLEEP simple desktop effects like windows reduction is super jerky.

I thought GNOME was not affected by the variable framerate (on the desktop) but that’s apparently not the case. I quickly tested Manjaro Gnome with proprietary nvidia drivers. It was OK but desktop effects were not constantly perfectly smooth. I double-checked in a recent Ubuntu + GNOME. It’s not butter smooth either. It only gets better under both GNOME & NVIDIA with the Intel HD open source drivers.

At least, no tweak is required under GNOME.

16

-EDIT-
Wrong thread, sorry.

17

BTW, did you also people notice than when setting Force[Full]CompositingPipeline in xorg.conf, the KDE startup would taken 15-20 more seconds ? (considering it’s quasi-instant otherwise)

18

There seems to be yet another issue with KDE + NVIDIA. Can you people please confirm if you encounter it ?

Sometimes (every couple of days here), when some apps suspend compositing, the KDE panel freezes. It can still be clicked and is definitely active, but there’s not visual response anymore.

cf. : 353983 – Turning off compositing breaks Plasma panel rendering

I noticed, once in a while, that starting Steam would trigger a notification according to which my desktop effects were re-initialized. Last time the bug occured, it was a couple of minutes after that.

This is super annoying :-) And yet another proof KDE is treated as a second class citizen. Probably because of the rough edges and bugs of the post KDE3 era and the fact most major distros dropped it by default… But KDE recovered very well meanwhile :)

19

The panel not updating anymore is a common problem for me. I solve it by switching desktop effects on again (usually it freezes when something, like Steam or a game, has disabled desktop effects).

20

I had cases of not updating panel after a few days of uptime, and I also had the option to allow to suspend compositing disabled at the time. It didn’t require me to run a game or anything special when that had happened. But it seems to not happen lately, after I upgraded to Kubuntu 17.10 or maybe a newer Nvidia driver.