KWin shows tearing despite of VSync

[enteon ente]

Since at least Version 4.8 KWin has a bug that creates a region of tearing in the upper part of the display. This just got worse in 4.9 and thus Ubuntu 12.10.

This bug is already filed in KDE bug tracker but is so grave that it destroys the whole user experience.
The initial patch is not big, please backport it to 4.9 and update the repository.

KDE bug: https://bugs.kde.org/show_bug.cgi?id=307965
Patch: http://bugsfiles.kde.org/attachment.cgi?id=74617

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

Problem occurs with Kubuntu 12.04 and got worse with kubuntu 12.10 beta 2.
Default settings (using an usb image to try out Kubuntu 12.10)

Using Intel sandy bridge graphics 2500k processor.
(Problem does not occur on my dell Studio XPS laptop with intel i965 graphics)
When I move a window horizontally the top part is displaced 2-8 mm depending upon the speed of moving.
This problem only occurs with the part of the window that is above a certain height on the screen
Kubuntu 12.04: problem occurs only in top of display (about the height of a window title bar)
Kubuntu 12.10: problem occurs in top 1/6th of the screen.

With Kubuntu 12.10 the problem becomes much more visible.
You notice tearing on a large part of a window that is in thu opper part of the display.

The effect disappears when I turn off vsync in System Settings - Desktop Effects.
(But now the moving is not as smooth on other parts of the screen as with vsync on.)

Reproducible: Always

Steps to Reproduce:
1.start kde
2.drag a window horizontally accross the top part of the screen
3.
Actual Results:
tearing

Expected Results:
smooth

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

Created attachment 74373
my xorg log file

Just so you know what driver etc.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

Tested it also with a recent fedora beta (USB boot) and the problem does not occur there.
It seems kde-specific. I realize there is not a lot of information in this remark but I guess
all observations are useful :-)
Thanks for a great great job on kwin, I can not say enough how happy I am with it!

[Mgraesslin (mgraesslin)]

I do not understand comment #2. If it does not occur with Fedora it rather seems Kubuntu specific, doesn't it?

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

Hallo Martin,

I was not clear. I meant to say: Fedora with a prerelease of gnome 3.6.
So the problem seems KDE related, not specifically Kubuntu-related.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

I just downloaded and tried Fedora 18 alfa, with KDE 4.9.0.0.
Same problem as with Kubuntu 12.10
We can say now that it is a KDE (kwin?) / intel driver problem.

[Thomas-luebking (thomas-luebking)]

About the same as the nvidia related tearing?

@John, can you record a video of this?

This https://bugzilla.gnome.org/show_bug.cgi?id=651312#c37
claims that you cannot blit during the retrace - if that was true, we can either move to full repaints (eventually by copying the front to the backbuffer for the undamaged parts?) and buffer swapping or mark all tearing bugs as wontfix.

ftr:
I have doubts on this claim, the memory amount would be rather small and also the only thing, i get tearing in the upper fraction with, is GL contents, there's claim about videos as well, but not here. However i have *never* seen tearing by just moving some windows, yet we've seen a video where this happened and the "tearing" was actually more like "paints with 500ms delay" - and that's not tearing

[Thomas-luebking (thomas-luebking)]

WOW, wait:
[ 22.590] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 22.590] (II) Module intel: vendor="X.Org Foundation"
[ 22.590] compiled for 1.11.3, module version = 2.17.0

Can you please try a somewhat recent driver for a sandybridge chip (2.17 is nearly a year old) - ideally an SNA one?

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

I created a video with the webcamoid, handholding my webcam.
It shows the tearing problem at the very top of the display.
And no tearing somewhat below this.
This is for kubuntu 12.04.

You can find the video at:
http://www.vanspaandonk-koks.nl/open_source/tearing%20problem%20intel%20sandy%20bridge%20kubuntu%2012.04.webm

perhaps you need to replace the %20 by spaces.
I used firefox - save page as - and then watched the video offline.

I hope you trust me when I say that on kubuntu 12.04 the tearing starts at a lower part of the screen.
I will start fedora alfa 18 kde from my usb now and report back the version of the video driver used there.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

Fedora 18 alfa, booted clean from usb excerpt fro /var/log/Xorg.o.log
BTW this uses kernel 3.6RC2

FYI: the "tearing" I showed on the video is (vertically) twice as large as
with kubuntu 12.04.
If you need any more just let me know, I am anxious to help solve this
problem. BTW do any of you use sandy bridge graphics???

[ 20.584] (II) LoadModule: "intel"
[ 20.585] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
[ 20.631] (II) Module intel: vendor="X.Org Foundation"
[ 20.631] compiled for 1.12.99.903, module version = 2.20.2
[ 20.632] Module class: X.Org Video Driver
[ 20.632] ABI class: X.Org Video Driver, version 13.0
[ 20.632] (II) LoadModule: "vesa"
[ 20.632] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[ 20.638] (II) Module vesa: vendor="X.Org Foundation"
[ 20.638] compiled for 1.12.99.902, module version = 2.3.2
[ 20.638] Module class: X.Org Video Driver
[ 20.638] ABI class: X.Org Video Driver, version 13.0
[ 20.638] (II) LoadModule: "modesetting"
[ 20.638] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[ 20.643] (II) Module modesetting: vendor="X.Org Foundation"
[ 20.643] compiled for 1.12.99.902, module version = 0.4.0
[ 20.643] Module class: X.Org Video Driver
[ 20.643] ABI class: X.Org Video Driver, version 13.0
[ 20.643] (II) LoadModule: "fbdev"
[ 20.644] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[ 20.650] (II) Module fbdev: vendor="X.Org Foundation"
[ 20.650] compiled for 1.12.99.902, module version = 0.4.3

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

