Bug 362312 - Tearing with nvidia driver
Summary: Tearing with nvidia driver
Status: RESOLVED DUPLICATE of bug 343184
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 5.5.5
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2016-04-26 16:24 UTC by witheld
Modified: 2016-04-26 21:31 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Output of qdbus org.kde.KWin /KWin supportInformation (3.48 KB, text/plain)
2016-04-26 16:44 UTC, witheld
Output of glxinfo (56.14 KB, text/plain)
2016-04-26 16:46 UTC, witheld
Output of glxinfo (53.98 KB, text/plain)
2016-04-26 17:03 UTC, witheld
Output of qdbus org.kde.KWin /KWin supportInformation (5.40 KB, text/plain)
2016-04-26 17:03 UTC, witheld
Xorg.0.log (25.24 KB, text/x-log)
2016-04-26 17:15 UTC, witheld

Note You need to log in before you can comment on or make changes to this bug.
Description witheld 2016-04-26 16:24:14 UTC
The kwin compositor has been getting worse with every release, and as of 5.5.5, there is no way to stop tearing with any version of the nvidia driver. With both OpenGL 3.1 and 2.0 all methods of vsync fail spectacularly and generally make tearing worse.

Reproducible: Always

Steps to Reproduce:
1. Enable vsync
2. Do something that might induce tearing like playing a game, scrolling, or dragging a window around the screen

Actual Results:  
The application experiences massive tearing

Expected Results:  
There is no tearing, because vsync is working
Comment 1 Thomas Lübking 2016-04-26 16:29:54 UTC
There's been no change to kwin at all, but I get massive tearing in VDPAU and OpenGL *uncomposited* (and under fluxbox) as well w/ 364.16 - very likely a driver regression.
Comment 2 witheld 2016-04-26 16:36:12 UTC
Update: this also occurs with the open source drivers, it seems that vsync has just been completely and totally destroyed. It also breaks vsync in other applications. I've simple been forced to disable the compositor.
Comment 3 witheld 2016-04-26 16:37:13 UTC
(In reply to Thomas Lübking from comment #1)
> There's been no change to kwin at all, but I get massive tearing in VDPAU
> and OpenGL *uncomposited* (and under fluxbox) as well w/ 364.16 - very
> likely a driver regression.

It occurs in both the open source and closed source drivers and any version of the closed source drivers I've tried
Comment 4 Thomas Lübking 2016-04-26 16:38:12 UTC
please attach the outputs of "qdbus org.kde.KWin /KWin supportInformation" and glxinfo.
Comment 5 witheld 2016-04-26 16:44:56 UTC
Created attachment 98619 [details]
Output of qdbus org.kde.KWin /KWin supportInformation
Comment 6 witheld 2016-04-26 16:46:02 UTC
Created attachment 98620 [details]
Output of glxinfo
Comment 7 witheld 2016-04-26 16:49:23 UTC
I've switched to Compton for the time being, since it works
Comment 8 Thomas Lübking 2016-04-26 16:56:54 UTC
the supportinfo is worthless since the compositor is suspended and the glxinfo suggests you're neither on nouveau nor nvidia, but a software rasterizer...
Comment 9 witheld 2016-04-26 17:03:26 UTC
Created attachment 98621 [details]
Output of glxinfo
Comment 10 witheld 2016-04-26 17:03:51 UTC
Created attachment 98622 [details]
Output of qdbus org.kde.KWin /KWin supportInformation
Comment 11 witheld 2016-04-26 17:07:15 UTC
More interesting note, it seems that vsync does work correctly for about 15 seconds after turning it on
Comment 12 witheld 2016-04-26 17:09:23 UTC
Oh, I figured it out! vsync breaks as soon as you move any windows, 100% of the time it works until you move a window!
Comment 13 witheld 2016-04-26 17:10:22 UTC
Nevermind, it's true that it breaks when you move a window, but it breaks a few moments later anyway
Comment 14 Thomas Lübking 2016-04-26 17:12:57 UTC
> glPreferBufferSwap: 0

swapcontrol is disabled, likely due to the triplebuffer issues.

please attach /var/log/Xorg.0.log

you can probably enforce the non-blocking path; last time i checked, nvidia didn't even block doublebuffered:

please notice that only one screen will be synced (usually the primary one), that's a hw limitation.
Comment 15 witheld 2016-04-26 17:15:16 UTC
Created attachment 98623 [details]
Comment 16 witheld 2016-04-26 20:40:32 UTC
I'm not understanding how to do what you said
Comment 17 Thomas Lübking 2016-04-26 21:31:48 UTC
Nouveau won't support HW GL for your GPU (requires bleeding edge linux + mesa) - if KWin enables the compositor at all (w/o being forced to) it will resort to xrender to not composite on your CPU.

For nvidia, vsync gets enabled because it's only double buffering what caused bug #322060 (this is probably no longer the case as long as the driver magically doesn't block on double buffering)

Either enable triple buffering for the nvidia driver¹ or prevent the driver from waiting busily²

Actually™ because of the "usually" non-blocking double buffering, this should happen automatically, but for some odd reason the detection tends to fail on logins (bug #343184)

If and as long as the nvidia driver doesn't block in the double buffering case, it's ok to "cheat" on this and make kwin believe this is triple buffering while it's not (but the relevant behavior matches)³
Notice that this is some unexplained behavior in the driver which may change at any time.

[1] /etc/X11/xorg.conf.d/20-nvidia.conf 
Section "Device"
    Identifier "Default nvidia Device"
    Driver      "nvidia"
    Option      "NoLogo"                                "True" # no spam
    Option  "CoolBits"                              "1" # more options in nvidia-settings?
    Option  "TripleBuffer"                  "True" # this is the relevant entry

[2]  ~/.config/plasma-workspace/env/gl_yield.sh
export __GL_YIELD="USLEEP"

ensure to "chmod +x ~/.config/plasma-workspace/env/gl_yield.sh"

[3]   ~/.config/plasma-workspace/env/kwin_force_tb.sh

ensure to "chmod +x ~/.config/plasma-workspace/env/kwin_force_tb.sh"

*** This bug has been marked as a duplicate of bug 343184 ***