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.

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.

(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

please attach the outputs of "qdbus org.kde.KWin /KWin supportInformation" and glxinfo.

Created attachment 98619 [details]
Output of qdbus org.kde.KWin /KWin supportInformation

Created attachment 98620 [details]
Output of glxinfo

I've switched to Compton for the time being, since it works

the supportinfo is worthless since the compositor is suspended and the glxinfo suggests you're neither on nouveau nor nvidia, but a software rasterizer...

Created attachment 98621 [details]
Output of glxinfo

Created attachment 98622 [details]
Output of qdbus org.kde.KWin /KWin supportInformation

More interesting note, it seems that vsync does work correctly for about 15 seconds after turning it on

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!

Nevermind, it's true that it breaks when you move a window, but it breaks a few moments later anyway

> 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:
https://community.kde.org/KWin/Environment_Variables#KWIN_TRIPLE_BUFFER

please notice that only one screen will be synced (usually the primary one), that's a hw limitation.

Created attachment 98623 [details]
Xorg.0.log

I'm not understanding how to do what you said

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
EndSection


[2]  ~/.config/plasma-workspace/env/gl_yield.sh
#!/bin/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
#!/bin/sh
export KWIN_TRIPLE_BUFFER=1

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

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