In comment #8 I intended to say: "Hope that you trust me when I say that on Kubuntu 12.10 the tearing starts at a lower part of the screen"

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

I now tried again fedora 18 preview, with SNA enabled.
At this point I do not know anything else to try so I will
wait for you guys to think of something :-)

I created a file /etc/X11/xorg.conf with these contents:

Section "Device"
 Identifier "Intel Graphics"
 Driver "intel"
 Option "AccelMethod" "sna"
EndSection

And restarted the x-server.

The tearing is exactly as before, so this did not help.

Excerpts from /var/log/Xorg.0.log:

...
     80 [ 164.490] (II) LoadModule: "glx"
     81 [ 164.490] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
     82 [ 164.490] (II) Module glx: vendor="X.Org Foundation"
     83 [ 164.490] compiled for 1.12.99.904, module version = 1.0.0
     84 [ 164.491] ABI class: X.Org Server Extension, version 6.0
     85 [ 164.491] (==) AIGLX enabled
     86 [ 164.491] Loading extension GLX
     87 [ 164.491] (II) LoadModule: "intel"
     88 [ 164.491] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
     89 [ 164.491] (II) Module intel: vendor="X.Org Foundation"
     90 [ 164.491] compiled for 1.12.99.903, module version = 2.20.2
     91 [ 164.491] Module class: X.Org Video Driver
     92 [ 164.491] ABI class: X.Org Video Driver, version 13.0
...
    259 [ 165.023] (==) Depth 24 pixmap format is 32 bpp
    260 [ 165.034] (II) intel(0): SNA initialized with SandyBridge backend
    261 [ 165.034] (==) intel(0): Backing store disabled
    262 [ 165.034] (==) intel(0): Silken mouse enabled
    263 [ 165.034] (II) intel(0): HW Cursor enabled
    264 [ 165.034] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
    265 [ 165.034] (==) intel(0): DPMS enabled
    266 [ 165.041] (II) intel(0): [DRI2] Setup complete
....

[Thomas-luebking (thomas-luebking)]

This patch might avoid tearing IN FULLSCREEN WINDOWS ONLY
The more feedback we can get on it, the more likely it'll get into the next release.

https://git.reviewboard.kde.org/r/106833/

[Thomas-luebking (thomas-luebking)]

*** Bug 308332 has been marked as a duplicate of this bug. ***

[Ralf Jung (0tlwui8x-post-kj985rvy)]

On my system, this fixes tearing (using the teartest from http://ompldr.org/iYXBldg-hide) in full-screen mplayer (with the OpenGL backend). It does however *not* fix tearing with the full-screen VLC (OpenGL mode as well), nor in VLC maximized in windowed mode - the latter was to be expected, but I do this often. The reason may be that my screen is 16:10, the video is 16:9, and VLC is smart enough toa ctually not damage the black bars at the top and bottom - so KWin does not see a full-screen damage event.
If you decide to adjust the repaint logic to compensate for that, please have in mind there are people using a 5:4 screen (1280x1024) watching 16:9 videos - and movies for cinema are even wider.

Btw, why is this bug still unconfirmed?

[Thomas-luebking (thomas-luebking)]

(In reply to comment #14)
> On my system, this fixes tearing (using the teartest from
> http://ompldr.org/iYXBldg-hide) in full-screen mplayer (with the OpenGL
> backend). It does however *not* fix tearing with the full-screen VLC (OpenGL
> mode as well), nor in VLC maximized in windowed mode

Can you please enable the "Show Paint" plugin and check the paint behavior of vlc?
Also check another video output (xv, vdpau, x11)

> If you decide to adjust the repaint logic to compensate for that, please
> have in mind there are people using a 5:4 screen (1280x1024) watching 16:9
> videos - and movies for cinema are even wider.
Irrelevant since the black bars will be wider than the post retrace area anyway?

> Btw, why is this bug still unconfirmed?
We don't even 100% know what it is, thus whether we have to or can solve it.
Status quo is that glWaitVideoSync in different implementations *might* sync to the retrace end - or sync to the wrong device (unlikely but possible - do you have a multiscreen setup?) or ...
And in that case it would be invalid (or "upstream" etc.) anyway.

Personally I btw. give a shit on whether a bug is marked unconfirmed or new - there's is an issue to solve for at least one person unless the bug is marked resolved.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

(In reply to comment #15)
> Can you please enable the "Show Paint" plugin and check the paint behavior
> of vlc?
> Also check another video output (xv, vdpau, x11)
Indeed the paint plugin shows that "mplayer -vo gl" does full-screen repaints, while VLC does not.
vdpau does not work here (mplayerdoesn't support it and VLC framerate drops down too much to be useful). I will test the other backends later or tomorrow when I got the time.

> > If you decide to adjust the repaint logic to compensate for that, please
> > have in mind there are people using a 5:4 screen (1280x1024) watching 16:9
> > videos - and movies for cinema are even wider.
> Irrelevant since the black bars will be wider than the post retrace area
> anyway?
That might or might not work - the tearing line moves down at least one quarter, sometimes even a third of the screen here.
For a 16:9 movie on a 5:4 screen, the movie will be 720 pixels high, meaning the black bars have 280 pixels, which is less than a quarter, so if it tears like it does on my system it would be visible. If this depends more on the absolute pixels than on the relative sizes... I don't know^^

> > Btw, why is this bug still unconfirmed?
> We don't even 100% know what it is, thus whether we have to or can solve it.
> Status quo is that glWaitVideoSync in different implementations *might* sync
> to the retrace end - or sync to the wrong device (unlikely but possible - do
> you have a multiscreen setup?) or ...
I see.
I am using an external screen connected to the HDMI connector of my laptop. The laptop-internal screen is disabled. I do also have a 2nd GPU by NVidia in this machine, but it is turned off all the time during these tests and therefore should not interfere.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #16)

> I do also have a 2nd GPU by NVidia in this machine, but it is turned
> off all the time during these tests and therefore should not interfere.

         DOES ANYONE HERE HAVE AN NVIDIA FREE SYSTEM?

Sorry for shouting, but could be quite relevant ;-)

> If this depends more on the absolute pixels than on the relative sizes...
In case the problem is syncing to the end of the retrace, it's absolute pixels and relates more to the memory speed (and pot. the screen width)

> I am using an external screen connected to the HDMI connector of my laptop.
Do you get the same (or similar) behavior on the internal screen?

[Ralf Jung (0tlwui8x-post-kj985rvy)]

I've had some more time than expected, so here are my test results:

x = tears heavily (i.e. a tearing line is visible at least half the time)
~ = tears a bit (i.e. a tearing line is sometimes visible)
- = does not tear at all

W = Window (mayimized)
FS = Fullscreen

I did not include mplayer with X11 backend as it does not do upscaling, so the image is small on my screen
and can't be compared to the others.

master
            | GL | Xv | X11
VLC W | x | ~ | x
VLC FS | x | ~ | x
mplayer W | x | ~ |
mplayer FS | x | ~ |

master+patch

            | GL | Xv | X11
VLC W | x | ~ | x
VLC FS | x | ~ | x
mplayer W | x | ~ |
mplayer FS | - | ~ |

I added a debug statement to kwin telling me when the swap case is used, and indeed this correlates with the visual observations: When using mplayer -vo gl in fullscreen, every frame is swapped. For any other case, sometimes a frame is swapped, but most of the time it is not. This also correlates with the output of the paint plugin: Only mplayer -vo gl is actually performing full-screen redraws.

(In reply to comment #17)
> DOES ANYONE HERE HAVE AN NVIDIA FREE SYSTEM?
>
> Sorry for shouting, but could be quite relevant ;-)
I can feel your pain ;-) but, you see, I want to do gaming on Linux, and then there is not much choice.
On topic though, as I said, the card is turned off and the nvidia kernel module is not even loaded, nor is the NVidia GL implementation.

> > I am using an external screen connected to the HDMI connector of my laptop.
> Do you get the same (or similar) behavior on the internal screen?
Will test tomorrow. The internal screen is 16:9 though and much smaller, so I expect (a) your patch to kick in for all backens in full-screen, as now all pixels *have* to be damaged, and (b) it's much harder to see small tearing.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

Argh, bugs.kde.org seems to use a strange font which doesn't have a proper tilde...
Xv was always "tearing a bit", and mplayer FS with the patch applied was the only case with no tearing at all.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #18)
> I can feel your pain ;-)

That's not the point, but we've always had tearing issue reports with nvidia boards and recently got some for intel.
Now, if all those intel reporters actually use optimus, that smells suspicious to me ;-)

