Video tearing on Sandybridge

Video tearing on Sandybridge

[Oliver Seitz]

Hello,

I'm running vaapi-mplayer on debian wheezy, which has fairly up-to-date 
intel drivers. (Right now i965-va-driver is outdated, so I use the sid 
package of that.)

I do not have any window manager, only X and an xterm. (Really, not even 
twm. It is only a test installation.)

Both output via OpenGL and VA-API play fine if there is only one active 
screen, or two screens which display the same picture (clone mode).

If, however, two screens are next to or on top of each other, playing 
video on one of the screens can show some tearing. It is not always seen 
with normal video, a special test pattern is helpful. Also, it does only 
tear in one out of ten tries, you can hit pause again and again, sooner 
or later the tearing will appear, and disappear again after the next 
pause/unpause cycle. While the tearing is there, it stays at about the 
same height of the video until the next pause/unpause cycle. Most times 
it is seen in the top third of the video. It does not matter if the 
video is fullscreen or not.

One screen is 1440x900 via DVI, the other is 1920x1080 via HDMI. Both 
screens run 60Hz, my test video is 30fps and full 1920x1080.

Is it likely that this is a bug, or am I doing something wrong?

Thank you all!

Greets,
Kiste

Re: Video tearing on Sandybridge

[Chris Wilson]

On Sat, 31 Mar 2012 19:52:09 +0200, Oliver Seitz <info@vtnd.de> wrote:
[snip]
> If, however, two screens are next to or on top of each other, playing 
> video on one of the screens can show some tearing. It is not always seen 
> with normal video, a special test pattern is helpful. Also, it does only 
> tear in one out of ten tries, you can hit pause again and again, sooner 
> or later the tearing will appear, and disappear again after the next 
> pause/unpause cycle. While the tearing is there, it stays at about the 
> same height of the video until the next pause/unpause cycle. Most times 
> it is seen in the top third of the video. It does not matter if the 
> video is fullscreen or not.
> 
> Is it likely that this is a bug, or am I doing something wrong?

Video tearing in windows is a known issue on SandyBridge as they removed
the commands to perform vsync'ed updates and hid the logic behind a
baffling sequence of registers that we have not yet got working.

The only workaround is to force pageflipping (ie exchange the whole
scanout for each frame) either by using a compositing WM (and hoping
for the best) or to only use fullscreen DRI video applications
(OpenGL or libva decoders) that use SwapBuffers.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Video tearing on Sandybridge

[Oliver Seitz]

> The only workaround is [...]  to only use fullscreen DRI video applications
> (OpenGL or libva decoders) that use SwapBuffers.

Yes, works perfectly while only one screen is connected. That means, 
this definition of "fullscreen" is "the whole framebuffer", and not "the 
content of one display"? This would in some way explain why tearing can 
not be reliably prevented while more than one screen is active.

Thanks for the explanations!

Greets,
Kiste

Re: Video tearing on Sandybridge

[Daniel Vetter]

On Mon, Apr 2, 2012 at 12:40, Oliver Seitz <info@vtnd.de> wrote:
>
>> The only workaround is [...]  to only use fullscreen DRI video
>> applications
>>
>> (OpenGL or libva decoders) that use SwapBuffers.
>
>
> Yes, works perfectly while only one screen is connected. That means, this
> definition of "fullscreen" is "the whole framebuffer", and not "the content
> of one display"? This would in some way explain why tearing can not be
> reliably prevented while more than one screen is active.

Well, currently X has one framebuffer spanning all xrandr screens.
Which means we can't pageflip just one (it would show garbage on the
other screen). The fix would be to use per-crtc framebuffers for X,
which requires a decent rewrite of many things in X.

Yet again something else that Wayland gets right from the start ;-)
-Daniel
-- 
Daniel Vetter
daniel.vetter@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

Re: Video tearing on Sandybridge

[Oliver Seitz]

> Video tearing in windows is a known issue on SandyBridge

And also on IvyBridge, I presume. Then I'll try to be patient until 
there's a new implementation of vsynced update logic in the driver :-)

Thanks for the explanations and all the good work!

Kiste

Re: Video tearing on Sandybridge

[Eugeni Dodonov]

[-- Attachment #1.1: Type: text/plain, Size: 796 bytes --]

On Mon, Apr 2, 2012 at 08:30, Oliver Seitz <info@vtnd.de> wrote:

>
>  Video tearing in windows is a known issue on SandyBridge
>>
>
> And also on IvyBridge, I presume. Then I'll try to be patient until
> there's a new implementation of vsynced update logic in the driver :-)
>

There are some improvements on the next one after that though :).

But the real fix for SNB/IVB depends on the DERRMR implementation which we
could not get to work without nasty side effects on Sandy Bridge yet (such
as hangs). Jesse has sent something in this sense for Ivy Bridge in his
'[Intel-gfx] Scanline wait hack for IVB' patch, so hope is not lost yet.

There is a huge thread about this on the
https://bugs.freedesktop.org/show_bug.cgi?id=37686 bug as well.

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>

[-- Attachment #1.2: Type: text/html, Size: 1392 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx