The situation on KDE/Kwin/Plasma performance
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... [b]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) ?[/b] 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 [b]animations are very inconsistent[/b]. 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 [b]significantly more consistent[/b]. 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 [b]occasional stutter[/b]. 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 [b]input latency[/b], cf. https://wiki.archlinux.org/index.php/Talk:NVIDIA/Troubleshooting 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 : https://bugs.kde.org/show_bug.cgi?id=322060 Bug 322060 - Synced swapping on double buffered nvidia GPUs cause high CPU load Reported in 2013.
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. https://wiki.archlinux.org/index.php/Talk:NVIDIA/Troubleshooting
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 : https://bugs.kde.org/show_bug.cgi?id=322060

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

#1
Posted 02/03/2018 08:48 PM   
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.
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.

GPU: EVGA 980Ti FTW
CPU: Core i5 2500K
PSU: Corsair HX650
MB: MSI P67A-C43 (B3)
RAM: 16GB DDR3 1600
Sound: Asus Xonar D1 PCI
Monitor: ViewSonic XG2703-GS
OS: Gentoo Linux AMD64 / Windows 10 x64

#2
Posted 02/08/2018 09:10 PM   
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.
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.

#3
Posted 02/10/2018 05:02 PM   
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.
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.

Dell Precision M4700
Intel QM77 chipset
Core i7 3940XM (with Intel HD4000 graphics)
Nvidia Quadro K2000M (Geforce GT650m equivalent)
16 GB DDR3 1600 ram
Windows 10 Pro 1709
Arch Linux with KDE Plasma

#4
Posted 02/10/2018 05:27 PM   
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 ?
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 ?

#5
Posted 02/10/2018 05:32 PM   
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: https://blog.martin-graesslin.com/blog/2017/10/plasmawayland-and-nvidia-2017-edition/ 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.
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: https://blog.martin-graesslin.com/blog/2017/10/plasmawayland-and-nvidia-2017-edition/ 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.

#6
Posted 02/10/2018 05:57 PM   
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.
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.

Dell Precision M4700
Intel QM77 chipset
Core i7 3940XM (with Intel HD4000 graphics)
Nvidia Quadro K2000M (Geforce GT650m equivalent)
16 GB DDR3 1600 ram
Windows 10 Pro 1709
Arch Linux with KDE Plasma

#7
Posted 02/10/2018 06:10 PM   
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.
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.

#8
Posted 02/10/2018 06:57 PM   
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.
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.

#9
Posted 02/10/2018 08:03 PM   
@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.
@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.

#10
Posted 02/10/2018 11:11 PM   
@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.
@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.

#11
Posted 02/11/2018 09:08 PM   
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.
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.

#12
Posted 02/17/2018 05:54 AM   
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. [b]My desktop gets quite unstable when forcing the composition pipeline[/b]. 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 !!
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 !!

#13
Posted 02/17/2018 04:37 PM   
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.
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.

#14
Posted 02/19/2018 12:33 PM   
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.
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.

#15
Posted 02/19/2018 12:40 PM   
Scroll To Top

Add Reply