> I want to do gaming on Linux
I've an nvidia GPU + the blob as well, i'm completely agnostic on this topic and in general the system works nicely. I just want to pin down this issue.

> On topic though, as I said, the card is turned off and the nvidia kernel
> module is not even loaded, nor is the NVidia GL implementation.
How's the HDMI chip wired? Connected to the nvidia chip or to the intel one (where the nvidia one copies the framebuffer)?

> Will test tomorrow. The internal screen is 16:9 though
-> cinemascope / panavision / cinemascope55

However the much more relevant question is whether the non swapping sync works with the internal screen.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

On 10/14/2012 01:11 PM, Thomas Lübking wrote:
> https://bugs.kde.org/show_bug.cgi?id=307965
>
> --- Comment #20 from Thomas Lübking <email address hidden> ---
> (In reply to comment #18)
>> I can feel your pain ;-)
> That's not the point, but we've always had tearing issue reports with nvidia
> boards and recently got some for intel.
> Now, if all those intel reporters actually use optimus, that smells suspicious
> to me ;-)
>
>> I want to do gaming on Linux
> I've an nvidia GPU + the blob as well, i'm completely agnostic on this topic
> and in general the system works nicely. I just want to pin down this issue.
>
>> On topic though, as I said, the card is turned off and the nvidia kernel
>> module is not even loaded, nor is the NVidia GL implementation.
> How's the HDMI chip wired? Connected to the nvidia chip or to the intel one
> (where the nvidia one copies the framebuffer)?
>
>> Will test tomorrow. The internal screen is 16:9 though
> -> cinemascope / panavision / cinemascope55
>
> However the much more relevant question is whether the non swapping sync works
> with the internal screen.
>
I can confirm that my main system is NVIDEA-FREE!!
This is the system I reported (and filmed) the tearing issue on.
The system has an ASUS Maximus IV gene-Z blahblah board with
  k2500 sandy bridge and am perfectly happy with the speed of the graphics.
I just use a single monitor, really the setup is as simple as can be :-)

In addition I want to report the following:
- The teartest (movie) mentioned earlier also tears in this system.
   So I think there is at least some chance that if a person reports
video tearing solved, that
   my problem is solved as well.
- I cannot apply a patch - don't have the time to compile etc.
- I have a 24" DELL monitor with a resolution of 1920 X 1200...
- My laptop, with pre-sandy bridge graphics and 1920X1080 screen does
NOT show tearing in the tear video test.
This correlates with NO tearing when moving windows manually on that system.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

