video tearing with textured video on intel card

Can someone of the devs say something about the problem or at least give some very good reasons? This is serious.

I mean textured video output is standard in the intel driver for years and it still doesn't work because of the tearing or missing vsync.

Another thing I don't understand is why overlay can't be enabled with the VideoOverlay xorg.conf option anymore? Nearly all Intel graphic cards seem to support overlay so why mess it up for them too?

This all means that video output doesn't really work since ages and all distributions need patches.

I have an i915 card but according to https://bugs.launchpad.net/bugs/278318 many others are also effected.

From my understanding, and please correct me if I'm wrong, overlay hardware is obsoleted with the move to 3D hardware/software. So all the 2D operations that where implemented in the overlay now has to be re-implemented in 3D operations.

Also, this thread:
    http://<email address hidden>/msg04078.html
which mentions option A, a "trivial" solution that will cause everything else to perform worse, but might be acceptable for fullscreen video. I think the patch he refers to is the XvMC path mentioned above, which doesn't affect xv.

What is the possibility for getting that implemented and only enabling it via an xorg.conf variable? So those of us that only ever run in fullscreen video will be happy :)

Atm video watching without seasickness is only possible with overlay output which requires a patched intel driver.
There might be penalties like blue borders with compiz or kwin but at least it works.
I guess nearly every standard user doesn't care if overlay is old, deprecated or 2d if there is no working alternative to watch videos.

If of course textured video uses vsync or similar and doesn't tear anymore I have no problem when overlay is disabled but this hasn't happened in over a year as I mentioned above.

Maybe if you have a time machine through which I could watch videos with a working intel driver textured video output it would be fine too. :D

Please remember that people live in the present, NOT in the future. Nobody needs textured video, EXA, UXA or any other new fancy feature if they mess things up. Workings features should be kept until the new ones are really able to replace them. That's why there normally is a stable and unstable branch.

One quick extra comment based on the "we're using 3D hardware now" meme: I tried using the opengl renderer in mythtv but it turned everything green and then froze. Once it froze I needed to reboot the machine to get my screen back - I couldn't restart X.

That is a separate bug, but it removes a possible work-around.

yes, I've been trying to use the opengl renderer in mythtv for sometime now, but it's always a green monochrome. It states this on the MythTV wiki under the XvMC section. http://www.mythtv.org/wiki/XvMC#Intel
Although I'm not using XvMC, just the opengl renderer, I'm still seeing the green.

I'm not sure what it is, intel driver or mythtv software. I can run mplayer using -vo GL or GL2 and it looks fine, and for a while had no tearing when using this. So I'm assuming its a mythtv colorspace conversion error. I haven't tested this in a while though.

http://svn.mythtv.org/trac/ticket/5999
No response.

OpenGL video output with EXA or UXA seem to have the tearing problem too. At least if used in kwin and with activated vsync option.

I don't know if this is a fglrx problem or a general OpenGL video one but the gl output seems to much more grainy than Xv. Not as much as Xorg video output but similar.

Started doing some debugging.

The mythtv vsync code is here: <http://svn.mythtv.org/trac/browser/trunk/mythtv/libs/libmythtv/vsync.cpp>.

If you edit the function drmWaitVBlank() on line 264 to include some calls to gettimeofday() and print out when the wait is less than 10ms, you'll see plenty of output.

If you look in the function DRMVideoSync::WaitForFrame() at line 325 you'll see some commented out debug statements. If you uncomment them you get:

WaitForFrame at : 15548 Delay at first sync: 7750
Wait 1 intervals. Count 60491126 Delay -8970
WaitForFrame at : 24978 Delay at first sync: 14499
Wait 1 intervals. Count 60491128 Delay -2240
WaitForFrame at : 46073 Delay at first sync: 37744
Wait 3 intervals. Count 60491132 Delay -12440
WaitForFrame at : 20562 Delay at first sync: 11037
Wait 1 intervals. Count 60491134 Delay -5689
WaitForFrame at : 28353 Delay at first sync: 17584
Wait 2 intervals. Count 60491137 Delay -15875
WaitForFrame at : 16296 Delay at first sync: 7597

