Bug 19635

The current suggested solution is to use a vblank synced composite window manager like compiz. Does that work for you?

Compiz didn't seem to work for me. It might be a configuration problem, but I made sure unredirect_fullscreen_windows is set to false, and sync_to_vblank is true.

I'm not using DRI2, and other apps seems to use sync to vblank.

What info is needed for this bug to progress?  I can get you whatever is needed.

I'm running an intel DG45FC with G45/X4500HD on gentoo amd64.  I only use this machine for fullscreen video (HTPC) so tearing is really the only thing that matters to me.  I was running the 2008Q4 package with DRI2 but now i'm back on 2.5.1.

(In reply to comment #3)
> What info is needed for this bug to progress?  I can get you whatever is
> needed.

Does using compiz avoid tearing?

Hi all,
  I'm seeing this on ubuntu jaunty when running mythtv.  I've tried both with and without compiz (compiz is on by default in jaunty - I turned it off to see if that would help).  It doesn't seem to make any difference.  The myth logs show:

2009-01-31 12:10:52.935 Video timing method: DRM

Which suggests that myth is trying to vsync.  It just doesn't seem to be successful.  (although the tear is often in a consistent location which might suggest it is sync'd to the VBI, just not in phase... or something.)

I also note that the mailing list mail #042530 mentioned in the original report mentions a patch that would fix this in a kludgy way.  Is there a pointer to that patch anywhere for those of us who wouldn't mind a short term kludge?

Be well,

Will

Eric, so compiz doesn't help. Any other idea?

Is this the kludgy fix?
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=555eea5411cf8c725df5f1b4cb80198fa6a1225b

(In reply to comment #7)
> Is this the kludgy fix?
> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=555eea5411cf8c725df5f1b4cb80198fa6a1225b
> 

That switch seems to be off in the source of the package I'm using.  I'll switch it on and test it tonight.

I note that this is in a file called intel_xvmc.c.  How should the use of mythtv's xv-blit renderer vs their xvmc renderer affect this?  Does xv-blit also use the textured video system?

Okie - that patch seems to make a difference to XVMC output.  I'm just about to return to the unpatched version to check this (I have been using XV-blit, but I tested XVMC a while ago to see if it would help).  Unfortunately this only solves the problem for XVMC.

I still see tearing with normal XV-blit output.  And I can't use XVMC output with HD video (I've heard this is a standard limitation - is that right?).

Looking in my mythfrontend logs it seems I can answer my own question from above - xv-blit is using textured video.  Here are the relevant mythfrontend logs:

2009-02-09 20:20:33.867 VideoOutputXv: @ j=0 Looking for flag[s]: XvInputMask XvImageMask  10
2009-02-09 20:20:33.867 VideoOutputXv: Adaptor#0: Intel(R) Textured Video has flag[s]: XvInputMask XvImageMask
2009-02-09 20:20:33.867 VideoOutputXv: Has XVideo flags...
2009-02-09 20:20:33.867 VideoOutputXv: Has XV_BRIGHTNESS...
2009-02-09 20:20:33.867 VideoOutputXv: Here...
2009-02-09 20:20:33.867 VideoOutputXv: Grabbed xv port 80
2009-02-09 20:20:33.867 VideoOutputXv: XVideo surface found on port 80
2009-02-09 20:20:33.868 VideoOutputXv: XVideo Adaptor Name: 'Intel(R) Textured Video'
2009-02-09 20:20:33.868 VideoOutputXv: XVideo Format #0 is 'YUY2'
2009-02-09 20:20:33.868 VideoOutputXv: XVideo Format #1 is 'YV12'
2009-02-09 20:20:33.868 VideoOutputXv: XVideo Format #2 is 'I420'
2009-02-09 20:20:33.868 VideoOutputXv: XVideo Format #3 is 'UYVY'
2009-02-09 20:20:33.868 VideoOutputXv: XVideo Format #4 is 'XVMC'
2009-02-09 20:20:33.868 VideoOutputXv: Using XVideo Format 'YV12'
2009-02-09 20:20:33.868 VideoOutputXv: CreateShmImages(32): video_dim: 720x576
2009-02-09 20:20:33.893 VDP: SetVideoRenderer(xv-blit)
[snip]
2009-02-09 20:20:34.245 Video timing method: DRM

BTW - if I say anything stupid here, please correct me.  I'm not an expert on this stuff and am picking it up as I go along.

I finally got Compiz Fusion compiled, installed and running.  So it actually did correct the tearing, for both 720p and 1080i (don't have any 1080p video content).  I output 1080p via HDMI though.  BUT, and this is a big but, I can't really run compiz because I'm running a diskless client (over NFS) with 2GB of RAM and zero swap.  So where as before I was running X, openbox, mythfrontend within 500MB of ram now X, Compiz (with just about all plugins disabled), and mythfrontend now takes up all 2GB.  So now I have video buffering problems. 1080i seems to run ok, but 720p stutters horribly.

I'm running:
Gentoo but using Intel Kernel (.28 w/ 6 patches)
Xorg-server-1.5.99.901 (1.6 rc1)
mesa-9999 (as of couple weeks ago)
xf86-video-intel-2.6.1

Others things to note:
Using DRI2/UXA there was a LOT of refreshing problems. Pretty much the only thing that looked right was fullscreen video.  The mythfrontend wasn't drawing anything else correctly. I'll have to double check if 720p content played correctly here, I only tried 1080i.

Using EXA everything looked great, but it was very slow and, like I stated above, very memory intensive. I'm assuming 720p playback issues where from memory buffering problems though.

(In reply to comment #10)
Forgot to state I'm running compiz-0.7.8 (with the sync to vblank checkbox on under the General options).

I might have made a user error with my compiz testing.  To get the vsync setting on ubuntu you need to install the compizconfig-settings-manager package.  The vsync setting was off by default.  It made little difference, but I still need to double-check the unredirect_fullscreen_windows setting.  I'll try to check this in the next few days.

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

Did a little more testing, here is what I found:

Part of my memory problem was that I was compiling in a tmpfs and forgot to clear it.  Clearing it resolved the stuttering problem, although xorg is still taking up 700MB of ram, conbined with compiz and mythfrontend its still using all 2GB of ram.  Doesn't that seem a little odd?

DRI2/UXA tearing was still a problem for 720p content. Just a general note that DRI2/UXA is pretty unusable at the moment, at least for my current setup.

As for EXA, things seem to be doable for now.  Its not as snappy, but at least the video doesn't tear.

Also, forgot to mention I'm running an E8400 cpu, core 2 duo 3GHz.

I tested with compiz + syncing option + ! unredirect full screen option.  Still tears.  Again, tearing is consistent in location - the tear isn't slowly moving up or down as I've seen on previous hardware with tearing issues.  Tearing seems to be more noticeable with SD content (PAL 720x576 interlaced) than with HD content (1080i?).

FWIW: I'm running a E7300 (2.66 GHz Core 2 Duo) and a Gigabyte GA-EG45M-D2SH motherboard using builtin video.  The screen is a Samsung LCD connected using DVI.

I noticed some tearing last night when viewing SD 480i content.  The horiz tear was right in the middle of the screen.  Didn't move up or down.  Looked pretty bad.

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://www.mail-archive.com/xorg@lists.freedesktop.org/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://www.mail-archive.com/xorg@lists.freedesktop.org/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 <haihao.xiang@intel.com>
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?