On 10/14/2012 05:34 PM, John van Spaandonk wrote:
> https://bugs.kde.org/show_bug.cgi?id=307965
>
> --- Comment #21 from John van Spaandonk <email address hidden> ---
> On 10/14/2012 01:11 PM, Thomas Lübking wrote:
>> https://bugs.kde.org/show_bug.cgi?id=307965
>>
>> --- Comment #20 from Thomas Lübking <email address hidden> ---
>> (In reply to comment #18)
>>> I can feel your pain ;-)
>> That's not the point, but we've always had tearing issue reports with nvidia
>> boards and recently got some for intel.
>> Now, if all those intel reporters actually use optimus, that smells suspicious
>> to me ;-)
>>
>>> I want to do gaming on Linux
>> I've an nvidia GPU + the blob as well, i'm completely agnostic on this topic
>> and in general the system works nicely. I just want to pin down this issue.
>>
>>> On topic though, as I said, the card is turned off and the nvidia kernel
>>> module is not even loaded, nor is the NVidia GL implementation.
>> How's the HDMI chip wired? Connected to the nvidia chip or to the intel one
>> (where the nvidia one copies the framebuffer)?
>>
>>> Will test tomorrow. The internal screen is 16:9 though
>> -> cinemascope / panavision / cinemascope55
>>
>> However the much more relevant question is whether the non swapping sync works
>> with the internal screen.
>>
> I can confirm that my main system is NVIDEA-FREE!!
> This is the system I reported (and filmed) the tearing issue on.
> The system has an ASUS Maximus IV gene-Z blahblah board with
> k2500 sandy bridge and am perfectly happy with the speed of the graphics.
> I just use a single monitor, really the setup is as simple as can be :-)
>
> In addition I want to report the following:
> - The teartest (movie) mentioned earlier also tears in this system.
> So I think there is at least some chance that if a person reports
> video tearing solved, that
> my problem is solved as well.
> - I cannot apply a patch - don't have the time to compile etc.
> - I have a 24" DELL monitor with a resolution of 1920 X 1200...
> - My laptop, with pre-sandy bridge graphics and 1920X1080 screen does
> NOT show tearing in the tear video test.
> This correlates with NO tearing when moving windows manually on that system.
Another not: I did not play the video full screen, just in a window.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

> vdpau does not work here (mplayerdoesn't support it and VLC framerate drops
> down too much to be useful).
I mixed two things up here: VA-API does not work. vdpau I did not even test, no idea how to get that working with optimus.

> How's the HDMI chip wired? Connected to the nvidia chip or to the intel one (where the nvidia one copies the framebuffer)?
HDMI is connected to the Intel card. To use the NVidia card, I use bumblebee which performs rendering on the 2nd card and copies stuff back. But all the video tests mentioned here were done directly on the Intel card.

>> Will test tomorrow. The internal screen is 16:9 though
> cinemascope / panavision / cinemascope55
Sorry, I do not understand - what are you saying?

> However the much more relevant question is whether the non swapping sync works > with the internal screen.
I only tested with the GL backend: In mplayer, there is no tearing in full-screen mode, but windowed mode has tearing. In VLC, there is tearing in both modes - even though the video covers the entire screen. The fullRepaint condition is still not met, and if I enable the paint plugin the tearing line is visible on the entire width - the "paint" colours also tear.
So, there's actually no difference here between the internal and the HDMI panel, even though the video aspect ratio matches the internals screen and *not* the HDMI screen.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #23)
> I mixed two things up here: VA-API does not work. vdpau I did not even test,
> no idea how to get that working with optimus.
vdpau is only available with nvidia, xvmc should work, though.

> >> Will test tomorrow. The internal screen is 16:9 though
> > cinemascope / panavision / cinemascope55
> Sorry, I do not understand - what are you saying?
those are cinematic aspects which are all much more narrow than 16:9 - so you'll get black bars.

> I only tested with the GL backend: In mplayer, there is no tearing in
> full-screen mode, but windowed mode has tearing. In VLC, there is tearing in
> both modes - even though the video covers the entire screen. The fullRepaint
> condition is still not met
Have you checked this (with a debug out in the glXSwapBuffer branch?)
Could mean that vlc tears internally and causes partial damage events crossing the retrace spot.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

(In reply to comment #24)
> those are cinematic aspects which are all much more narrow than 16:9 - so
> you'll get black bars.
I see - but I got this teartest video only in one resolution ;-) . However, VLC has some option to stretch the video, and I guess mplayer has that, too. Not that it's needed currently.

> > I only tested with the GL backend: In mplayer, there is no tearing in
> > full-screen mode, but windowed mode has tearing. In VLC, there is tearing in
> > both modes - even though the video covers the entire screen. The fullRepaint
> > condition is still not met
> Have you checked this (with a debug out in the glXSwapBuffer branch?)
Yes, I used a debug output in that branch. When using mplayer, I get a *lot* of them - as is to be expected, about one per frame. For VLC, there's just 10 to 20 full-screen redraws during the entire (30sec) video.
With compositing disabled, VLC produces some tearing, but much less than with compositing (comparable to using the XVideo backend and compositing).

[Thomas-luebking (thomas-luebking)]

Created attachment 74570
Christmas time

The attached x-mas patch enforces the glXSwapBuffer branch, writing back the frontbuffer into the backbuffer.

Please NOTICE:
- fullscreen memory copy is expensive, not as expensive as fullscreen repaints, but is. No problem on dedicated GPUs with memory speed beyond good and evil, but i've NOT tested that on an integrated system so far
- the code assumes we can glXSwapBuffer, rather don't run it if you can't (or revert if if freaky things happen ;-)
- the patch can be streamlined (ie. it's not required to turn the swapInterval on and off and also we can omit some extra drop in/out frames when switching between swapBuffer and partial copies

Happy testing - there *will* be no tearing.... prettyprettyplease not :-)

[Ralf Jung (0tlwui8x-post-kj985rvy)]