The waitForFrame number is how long myth thinks you should wait from the time that function is called until the next frame should be displayed - i.e. how long it thinks it should sleep for. It then tries to sleep until the next vblank. It then calculates how long it has to sleep until it is near the next frame and shows that as the Delay number on the first line. i.e. the difference between those two numbers is how long the ioctl actually waited. Also note that the second number should be around 0 if myth was perfectly synced. This wont happen as there is 20ms between video frames and 16ms between vsyncs.

Having seen that it didn't want to sleep for more than 10ms, I added the following code at the front of myth's WaitForFrame():

    if (m_delay > 8000) {
      int sleepTime = m_delay - 6000;
      usleep(sleepTime);
    }

i.e. delay until there are 2ms until the time myth thinks the frame should be displayed. This leads to logs that look like this:

WaitForFrame at : 17808 sleeptime : 11808
WaitForFrame II at : 5870 Delay at sync: -9631
WaitForFrame at : 24409 sleeptime : 18409
WaitForFrame II at : 5865 Delay at sync: -2885
WaitForFrame at : 31029 sleeptime : 25029
WaitForFrame II at : 5871 Delay at sync: 3662
Wait 1 intervals. Count 93245119 Delay -13069
WaitForFrame at : 21271 sleeptime : 15271
WaitForFrame II at : 5849 Delay at sync: -6322

And the problem wasn't fixed.

Please take the MythTV issue elsehwere, as it isn't directly related to this bug. The DRM vblank support isn't intended to be used by applications directly.

  You're saying this is a Mythtv bug? Mythtv didn't tear with my previous graphics card (admittedly a couple of things have changed as well as the graphics card - narrowing that down is what debugging is about).

  What is the correct way to get video sync? (i.e. If I take this tearing to the mythtv mailing list, I'll need to tell them more than "I get tearing". I'd really like to be able to say something like "I get tearing because mythtv does its vsync wrong - according to the intel driver guys it shouldn't be doing X, it should be doing Y".)

  Is there another program that you know does it 'right' and hence would allow me to test my setup?

@ William Uther
Just use overlay if possible. I guess most distributions have patches for it, at least Ubuntu.

According to this mailing list entry http://<email address hidden>/msg04078.html posted before the Intel devs are fully aware that textured video does tear and it looks like that it does on every Intel card. They were planning to fix this with DRI2 but the changes doesn't make it in time.
Furthermore it was no problem for them to disable and remove the non tearing output - overlay - a year ago or something like that.

I guess either Intel devs doesn't watch videos with their pcs, have another graphic card, always use patched drivers or live in the future/have a time machine :D .

I mean if this situation appears for some weeks or a month, nobody would care but you wouldn't salvage your only car if your new one arrives in over a year.

Maybe it is only me but I don't get it.

By the way, is it only possible for a gl-based compositing manager (such as compiz) to use sync to vblank to get rid of tearing, or would it also be possible for an xrender based one (such as metacity)?

If X has an equivalent of glXSwapBuffers, and we can make it swap w/o tearing, then yes. But at this point that's not possible. And in fact even with a GL compositor it's not possible in a reliable way on Intel; we don't implement a reliable buffer swap, and waiting for vblank in the client is subject to scheduling hiccups, so isn't really suitable.

Does this thread solve this bug? I'm getting good results:

http://lists.freedesktop.org/archives/intel-gfx/2009-March/001608.html

>>>
I finally get to report some good news...great news in fact. I finally have
tear free XV fullscreen video on my G45. No Compiz needed, w00t! Thanks to
all the devs/community for getting it there.

I just sync'd to head on xf86-video-intel driver. This is what else I'm
running, all -9999 packages were sync'd to head within the last week of this
posting.