Indeed, I can't see any tearing with this patch - neither when dragging a plasma widget horizontally at the top of the screen, nor when playing a video either in windowed or in full-screen mode. :)

However, the framerate drops to 30-40fps. I wonder why this is, since I can run some old games (and demos like glxspheres) with 60fps on the NVidia GPU, which also involves copying the ful -screen to the intel card for each frame.

[Thomas-luebking (thomas-luebking)]

- The two GPUs will not share the same memory? (r -> w ./. r/w)
- Also the memory might just get boosted when the nvidia GPU is up.
- Last but not least, the driver may ("Tear free") perform a sync itself - tried deactivating kwin v'syncing?

I tried to only copy back the dirty memory, but that fails here (happy flicker) - might be related to triple buffering :-(

Other tested things for the record: glWaitVideoSync *is* broken (on nvidia)
Waiting for the sync and then swapping the buffer (instead of using glSwapInterval) causes similar to the present tearing despite the swap/copy back patch is otherwise the same.

[Brian-m-hill (brian-m-hill)]

I backported the patch to 4.9.2 and can confirm that it absolutely kills performance on my system with integrated graphics :

Arch Linux
Mesa 9.0
xf86-video-intel 2.20.9
Core i7 2630QM
8 Gigabytes DDR3
Intel HD Graphics 3000

With the patch applied, I get an FPS in the teens to mid twenties and there is noticeable lag.

[ValdikSS (valdikss)]

Please test with mesa 8.0.4, there are some performance issues with 9.0 on HD3000. See https://bugs.freedesktop.org/show_bug.cgi?id=55998 and https://bugs.kde.org/show_bug.cgi?id=308385

[Brian-m-hill (brian-m-hill)]

With Mesa 8, the speed improves however I am getting graphical corruption with the patch. It appears to be a problem with the alpha blending when using the feature where you drag windows to the edges of the screen to maximize them; with the patch applied, it flickers.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

(In reply to comment #28)
> - The two GPUs will not share the same memory? (r -> w ./. r/w)
No, they won't. Neither the Xorg nor the Intel driver I have installed support DMA-BUF, let alone the NVidia driver ;-) So the image is copied two times: It's read back from the NVidia GPU, and then sent to the Intel GPU.

> - Also the memory might just get boosted when the nvidia GPU is up.
I turned on the NVidia card, then tried again - no changes.

> - Last but not least, the driver may ("Tear free") perform a sync itself -
> tried deactivating kwin v'syncing?
Indeed I can't see any tearing even after disabling vsync in KWin's configuration. The framereate goes up to 50-55fps, but it doesn't reach the 60 it has without the patch.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

With the "old" KDE 4.9.2 compositor, I get 60 fps even when playing a Full-HD video full-screen (using mplayer or VLC, GL backend). So the bandwidth is there, somehow.

[Thomas-luebking (thomas-luebking)]

Created attachment 74612
Hanukkah

If the back and front buffer are in different memory, that means an _additional_ copy for the glXSwapBuffer call.

The new patch has some performance improvements.
1st, it does not copy back the entire buffer but only the required parts
2nd, after a short time (24 frames, 1s for a cinematic movie) it enters a performance mode, assuming the fullscreen mode will continue (and it's thus not necessary to copy things back)

"2" does obviously not work with VLC, but one could -theoretically- relax that and check whether always the same region is updated.

The patch includes a code refacturing, i'm not sure how easy or possible it will be to port it back to 4.9 :-(

[Thomas-luebking (thomas-luebking)]

Created attachment 74617
Hanukkah #2

Forgot to restart the syncdelay timer - the first Hanukkah patch could feel chewy - sorry in case someone has already tried it.

[Ralf Jung (0tlwui8x-post-kj985rvy)]

(In reply to comment #34)
> The new patch has some performance improvements.
> 1st, it does not copy back the entire buffer but only the required parts
To be honest I do not understand why anything has to be copied back as it was kwin who copied it to the GPU to start with - but I don't know OpenGL well, so whatever ;-)

> 2nd, after a short time (24 frames, 1s for a cinematic movie) it enters a
> performance mode, assuming the fullscreen mode will continue (and it's thus
> not necessary to copy things back)
>
> "2" does obviously not work with VLC, but one could -theoretically- relax
> that and check whether always the same region is updated.
Framerate for a still desktop is 57-58 fps now (opposed to 59-62 in KDE 4.9.2). It drops to ~50fps in full-screen video playback - I could not see any difference between mplayer and VLC. There was no tearing whatsoever :)
While logging in, the screen went black instead of showing the splash screen - not sure if that's related to the patch.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #36)
> (In reply to comment #34)
> Framerate for a still desktop is 57-58 fps now (opposed to 59-62 in KDE
> 4.9.2).

That will likely be due to differences in glXSwapInterval and the broken glXWaitVideoSync - 62fps on an 60fps screen should not be possible in the first place.

> It drops to ~50fps in full-screen video playback

also with mplayer or only vith vlc (because on constant fullscreen updates, the back-copying overhead should be omitted and the difference would be _purely_ for the usage of glxSwapInterval)

> any difference between mplayer and VLC. There was no tearing whatsoever :)
At least it works.

> While logging in, the screen went black instead of showing the splash
> screen - not sure if that's related to the patch.
Might fall into the same category as the "flickering" effectframes (the problem is that they paint on top of the even undamaged backbuffer, ie. the content below was not repainted, but they are. Would need adaption of that code but is likely fixable)

--- sOT --

> To be honest I do not understand why anything has to be copied back as it
> was kwin who copied it to the GPU to start with - but I don't know OpenGL
> well, so whatever ;-)
There are two buffers, front and back.
You paint into the backbuffer which is currently not visible (otherwise flicker and tearing would be inavoidable) and when you're done, move the backbuffer content to the frontbuffer (which powers the screen pixels)
That move can be done by copying parts of the buffer or the entire buffer or ("flipping") by just telling the GPU that now the front is the backbuffer and vv. (obviously last is fastest, but the buffers must be on the same memory)

Because usually only a minor fraction of the screen is actually changed, kwin renders only that fraction into the backbuffer and then copies the resulting part into the frontbuffer.
Now, if you want to swap buffers (for whatever reason, ours being that the glWaitVideoSync extension is apparently broken) you have to ensure that the entire backfuffer is sane, the part you did not alter in this pass matches the current frontbuffer part.
For that to happen, you have to ensure the backbuffer is a pixelperfect copy of the _current_ frontbuffer (and not the frontbuffer one or two passes ago), therefore it's necessary to copy the differing parts from the front into the backbuffer before starting the actual painting (of the no to update screen part)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Harald Sitter (apachelogger)]

Won't see any update until any patch was approved and included upstream.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

On 11/13/2012 07:55 PM, RunetMember wrote:
> https://bugs.kde.org/show_bug.cgi?id=307965
>
> --- Comment #80 from RunetMember <email address hidden> ---
>> Unfortunately, the mentioned backports PPA does not contain KDE 4.9.3 for 12.10 (quantal), yet.
> https://launchpad.net/~kubuntu-ppa/+archive/ppa?field.series_filter=quantal
>
I used this.
deb http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu quantal main

(Sorry, it's the kubuntu ppa) http://www.kubuntu.org/news/kde-sc-4.9.3

[O-root-jurathek-de (o-root-jurathek-de)]

Ah, I must have somehow gotten into the wrong repo, there were only three packages in there.

Now I can confirm that this bug is fixed for me on Intel i5 2500k, HD 3000, intel_drv.so 2.20.9, Ubuntu 12.10+Kubuntu backports PPA

/usr/lib/xorg/modules/drivers/intel_drv.so belongs to xserver-xorg-video-intel, not the KDE backport.

Thank You!
To whomever :D

[ValdikSS (valdikss)]

Don't see any kwin changes
http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kde-workspace/changes

[Ralf Jung (0tlwui8x-post-kj985rvy)]

Maybe Ubuntu enabled the "TearFree" option in the Intel X driver?
That'd be just a crude work-around though, that option adds a driver-side compositor (even if the desktop already uses a compositor), which means a lot of additional copies.

[ValdikSS (valdikss)]

(In reply to comment #84)
> Maybe Ubuntu enabled the "TearFree" option in the Intel X driver?
> That'd be just a crude work-around though, that option adds a driver-side
> compositor (even if the desktop already uses a compositor), which means a
> lot of additional copies.

sudo grep -i tear /var/log/Xorg.0.log
Please

[O-root-jurathek-de (o-root-jurathek-de)]

(In reply to comment #85)
> sudo grep -i tear /var/log/Xorg.0.log
> Please

Nothing for me, but I didn't restart X nor reload the driver, but no tearing; just updated KDE.

[Mgraesslin (mgraesslin)]

> Don't see any kwin changes
> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kde-workspa
> ce/changes
Rev 699: New upstream release (LP: #1074747)

[ValdikSS (valdikss)]

(In reply to comment #87)
> Rev 699: New upstream release (LP: #1074747)

files modified:
debian/changelog
debian/control

[O-root-jurathek-de (o-root-jurathek-de)]

In order to clarify: there is still tearing in the upper part!
Just far far far less.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

On 11/16/2012 10:12 AM, <email address hidden> wrote:
> https://bugs.kde.org/show_bug.cgi?id=307965
>
> --- Comment #89 from <email address hidden> ---
> In order to clarify: there is still tearing in the upper part!
> Just far far far less.
>
I concur.

Tearing now only occurs with the top few mm, becoming difficult to see.
Thanks for the fix, but no home run quite yet :-(

[ValdikSS (valdikss)]

It could be that RC6 is disabled. If you enable RC6, it would occur just a little lower, but it would be pretty visible.

[Thomas-luebking (thomas-luebking)]

There has been no fix from our side unless you patched in https://git.reviewboard.kde.org/r/107198/ and selected a full repaint variant

   kwriteconfig --file kwinrc --group Compositing --key <?>

<?> being either of n,e,p,c for "No fullrepaints", "Extend (nearly full) to full repaints", "full rePaints" and "Copy buffer full repaints".

"c" is only reasonable on the nvidia blob and eventually fglrx.
Do NOT use it with MESA and the Open Source drivers.

[Andrey Borisochkin (borisochkin)]

I can confirm this behavior on up to date Archlinux (KDE 4.9.3, nvidia blob 310.19, video card - gtx650 ti). This tearing shows up regardless of vsync in nvidia-settings. When I turn on vsync in kwin tearing will come up. However, NOT immediately - after a few seconds.

I didn't encounter this behavior with older card (7900GS) the day before yesterday (nvidia blob 304.xx).

[Andrey Borisochkin (borisochkin)]

https://devtalk.nvidia.com/default/topic/525074/linux/image-tear-with-kwin-compositing-and-vsync-on/

"glWaitVideoSync() works as intended, but doesn't really provide a way to present in a tear-free way. The proper way to fix this on the KWin side would be to implement support for the new GLX_EXT_buffer_age extension."

[Thomas-luebking (thomas-luebking)]

Whatever was the intention of "glWaitVideoSync" (apparently not the way it was utilized in compositors) - "glxinfo | grep GLX_EXT_buffer_age" is void on nvidia 310.19 and as reported in the review request on intel/mesa as well.
So is "grep GLX_EXT_buffer_age /usr/share/doc/nvidia/NVIDIA_Changelog".

That is why we attempt always full repaints and swapping the buffer.
https://git.reviewboard.kde.org/r/107198/

[Pgriffais (pgriffais)]

Hi Thomas,

The problem with glWaitVideoSync() is that it waits on the CPU, so any interval of time can happen between performing that wait and issuing the blit, which means tear-free presentation isn't guaranteed.

We briefly discussed this with Fredrik a few days ago, and contrary to what I said GLX_EXT_buffer_age isn't yet exposed on current 310 drivers (as you found out). However we should be rolling out a new release series shortly, which will include support for it.

The intention behind the change you linked is good, but without the functionality provided by GLX_EXT_buffer_age you have no guarantees about how many buffers are in the flip queue of the driver; it's usually a trivial cycle between 2 or 3 buffers depending whether Triple Buffering is enabled, but other implementations might have their own specific flipping mechanism.

Thanks,
 - Pierre-Loup

[bwat47 (bwat47)]

Does anyone know if a fix for this (for intel cards) ever make it into kde 4.9.x? Or will it only come later on in 4.10? I really want to switch to KDE but this is a dealbreaker for me :(.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #97)
> Does anyone know if a fix for this (for intel cards) ever make it into kde
> 4.9.x?

Actually the intel IGPs should operate on the glXCopySubBuffer path and that should not cause tearing but with some broken MESA versions.

The pending patch at https://git.reviewboard.kde.org/r/107198/ will *hopefully* still make it into 4.10 - it's however a far too massive change for a bugfix release (ie. 4.9) sorry.

[Thomas-luebking (thomas-luebking)]

Hi Pierre-Loup

(In reply to comment #96)
> The problem with glWaitVideoSync() is that it waits on the CPU
Ok, thanks for the information - i guess it's no misassumption thzat we could in a further patch completely scratch that path then?

> The intention behind the change you linked is good, but without the
> functionality provided by GLX_EXT_buffer_age you have no guarantees

Actually the current approach either forces full repaints or completes the backbuffer from the frontbuffer (we scratched re-using the backbuffer for it's undefined state, plus it will require some (but minor) changes on clipping artificial elements), but the latter has severe performance issues on the MESA stack (so we'll mostly require GLX_EXT_buffer_age there, esp. since the weaker IGPs also typically suffer most from effects like blurring etc.)

Many thanks for your assistance on the issue.

[bwat47 (bwat47)]

(In reply to comment #98)
> (In reply to comment #97)
> > Does anyone know if a fix for this (for intel cards) ever make it into kde
> > 4.9.x?
>
> Actually the intel IGPs should operate on the glXCopySubBuffer path and that
> should not cause tearing but with some broken MESA versions.
>
> The pending patch at https://git.reviewboard.kde.org/r/107198/ will
> *hopefully* still make it into 4.10 - it's however a far too massive change
> for a bugfix release (ie. 4.9) sorry.

I'm on ivybridge and I had tried kubuntu 12.10 which has pretty recent mesa/kernel/driver versions (9.0, 3.5, 2.20.9).

AFIAK the problem is that currently sandybridge and ivybridge hardware simply cannot get fully tear free output unless the compositor *always* pageflips (ubuntu has changed compiz to behave this way by default in ubuntu 12.10 and I get absolutely no tearing anywhere there). I can also achieve totally tear-free output in gnome-shell by adding CLUTTER_PAINT=disable-clipped-redraws:disable-culling to /etc/environment.

Intel is working on adding "legacy" vsync in kernel 3.8 afiak, but if this is used it will cause significantly more power usage, since it keeps the intel card out of its power saving state, so the proper way on intel will still be to only use page-flipping, which is why that pending patch you linked is probably the only thing that will gives sandybridge/ivybridge users totally tear-free output.

It is possible to get tear-free fullscreen video currently if you use unredirect fullscreen windows in kwin + opengl output in the video player, but even that doesn't always work (it depends on the application, some video players don't seem to page-flip even with opengl output, for example see this vlc bug: https://trac.videolan.org/vlc/ticket/7702

the best tear free video experience for ivybridge is to use an always page-flipping compositor, with unredirect fullscreen windows disabled, this seems to get rid of any and all tearing.

[bwat47 (bwat47)]

I see KDE 4.10 is out today, can anyone tell me if tearing still occurs on ivybridge in kde 4.10?

[Thomas-luebking (thomas-luebking)]

None of the discussed "more buffer swapping" patches has been applied to kde 4.10

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

still present in kde 4.10 on kubuntu 12.10, as expected.

[bwat47 (bwat47)]

Can we expect it to make it into kde 4.11 then? I'm currently using the intel xorg "tearfree" option and have kwins vsync disabled, which works but has poor performance and higher power draw. This is a really big usability issue that makes kwin rather unusable on intel graphics!

[ValdikSS (valdikss)]

Yes, it will be included in 4.11

[Thomas-luebking (thomas-luebking)]

Git commit 6072b4feb8c90024aa24b2e9cb8a21ab2140412c by Thomas Lübking.
Committed on 18/02/2013 at 23:17.
Pushed by luebking into branch 'master'.

support a permanent glSwapBuffer

either by
- forcing fullrepaints unconditionally
- turning a repaint to a full one beyond a threshhold
- completing the the backbuffer from the frontbuffer after the paint
FIXED-IN: 4.10
REVIEW: 107198

M +1 -11 kwin/composite.cpp
M +5 -4 kwin/eglonxbackend.cpp
M +60 -57 kwin/glxbackend.cpp
M +29 -0 kwin/options.cpp
M +13 -0 kwin/options.h
M +35 -10 kwin/scene.cpp
M +3 -0 kwin/scene.h
M +76 -1 kwin/scene_opengl.cpp
M +1 -0 kwin/scene_opengl.h

http://commits.kde.org/kde-workspace/6072b4feb8c90024aa24b2e9cb8a21ab2140412c

[markg85 (markg85)]

(In reply to comment #106)
> Git commit 6072b4feb8c90024aa24b2e9cb8a21ab2140412c by Thomas Lübking.
> Committed on 18/02/2013 at 23:17.
> Pushed by luebking into branch 'master'.
>
> support a permanent glSwapBuffer
>
> either by
> - forcing fullrepaints unconditionally
> - turning a repaint to a full one beyond a threshhold
> - completing the the backbuffer from the frontbuffer after the paint
> FIXED-IN: 4.10
> REVIEW: 107198
>
> M +1 -11 kwin/composite.cpp
> M +5 -4 kwin/eglonxbackend.cpp
> M +60 -57 kwin/glxbackend.cpp
> M +29 -0 kwin/options.cpp
> M +13 -0 kwin/options.h
> M +35 -10 kwin/scene.cpp
> M +3 -0 kwin/scene.h
> M +76 -1 kwin/scene_opengl.cpp
> M +1 -0 kwin/scene_opengl.h
>
> http://commits.kde.org/kde-workspace/6072b4feb8c90024aa24b2e9cb8a21ab2140412c

Hi,

The "version fixed in" field in this bug report notes 4.11.
Yet the actual commit message says "FIXED-IN: 4.10"

...

Which version will have this fix? the just released 4.10.1?

Cheers,
MArk

[Ralf Jung (0tlwui8x-post-kj985rvy)]

The fix will land in 4.11. The danger of regressions is too big to put it into the stable branch.

[Thomas-luebking (thomas-luebking)]

4.11
Sorry, my bad.
The commit took some time, initially pointed 4.10 but didn't make it and i forgot to edit the message.

The patch (and the pending following ones) are far to invasive to be added to minor releases.

[markg85 (markg85)]

(In reply to comment #109)
> 4.11
> Sorry, my bad.
> The commit took some time, initially pointed 4.10 but didn't make it and i
> forgot to edit the message.
>
> The patch (and the pending following ones) are far to invasive to be added
> to minor releases.

Ok, that's fine. Just wanted to make sure since i'm also experiencing the issue described in this bug.

[Andreas Hermann (anhermann)]

I applied this patch against kwin 4.10.1. My system has an nvidia card, using the binary blob.
My results:

- with 'c' mode: zero tearing, but kwin constantly has 60% cpu usage. Performance is ok, but i think this is because of the powerfull gpu/cpu (gtx460 + core i7)

- with 'e' mode: amazing performance, but again tearing on the second monitor (upper part)

- with 'p' Mode: same as c

However, tearing generally disappears if i force my two monitors to have the same resolution.

[Thomas-luebking (thomas-luebking)]

Pretty much fixed tearing on "c" will remain until we remove the "rather not so helpful" waitSync calls from the pixel copying branch (patch here, RR pending for the moment)

As for the CPU usage: the patch was never tested against 4.10 neither would it cleanly apply.
If you can provide a callgrind dump, i can look into it, but there's little reason for CPU overhead on the buffer swapping paths (memory throughput esp. w/o flipping support, but that's not CPU related)

It rather sounds as if you run into constant repaints - for whatever reason - and for 60% load on an i7 core rather unblocked (ie. beyond 60FPS)

[Andreas Hermann (anhermann)]

Thank yout Thomas for the quick response.
So there is no easy way to to test this on 4.10?

[Thomas-luebking (thomas-luebking)]

No. It would require a serious and complete backport to ensure that everything is in shape (ie. every behaviour that patch relies on is present)
And that'd be quite some work for a quick singleton test.

The most simple way would actually be to get the git master of kde-workspace and compile & install only kwin (that should actually work)

[Thomas-luebking (thomas-luebking)]

(In reply to comment #113)
> Thank yout Thomas for the quick response.
> So there is no easy way to to test this on 4.10?

Just a short re-confirmation: you did not get this CPU load while using the FPS counter, did you?
That's pretty much expectable and unrelated.

[Andreas Hermann (anhermann)]

(In reply to comment #115)
> (In reply to comment #113)
> > Thank yout Thomas for the quick response.
> > So there is no easy way to to test this on 4.10?
>
> Just a short re-confirmation: you did not get this CPU load while using the
> FPS counter, did you?
> That's pretty much expectable and unrelated.

Do you mean the Show FPS effect? I dit not use that. I just looked at the process list with htop. That showed kwin constantly using around 50-60% cpu usage when running with 'c'.
As soon as i have some time, i will try it again with kwin from git-master.

[Sergio López del Pozo (selopo)]

I'm glad to see that the problem is fixed in 4.11. I upgraded Mint to it and works like a charm (note that Vsync settings have to be changed to Full scene repaints). I can finally watch movies without tearing, this was a no-go for me to continue with KDE.

[1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx (1pt1nq88tvxvjiijcixknc4iaqh3fq-john-8aho930n7szvk8tyqp2yd0cny5grzx)]

works with the new kde, 4.11.2.

[Rohan Garg (rohangarg)]

Hi
Sorry, but we do not plan to provide any more updates to KDE Workspace for 12.04 currently except via the Kubuntu Backports repository. Please add the Kubuntu Backports repository so as to get the latest KDE and to get the required bug fix. We also recommend using the LTS HWE stack with the Kubuntu Backports PPA.

You can read about the Kubuntu Backports PPA here : https://wiki.kubuntu.org/Kubuntu/KubuntuPPAs#Kubuntu_Backports