media-libs/mesa-9999
x11-libs/libX11-9999
x11-libs/libXext-9999
x11-libs/libXi-9999 (XInput.h moved to)
x11-libs/libdrm-9999
x11-libs/libxcb-9999
x11-proto/dri2proto-9999
x11-proto/inputproto-9999 (XInput.h moved from)
x11-proto/xcb-proto-9999
x11-proto/xextproto-9999
x11-proto/xproto-9999
x11-drivers/xf86-input-evdev-2.1.3
x11-drivers/xf86-input-keyboard-1.3.2
x11-drivers/xf86-input-mouse-1.4.0
x11-drivers/xf86-video-intel-9999
x11-base/xorg-server-1.6.0
x11-wm/openbox-3.4.7.2
kernel intel-drm 2.6.28 (w/ patches)
gentoo ~amd64

Runs mythfrontend, openbox, and X, within 1gig of ram. Fullscreen video with
EXA was tear-free at 1080p and 720p, E8400 cpu ~20-27%

fixed in xf86-video-intel
commit 67fef27f4b76490be085d232aba0ca9cbb3c5e59
Author: Xiang, Haihao <email address hidden>
Date: Fri Mar 6 09:40:07 2009 +0800

    Xv: free tearing on textured video

    Add an Xv attribute XV_SYNC_TO_VBLANK which has three values -1(auto), 0(off)
    and 1(on) to control whether textured adapter synchronizes the screen
    update to the vblank. The default value is -1(auto).

The description in the man page is a bit confusing:

 It has three
 values 'auto'(-1), 'off'(0) and 'auto'(1). 'off' means never sync, 'on' means
 always sync, no matter what size, and 'auto' means sync if the Xv image is
 more than quarter of the pixels on the screen. The default is 'auto'(-1).

I guess it should say 'on'(1)?

As for tearing, it doesn't seem to be fixed on my G45.

The default value of XV_SYNC_TO_VBLANK seems to be 1. Even if I manually set -1 or 0, it's set back to 1 after using MPlayer.

(In reply to comment #32)
> The description in the man page is a bit confusing:
>
> It has three
> values 'auto'(-1), 'off'(0) and 'auto'(1). 'off' means never sync, 'on' means
> always sync, no matter what size, and 'auto' means sync if the Xv image is
> more than quarter of the pixels on the screen. The default is 'auto'(-1).
>
> I guess it should say 'on'(1)?
It should be 'on' (1).

> As for tearing, it doesn't seem to be fixed on my G45.
Really? I tested on my GM965/GM45/G45 and don't see tearing any more. Comment #30 also said he got good result on his G45.

> The default value of XV_SYNC_TO_VBLANK seems to be 1. Even if I manually set -1
> or 0, it's set back to 1 after using MPlayer.
The default valude is -1, you can use xvattr to query it before using MPlayer. It is changed by MPlayer. (some other video drivers also have XV_SYNC_TO_VBLANK attribute, and MPlayer sets it to sync by default)

>

(In reply to comment #33)
> Really? I tested on my GM965/GM45/G45 and don't see tearing any more. Comment
> #30 also said he got good result on his G45.

Yeah, it's weird, tearing seems worse now. There's almost always a horizontal tear in any full-screen video.

I figured out why. It's because of the Xrender based compositor Metacity uses.

It is limited to 50 fps at the moment, I have tried to increase the refresh rate, but so far I haven't noticed a difference.

It seems to work fine if the compositor is turned off, so I guess this problem lies with metacity?

Jesse has some commits to eliminate tearing when using composite manager, but he doesn't push them out now.

Is this supposed to be fixed in intel 2.6.3?
It is not so I think this bug shouldn't be marked as resolved.

(In reply to comment #37)
> Is this supposed to be fixed in intel 2.6.3?
> It is not so I think this bug shouldn't be marked as resolved.

We already have https://bugs.freedesktop.org/show_bug.cgi?id=20664 open for the composite tearing case. Our driver doesn't yet support a good method to prevent tearing of OpenGL or composited applications, but I have some patches to add that. I'll point people at them in #20664.

Just so that I understand unggnu's comment correctly... This bug isn't fixed in 2.6.3, but is fixed in the repository and that fix will be released in 2.7, right?