X.org xf86-video-intel

[sandybridge] Graphics tearing when playing video

Reported by Benjamin Drung on 2011-04-09
244
This bug affects 49 people
Affects Status Importance Assigned to Milestone
Compiz Core
Medium
Daniel van Vugt
Ubutter
Undecided
Unassigned
xf86-video-intel
Fix Released
Wishlist
compiz (Ubuntu)
Undecided
Daniel van Vugt
xserver-xorg-video-intel (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

Videos tear heavily.

WORKAROUND:

Enable "Force full screen redraws (buffer swap) on repaint" in the Workarounds section of ccsm. If you don't have ccsm installed, you can get it by installing package "compizconfig-settings-manager".

---
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
ProcVersionSignature: Ubuntu 2.6.38-8.41-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
DRM.card0.DP.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.DP.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1920x1200 1600x1200 1280x1024 1280x1024 1280x960 1152x864 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 640x480 640x480 640x480 640x480 720x400
 edid-base64: AP///////wBMLbYCNDJVSCQSAQOANCCgKlrRp1ZLmyQTUFS/74CpQIGAgUBxTwEBAQEBAQEBKDyAoHCwI0AwIDYABkQhAAAaAAAA/QA4Sx5REQAKICAgICAgAAAA/ABTeW5jTWFzdGVyCiAgAAAA/wBIOVhROTAxMjY0CiAgAJw=
DRM.card0.HDMI.A.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Sat Apr 9 23:52:32 2011
DistUpgraded: Log time: 2011-03-11 00:20:27.564047
DistroCodename: natty
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:844d]
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100921.1)
MachineType: System manufacturer System Product Name
ProcEnviron:
 LANGUAGE=de_DE:en
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-8-generic root=UUID=782d30b2-7975-4d00-bf3e-de316d2b96f6 ro quiet splash vt.handoff=7
Renderer: Unknown
SourcePackage: xserver-xorg-video-intel
UpgradeStatus: Upgraded to natty on 2011-03-11 (29 days ago)
dmi.bios.date: 02/11/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0806
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8H67-M PRO
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0806:bd02/11/2011:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP8H67-MPRO:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
version.compiz: compiz 1:0.9.4+bzr20110407-0ubuntu2
version.ia32-libs: ia32-libs 20090808ubuntu11
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.1-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu6

Related branches

lp:~vanvugt/compiz-core/fix-880707.2
Merged into lp:compiz-core/0.9.5 at revision 2915
Sam Spilsbury: Approve on 2012-01-18
Compiz Maintainers: Pending requested 2011-11-26
Tim Penhey: Pending requested 2011-11-26
Benjamin Drung (bdrung) wrote :
bugbot (bugbot) on 2011-04-10
tags: added: tearing
Benjamin Drung (bdrung) wrote :

I get multiple of these in my Xorg.log:
(WW) intel(0): first get vblank counter failed: Invalid argument

Benjamin Drung (bdrung) wrote :

A locally built xserver-xorg-video-intel 2:2.14.902-1+exp1 from Debian experimental seems to fix the tearing problem for me.

Bryce Harrington (bryce) wrote :

Benjamin, would you be willing to do a git bisection between 2.14.0 and 2.14.902 to see what patch fixes the tearing for you?

Directions for bisection searches are available at http://wiki.ubuntu.com/X/Bisecting

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Benjamin Drung (bdrung) wrote :

I started to bisect the changes, but I failed to reproduce the tearing with the 2.14.0 git commit. Then I tried xserver-xorg-video-intel 2:2.14.0-4ubuntu7, which surprisingly does not tear too. Even xserver-xorg-video-intel 2:2.14.0-4ubuntu6 does not tear any more.

I don't get these messages in the Xorg.log any more:
(WW) intel(0): I830DRI2GetMSC:1064 get vblank counter failed: Invalid argument
(WW) intel(0): I830DRI2ScheduleWaitMSC:1124 get vblank counter failed: Invalid argument
(WW) intel(0): first get vblank counter failed: Invalid argument

This tearing problem was probably fixed by an update of another package. I am marking this bug as invalid.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Invalid
Dmitry Savin (envelsavinds) wrote :

The issue is still present in final Natty release with integrated i5-2500 video. A bit less but still exist. No strange messages in logs. You can see tearing in the upper third part of the screen at resolution 1920x1080. Intel drivers on Windows 7 give no tearing. I will try to test a new 2.15.0 driver from xorg-edgers/ppa and write about results. The things like this and "GPU Hang"make the system hardly usable on my configuration.

Dmitry Savin (envelsavinds) wrote :

The bug is present also with drivers 2.15.0 as well as without composite WM at all. In the last case it is even worth - no frames syncronization at all (I see tearing and video speed is about two times slower).

Changed in xserver-xorg-video-intel (Ubuntu):
status: Invalid → New
Dmitry Savin (envelsavinds) wrote :

It seems that the bug is reproducible only with Full HD video (1920x1088). And only with XV output not with all players.
It looks like a performance issue with large textures.

Benjamin Drung (bdrung) wrote :

I experience tearing if I restart compiz.

David Schleef (dschleef) wrote :

This can be reproduced/tested quickly and easily by using:

gst-launch videotestsrc pattern=blink ! video/x-raw-yuv,framerate=60/1 ! xvimagesink

panic_button (panic-button) wrote :

I have reproduced the problem on Ubuntu Natty and LMDE with recent kernels. I'd say this is a pretty big issue, since this is the main thing holding me back from using linux as my main OS. Fullscreen full HD video with tearing is unacceptable for users who spend any amount of time on YouTube.

Dmitry Savin (envelsavinds) wrote :

I think video tearing on YouTube is not a driver issue. It happens with all drivers. What I talked about is the issue with new intel driver (2.14.0) which is included in Ubunut and (as announced) supports SandyBridge integrated graphics. OpenGL and Video tear like hell in spite of vsync set to true.

panic_button (panic-button) wrote :

I updated to 2.15 and with the latest Flash release, I no longer have issues. Also, downloaded flash plays well in any media player. Not sure if this is a cure-all, but at least for flash it is.

Curtis Gedak (gedakc) wrote :

I too am experiencing High Definition video tearing with my Intel sandybridge CPU/GPU processors. Most of the time the tearing occurs on the upper third of the screen.

This problem occurs on both an Intel i7-2600K and on an Intel i5-2500K. Both of these chips feature Intel High Definition Graphics 3000. The problem is prevalent at a resolution of 1920x1080, but can also be seen at 1680x1050.

I have tried Kubuntu Natty Narwhal 11.04 with the latest xserver-xorg-video-intel driver package (2:2.15.0+git20110513.9d6e02al-0ubuntu0sarvatt) but the problem persists.

I have tried VLC, DragonPlayer, MPlayer, and MythTV, but all display the video tearing problem.

This problem is very frustrating when trying to watch HDTV shows with MythTV.

If more information is needed to diagnose and troubleshoot this problem then I would be more than happy to help.

19 comments hidden view all 169 comments

Any video tears with sandybridge graphics (i5-2500 integrated) with intel driver version 2.14.0. Updating to version 2.15.0 doesn't solve the problem.
Distro LinuxMint 11 (the same was in Ubuntu 11.04 with all updates). OpenGL apps tear as well.

uname -a:
Linux envel 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux

xvinfo:
X-Video Extension version 2.2
screen #0
  Adaptor #0: "Intel(R) Textured Video"
    number of ports: 16
    port base: 83
    operations supported: PutImage
    supported visuals:
      depth 24, visualID 0x21
    number of attributes: 3
      "XV_BRIGHTNESS" (range -128 to 127)
              client settable attribute
              client gettable attribute (current value is 0)
      "XV_CONTRAST" (range 0 to 255)
              client settable attribute
              client gettable attribute (current value is 0)
      "XV_SYNC_TO_VBLANK" (range -1 to 1)
              client settable attribute
              client gettable attribute (current value is 1)
    maximum XvImage size: 2048 x 2048
    Number of image formats: 5
      id: 0x32595559 (YUY2)
        guid: 59555932-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x32315659 (YV12)
        guid: 59563132-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x30323449 (I420)
        guid: 49343230-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x59565955 (UYVY)
        guid: 55595659-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x434d5658 (XVMC)
        guid: 58564d43-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

Created attachment 47245
Xorg log

The ability to wait upon scanlines was apparently defeatured, or at least disappeared from the specs...

Created attachment 47246
Tearing screenshot

(In reply to comment #2)
> The ability to wait upon scanlines was apparently defeatured, or at least
> disappeared from the specs...

Where can I find specs and how it is implemented for other intel graphics chips? (I have x86-video-intel-2.15.0 source code in front of me). I think it is important issue for desktop computers with Intel graphics.

(In reply to comment #2)
> The ability to wait upon scanlines was apparently defeatured, or at least
> disappeared from the specs...

It looks like it is defeatured. glxgears shows me 60fps with tearing.

Finally I found the ability to enable wait_for_scan_line support on SandyBridge.
According to specs, we should use DE_LOAD_SL ("This register is used to initiate a display scan line compare on DevSNB:D2 and later steppings"). To load a value to this register it is needed to use MI_LOAD_REGISTER_IMM. So the algorithm should be the following:

1. Calculate start/end scan lines
2. Call MI_LOAD_REGISTER_IMM with DE_LOAD_SL address and parameter equals to (0x11x<<29 | (start_sl<<16) | end_sl), where x represents pipe (0 for A, 1 for B).
3. Call MI_WAIT_FOR_EVENT with corresponding bits set to true (wait for pipe A/B scan line). Notice, that these bits are changed since last docs version.

The above should work but I didn't succeed. The problem could be with MI_LOAD_REGISTER_IMM (no rights for changing register) or even with hardware version. Of course, I may be wrong with the algorithm above.

24 comments hidden view all 169 comments
Dmitry Savin (envelsavinds) wrote :

Ok, I've got an explanation for this bug from developer. He said that "The ability to wait upon scanlines was apparently defeatured, or at least disappeared from the specs". It means that it will not be implemented at all.
I spent two days looking into the specs and writing the code. Yes, Intel changed the mechanism of waiting for scan line window and vblank events. I wrote new implementation for SandyBridge. All I've got is periodical video hang up every several seconds.
I continue to contact developer of this part and try to understand what I did wrong.

The simple way to test for this bug is to start video and press PrintScreen on dynamic scene. You will see teared picture.

There's a link to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=37686

Curtis Gedak (gedakc) wrote :

Thank Envel for reporting you findings and the link to the other bug report.

While researching this problem I came across the following Intel Linux Graphics documentation:
http://intellinuxgraphics.org/documentation.html

My thoughts are that this problem must be solvable, or else why would Intel call this Graphics Processing Unit "High Definition Graphics 3000". ;-)

I also recall reading somewhere that the problem did not arise in MS Windows.
Can someone with MS Windows test to see if there is video tearing while viewing HD video in Windows?

Download full text (4.6 KiB)

No problem in Windows. This is Linux-specific.

On Sun, May 29, 2011 at 10:06 PM, Curtis Gedak <email address hidden> wrote:

> Thank Envel for reporting you findings and the link to the other bug
> report.
>
> While researching this problem I came across the following Intel Linux
> Graphics documentation:
> http://intellinuxgraphics.org/documentation.html
>
> My thoughts are that this problem must be solvable, or else why would
> Intel call this Graphics Processing Unit "High Definition Graphics
> 3000". ;-)
>
> I also recall reading somewhere that the problem did not arise in MS
> Windows.
> Can someone with MS Windows test to see if there is video tearing while
> viewing HD video in Windows?
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/755841
>
> Title:
> [sandybridge] video tearing
>
> Status in “xserver-xorg-video-intel” package in Ubuntu:
> New
>
> Bug description:
> Binary package hint: xserver-xorg-video-intel
>
> Videos tear heavily.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.04
> Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
> ProcVersionSignature: Ubuntu 2.6.38-8.41-generic 2.6.38.2
> Uname: Linux 2.6.38-8-generic x86_64
> Architecture: amd64
> CompizPlugins: No value set for
> `/apps/compiz-1/general/screen0/options/active_plugins'
> CompositorRunning: compiz
> DRM.card0.DP.1:
> status: disconnected
> enabled: disabled
> dpms: Off
> modes:
> edid-base64:
> DRM.card0.DP.2:
> status: disconnected
> enabled: disabled
> dpms: Off
> modes:
> edid-base64:
> DRM.card0.HDMI.A.1:
> status: connected
> enabled: enabled
> dpms: On
> modes: 1920x1200 1600x1200 1280x1024 1280x1024 1280x960 1152x864 1024x768
> 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 640x480 640x480
> 640x480 640x480 720x400
> edid-base64:
> AP///////wBMLbYCNDJVSCQSAQOANCCgKlrRp1ZLmyQTUFS/74CpQIGAgUBxTwEBAQEBAQEBKDyAoHCwI0AwIDYABkQhAAAaAAAA/QA4Sx5REQAKICAgICAgAAAA/ABTeW5jTWFzdGVyCiAgAAAA/wBIOVhROTAxMjY0CiAgAJw=
> DRM.card0.HDMI.A.2:
> status: disconnected
> enabled: disabled
> dpms: Off
> modes:
> edid-base64:
> DRM.card0.VGA.1:
> status: disconnected
> enabled: disabled
> dpms: Off
> modes:
> edid-base64:
> Date: Sat Apr 9 23:52:32 2011
> DistUpgraded: Log time: 2011-03-11 00:20:27.564047
> DistroCodename: natty
> DistroVariant: ubuntu
> GraphicsCard:
> Intel Corporation 2nd Generation Core Processor Family Integrated
> Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller])
> Subsystem: ASUSTeK Computer Inc. Device [1043:844d]
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64
> (20100921.1)
> MachineType: System manufacturer System Product Name
> ProcEnviron:
> LANGUAGE=de_DE:en
> LANG=de_DE.UTF-8
> SHELL=/bin/bash
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-8-generic
> root=UUID=782d30b2-7975-4d00-bf3e-de316d2b96f6 ro quiet splash vt.handoff=7
> Renderer: Unknown
> SourcePackage: xserver-xorg-video-intel
> UpgradeStatus: Upgraded to natty on 2011-03-11 (29 days ago)
> dmi.bios.date: 02/11/2011
> dmi.bios.vendor: American Megatrends Inc....

Read more...

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed

Actually, the bug at freedesktop was reported by me (here's my nickname). I'll keep updating on my progress according to this bug.

Curtis Gedak (gedakc) wrote :

Envel, if you need help with testing or something else just let me know. I do have a background in C and am the maintainer of the GParted application.

I have two systems for testing:
- ASUS P8M61-M motherboard and an Intel i5-2500k CPU
- ASUS P8M67-M Pro/CSM motherboard and an Intel i7-2600k CPU

The video tearing problem occurs even with the faster CPU/GPU.

Changed in xserver-xorg-video-intel:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Cam Hutchison (camh) wrote :

I'm happy to help with testing if needed. I have just built an i7-2600k attached to a 2560x1600 monitor. I am running Debian unstable, which should be close enough to Ubuntu for testing purposes.

Since people are saying the tearing is worse at higher resolutions, I thought I'd offer my screen.

I also have the problem of video tearing since upgrading to 11.04. The hardware is H55M-S2H M/B, i5-650 CPU, integrated graphics using i915 video driver.

The problem is evident when using (s)mplayer and mythtv, but not with totem and vlc.

Changed in xserver-xorg-video-intel:
importance: Wishlist → High

Perhaps I should mention that my 11.04 is the 32bit (i386) version, and that it is present with the "Ubuntu" and "Ubuntu Classic" profiles, the CPU is a "Clarkdale" not a "Sandybridge", and the monitor resolution is 1920x1200.

Curtis Gedak (gedakc) wrote :

Through trial and error I have discovered two work-arounds that appear to address the video tearing problem for 1080i video on Intel HD 3000 Graphics GPUs.

For mplayer see the following link:
https://bugs.freedesktop.org/show_bug.cgi?id=37686#c35

For mythtv see the following link:
https://bugs.freedesktop.org/show_bug.cgi?id=37686#c40

aefaradien (sen-aefaradien) wrote :

I am seeing the same issue on my I5-661 graphics. All compositing is disabled - I am only using Metacity. I tried the mplayer test in #23 but see tearing using both the "-vo gl2" and "-vo xv" options.
This is really annoying as I only upgraded to Natty (from Hardy) a couple of days ago and everything was fine then... Is it possible to "downgrade" to a more stable version of the intel drivers until this issue is fixed? Any work-around at all would be appreciated.

Peter Hall (peter-preacher) wrote :

Curtis, just wanted to confirm that your Mythtv-workaround worked perfectly for me, thanks a lot!

CPU usage is three times as high though, but I can live with that if it means HD-videos free from tearing.

Curtis Gedak (gedakc) wrote :

Eureka! I have discovered an even better work around for Mythbuntu MythTV. This new workaround not only addresses the video tearing problem, but also addresses the small amount of juddering that was present in the workaround identified in comment #23.

For Mythbuntu 11.04 MythTV see the following link:
https://bugs.freedesktop.org/show_bug.cgi?id=37686#c47

For reduced video tearing for the Kubuntu 11.04 KDE desktop see the following link:
https://bugs.freedesktop.org/show_bug.cgi?id=37686#c46

For a sample .mp4 file to test the video tearing problem see the following link:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/600178/comments/38

PhilippeDePass (depassp) wrote :

This bug is also affecting me. I'm quite disappointed that I decided to "upgrade" to 11.04.

Daniel van Vugt (vanvugt) wrote :

I suggest a good workaround for this bug, and also bug 880707, is to enable:
   "Force full screen redraws (buffer swap) on repaint"
in the Workarounds section of ccsm. You might also need to tick "Don't wait for video sync".

Now for the first time in a long time I have a tear-free sandybridge graphics experience.

If you don't have ccsm installed, you can get it by installing package "compizconfig-settings-manager".

Benjamin Drung (bdrung) wrote :

I can confirm, that these settings fix the tearing issue on my sandybridge system on Ubuntu 11.10 (oneiric).

description: updated
Daniel van Vugt (vanvugt) wrote :

If indeed the problem this bug describes is the error "(WW) intel(0): first get vblank counter failed: Invalid argument"
then I think my fix for bug 763005 will solve that. Because part of the fix for bug 763005 is to remove the need for compiz to get the vblank counter at all.

If this bug doesn't become a duplicate of bug 763005, maybe it can be considered a duplicate of the more general tearing bug 880707 which affects any graphics chip and has an exact known cause.

Renars G. (originalchoice) wrote :

Fix from post #28 does not work for me. Am using Ubuntu 11.10 with i3 sandy bridge and gnome-shell dm.

era (erik-thysell) wrote :

Running Kubuntu 11.10 I have tearing, lots of it, full screen (1920 x 1080) and windowed.
Running Unity (installed in Kubuntu) I have no tearing but blurring.
(Core i5 2405S + Asus P8H67-M EVO)

Daniel van Vugt (vanvugt) wrote :

I'm still working on improving the general tearing problem (for all graphics hardware) running compiz/unity in bug 880707. I am not fixing gnome-shell right now.

Tearing is almost always a bug in the application (compiz/unity or gnome-shell), and almost never a bug in the driver. If there is a driver issue then it's usually that the manufacturer has decided to turn off vsync support by default (which I think ATI did with fglrx and "Tear-free desktop"). However, Intel have the feature turned on by default and AFAIK you can't turn it off. So tearing with intel graphics will generally be resolved by fixing the application, and not the driver or X.

Changed in xserver-xorg-video-intel:
status: Confirmed → In Progress
summary: - [sandybridge] video tearing
+ [sandybridge] Graphics tearing when playing video
description: updated
Changed in compiz (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
Changed in compiz-core:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
Changed in compiz-core:
milestone: none → 0.9.6
importance: Undecided → Medium
tags: added: performance
Changed in compiz-core:
status: In Progress → Fix Committed
Changed in compiz (Ubuntu):
status: In Progress → Fix Released
Changed in compiz-core:
status: Fix Committed → Fix Released
JC Hulce (soaringsky) on 2012-04-26
Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Fix Released
96 comments hidden view all 169 comments

Using the GL tester, I get tearing in windowed mode when I have my TV hooked up.

(In reply to comment #85)
> (In reply to comment #72)
> > Just as an update from the past post.
>
> Thanks for the update!
>
> > Unfortunately, all my attempts for fixing this properly have failed so far, the
> > hardware does not wants to collaborate with the software for inter-ring
> > synchronization.
>
> I have a couple questions if you don't mind. In a previous comment, you
> mentioned that a fix would require work in the kernel, in libdrm and in the X
> driver. So is a fix really viable within the SNB product cycle? Does it affect
> Ivy Bridge as well? I ask because I may consider upgrading early to Ivy Bridge
> if this is no longer a issue.
>
> > So the workaround I used previously still applies - I need to disable
> > compositing and use either vaapi or gl rendering, which perform vsync'ed screen
> > updates. This way, I see no tearing.
>
> I can still see tearing with GL rendering. It's much less noticeable, but it's
> there. I can see it clearly when I'm watching basketball games in a 1080p TV
> (using HDMI), specially during the fastbreak, when the camera pans quickly. But
> yea, it's much better than X11, Xv or anything like that. Is this expected? I
> tested both with mplayer and VLC (glx output).
>
You might be seeing the effect as shown in my attachment (https://bugs.freedesktop.org/attachment.cgi?id=47585), which according to daniel vetter is "probably unfixable". I think this is because possibly that is actually an artifact of capturing the screenshot. However something else which happens for me is that in the vertical-bars video the bars don't move smoothly across the screen. I don't know how to really explain it, but it is as if my screen has a really slow switching time, so that the front of the bars (as they move) lights up, while the rear fades out. However this fading is not gradual, but seems to happen with a lot of 'blinking'. I'm not sure what is causing this yet, but I think it might be some artifact of the screen (seems to happen with some bars painted in the gimp, too), it looks quite weird.
Anyway make sure it's none of that, take a picture with a (decent) camera.

> I can't even test VAAPI. VLC supports it, but when I enable it, I get 100% CPU
> usage and less than 1 FPS for some reason. There's the mplayer patches for
> VAAPI support, but it seems in very bad shape. Is there a test program for
> VAAPI?
You can try the mplayer-vaapi branch at git://gitorious.org/vaapi/mplayer.git , which is maintained by Gwenole Beauchesne, who also works on intel's vaapi support. The mplayer version it is based on is quite old, and it is based on the original mplayer (not mplayer2), but it works fine nonetheless.

>
> For the record, I'm not running a composite manager.
>
> Thanks for looking into this Eugeni.

(In reply to comment #87)
> (In reply to comment #85)
> > I can still see tearing with GL rendering. It's much less noticeable, but it's
> > there. I can see it clearly when I'm watching basketball games in a 1080p TV
> > (using HDMI), specially during the fastbreak, when the camera pans quickly. But
> > yea, it's much better than X11, Xv or anything like that. Is this expected? I
> > tested both with mplayer and VLC (glx output).
> >
> You might be seeing the effect as shown in my attachment
> (https://bugs.freedesktop.org/attachment.cgi?id=47585), which according to
> daniel vetter is "probably unfixable". I think this is because possibly that is
> actually an artifact of capturing the screenshot. However something else which
> happens for me is that in the vertical-bars video the bars don't move smoothly
> across the screen. I don't know how to really explain it, but it is as if my
> screen has a really slow switching time, so that the front of the bars (as they
> move) lights up, while the rear fades out. However this fading is not gradual,
> but seems to happen with a lot of 'blinking'. I'm not sure what is causing this
> yet, but I think it might be some artifact of the screen (seems to happen with
> some bars painted in the gimp, too), it looks quite weird.
> Anyway make sure it's none of that, take a picture with a (decent) camera.

Note though that I'm seeing this in video, I'm not trying to take screenshots. Just to be clear.

> > I can't even test VAAPI. VLC supports it, but when I enable it, I get 100% CPU
> > usage and less than 1 FPS for some reason. There's the mplayer patches for
> > VAAPI support, but it seems in very bad shape. Is there a test program for
> > VAAPI?
> You can try the mplayer-vaapi branch at git://gitorious.org/vaapi/mplayer.git ,
> which is maintained by Gwenole Beauchesne, who also works on intel's vaapi
> support. The mplayer version it is based on is quite old, and it is based on
> the original mplayer (not mplayer2), but it works fine nonetheless.

I'll check that out, thanks.

I have tearing using Vlc on Intel HD Chipset Intel® Celeron® Processor G530 (Sandy Bridge), xf86-video-intel git version but even with 2.19.0 version, linux kernel 3.4.4, xorg-server-1.12.2, mesa 8.0.3, libdrm-2.4.33. I use openbox desktop manager, and the only workaround to avoid tearing is to use Vlc Opengl video output together with Vlc fullscreen option. I notice tearing especially with 1920x1080 resolution video files.

(In reply to comment #89)
> I have tearing using Vlc on Intel HD Chipset Intel® Celeron® Processor G530
> (Sandy Bridge), xf86-video-intel git version but even with 2.19.0 version,
> linux kernel 3.4.4, xorg-server-1.12.2, mesa 8.0.3, libdrm-2.4.33. I use
> openbox desktop manager, and the only workaround to avoid tearing is to use Vlc
> Opengl video output together with Vlc fullscreen option. I notice tearing
> especially with 1920x1080 resolution video files.

With intel driver GIT Commit ID: 2941a5fe15626730869a48a63bb088e8ae2c0549, I can avoid tearing without vlc Opengl video output, but I need Vlc fullscreen option enabled. Intel driver accel method I use is SNA.

Just wanted to report that I seem to have less problems when using the SNA driver.

Reclaiming ownership, downgrading priority since this is impossible to fix without compromise with the current hardware support. For the foolhardy, you may like to try Option "TearFree" "true". It basically runs another compositor layer between the framebuffer and the scanout, so a major waste of memory if you are indeed using a pageflipping renderer (video player, game, compositor). And it exposes a few bugs in the Damage layer, so not ready for prime time just yet.

It is sad that Other OSes seem to have not problem with this basic functionality.
Could you tell us if Ivy Bridge suffers from the same issue? If no, SNB and IVB are pin-compatible, so people affected could just upgrade CPU.

By other OS, I presume you mean the ones that *only* support pageflipping compositors? Which for the reasons highlighted above work just fine.

IVB in theory supports vsync'ed writes to the scanout, give or take a few hundred microseconds in signal latency between the display engine and the render pipeline. When I get my hands on an IVB, I'll hook up the required kernel/xf86-video-intel infrastructure and see if the claimed retrofit of vsync works...

In the meantime, the only answer is take a leaf out of the other OSes playbook and only use pageflipping.

(In reply to comment #94)
> By other OS, I presume you mean the ones that *only* support pageflipping
> compositors? Which for the reasons highlighted above work just fine.
>
> IVB in theory supports vsync'ed writes to the scanout, give or take a few
> hundred microseconds in signal latency between the display engine and the
> render pipeline. When I get my hands on an IVB, I'll hook up the required
> kernel/xf86-video-intel infrastructure and see if the claimed retrofit of vsync
> works...
>
> In the meantime, the only answer is take a leaf out of the other OSes playbook
> and only use pageflipping.

Sorry i'm about to buy an IVB to replace my GMA950.
I've read that since v2.6.38 Linux handles page flipping and it also seems that DRI2 can handle it : am i wrong ? Therefore could it be solved using current stack ? Or is a new compositor like Wayland needed ? Thanks

If you have an unredirected fullscreen DRI2 application, then it will use pageflipping to update the scanout upon a SwapBuffers. So something as simple as 'mplayer -fs -vo gl' should be enough to achieve tear-free playback on most DE (you may have to tweak a few compositor settings if using one though).

(In reply to comment #96)
> If you have an unredirected fullscreen DRI2 application, then it will use
> pageflipping to update the scanout upon a SwapBuffers. So something as simple
> as 'mplayer -fs -vo gl' should be enough to achieve tear-free playback on most
> DE (you may have to tweak a few compositor settings if using one though).
Is this also true when you use multiple monitors (xrandr output follows)? Because I use mplayer -fs -vo gl with xf86-video-intel 8066bc33d78e78ce7c13833b08a7daaea2f3ed22 (AccelMethod SNA, TearFree not set) and I do notice tearing.

Here’s my xrandr output:
Screen 0: minimum 320 x 200, current 3520 x 1200, maximum 32767 x 32767
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm
   1600x1200 60.0*+
   1280x1024 75.0 72.0 60.0
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1920x1200+1600+0 (normal left inverted right x axis y axis) 474mm x 296mm
   1920x1200 60.0*+
   1600x1200 60.0
   1680x1050 60.0
   1280x1024 75.0 60.0
   1440x900 75.0 59.9
   1024x768 75.1 70.1 60.0
   800x600 72.2 75.0 60.3
   640x480 72.8 75.0 60.0
   720x400 70.1
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)

(In reply to comment #97)
> (In reply to comment #96)
> > If you have an unredirected fullscreen DRI2 application, then it will use
> > pageflipping to update the scanout upon a SwapBuffers. So something as simple
> > as 'mplayer -fs -vo gl' should be enough to achieve tear-free playback on most
> > DE (you may have to tweak a few compositor settings if using one though).
> Is this also true when you use multiple monitors (xrandr output follows)?
> Because I use mplayer -fs -vo gl with xf86-video-intel
> 8066bc33d78e78ce7c13833b08a7daaea2f3ed22 (AccelMethod SNA, TearFree not set)
> and I do notice tearing.

Same with UXA and vlc with glx output. No compositor here. I can clearly see tearing when I connect the laptop to an external monitor to watch movies.

I think there's two bugs being discussed here. One is that compositors that don't unredirect fullscreen windows may give you tearing. Another is that even without using a compositor, and even if you render using OpenGL, you can still get tearing.

Changed in ubutter:
status: New → Fix Released

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

I was redirected to this bug. In my case i have "tearing" only if i use mplayer with -vo xv. It plays fine with -vo gl2. No composite window manager used.
I also can reproduce it with 2.20, but _can't_ reproduce it with 2.17 - it's why i call it regression. Cris, are you sure it is the same bug?

I checked the screenshots and in may case it is not tearing.

(In reply to comment #92)
> Reclaiming ownership, downgrading priority since this is impossible to fix
> without compromise with the current hardware support. For the foolhardy, you
> may like to try Option "TearFree" "true". It basically runs another compositor
> layer between the framebuffer and the scanout, so a major waste of memory if
> you are indeed using a pageflipping renderer (video player, game, compositor).
> And it exposes a few bugs in the Damage layer, so not ready for prime time just
> yet.

I tried Option "TearFree" "true" with intel driver git version
146959dd5ef28384a3db4fce4bf7840f2b3ec58c or Intel 2.20.2 (with SNA acceleration enabled) + kernel 3.4.7 + vlc 2.0.3 and I did not have tearing anymore even disabling vlc fullscreen option.

The bug still present on the last kernel and Xorg. I have a tearing on the desktop and video players the only workaround to problem (enable Vsync) causes me mouse laggy on moviments of windows and all desktop objets icons, scroll bar, menus, etc...
I have a Intel HD 2000 Chipset Intel® Celeron® Processor B800
(Sandy Bridge).
Sorry for my bad English I am Spanish.

Forwarding a message from Axel Rohde

Hi Chris,

I just tested the standalone OpenGL compositor fbcompose
from this site
https://launchpad.net/~fluxbox-maintainers/+archive/nightly/+packages
  fluxbox-fbcompose_1.3.2+nightly+120311-1_amd64.deb

... on a i5-3550, Debian wheezy, xf86-video-intel-2.20.7 using SNA,
fvwm2.

By just starting fbcompose without any arguments I got rid of tearing
in non-fullscreen(!) mplayer2, mplayer-vaapi, smplayer2, totem and vlc/rvlc windows.
The latter three used to tear in fullscreen mode, too.

Since I was too lazy to compile it, I faked the unmet dependency on
libGLEW.so.1.6 by symlinks in /usr/lib/x86_64-linux-gnu
  ln -s libGLEW.so.1.7.0 libGLEW.so.1.6.0
  ln -s libGLEW.so.1.7.0 libGLEW.so.1.6

This seems to be the home of the project:
http://git.fluxbox.org/fluxbox_gediminas.git/

Before stumbling across fbcompose I tried Cairo-compmgr and dcompmgr,
both are unusable as they simply screw up the display.

The only side-effect of fbcompose I've spotted so far is
upscaling instead of tiling of the background bitmap.

This workaround can become a valueable comment to
https://bugs.freedesktop.org/show_bug.cgi?id=37686
for all users of "vintage" window managers.

--

Please note that this is the equivalent of Option "TearFree", with the extra latency of going through an external process.

I still can see tearing even if driver option "TearFree" is enabled, when I rotate display right or left (xorg monitor Option "Rotate"), so when the axes are reversed.

(In reply to comment #105)
> I still can see tearing even if driver option "TearFree" is enabled, when I
> rotate display right or left (xorg monitor Option "Rotate"), so when the
> axes are reversed.

Yup, that's expected at this moment in time. To avoid tearing down will require another indirection which I haven't added just yet.

Note in addition to using pageflipping via the TearFree option, there is a glimmer of light in the form of

kernel commit d7d4eeddb8f72342f70621c4b3cb718af9361712
Author: Chris Wilson <email address hidden>
Date: Wed Oct 17 12:09:54 2012 +0100

    drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffers

and

xf86-video-intel commit 891bae4aa91e85542dcbe38f6ee92141e3efc801
Author: Chris Wilson <email address hidden>
Date: Wed Oct 17 11:29:10 2012 +0100

    sna: Use the secure batches to program scanline waits on gen6+

to try and convince the hardware to do vsync'ed updates. (In terms of power efficiency, using pageflipping is the way forward as that is how the hardware is designed to operate. Also note that only the later steppings of SNB have scanline waits...)

I don't understand the technical details, so please forgive misunderstandings or stupid questions.

Do I need SNA for the TearFree option? I get stuttering with SNA and TearFree, and still get tearing with TearFree without SNA.
I created a xorg.conf with only the following:
Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "AccelMethod" "sna"
   Option "TearFree" "true"
EndSection
Is that the correct way to do it?

Is there any chance of a fix in the foreseeable future? Or is buying a graphics card a good idea at this point?

(In reply to comment #108)
> I don't understand the technical details, so please forgive
> misunderstandings or stupid questions.
>
> Do I need SNA for the TearFree option? I get stuttering with SNA and
> TearFree, and still get tearing with TearFree without SNA.
> I created a xorg.conf with only the following:
> Section "Device"
> Identifier "Intel Graphics"
> Driver "intel"
> Option "AccelMethod" "sna"
> Option "TearFree" "true"
> EndSection
> Is that the correct way to do it?
>
> Is there any chance of a fix in the foreseeable future? Or is buying a
> graphics card a good idea at this point?

The stuttering is more or less expected at this point (mostly depends upon a client stalling due to a readback) as TearFree is just a proof-of-principle, and only possible with SNA. I plan to finish the asynchronous implementation in the near future.

I'm now on Kubuntu 12.10 and I enabled in xorg.conf both the tearfree option and the sna acceleration. It's definitely better: the xv output seems fine so far in mplayer, the gl output is however unusable as the video keep halting during the play (truthfully I don't really care about it as long as the xv output works). Watching youtube gives me less headache but it still isn't perfect: on some videos there's sometimes still tearing. One thing that I also noticed: after watching a youtube video in fullscreen the display gets somehow corrupted at the bottom of the kde screen (the sidebar containing the desktop shortcuts, the clock, the minimized windows). When I pass the mouse pointer on it everything gets fine again (as it is refreshed) but not for long...

Should I expect some improvements in a more recent driver that the one provided in Kubuntu 12.10?

1 comments hidden view all 169 comments

Did some test here and I thinks I find out the origin of the issue ( comment #19 gave me the right hint, about overlay ):
Basically if you:
- disable composite ( sorry till now I cannot find a better solution )
AND
- [VLC] deselect this option: Video -> Display -> Accelerated video output (Overlay)
OR
- [VLC] select this video output: Video -> Output -> OpenGL GLX
You will not have any Tearing

I'm on Ubuntu 12.10 using SNA.

Tear is still present on video playback (mainly with VLC) with compositor enabled or disabled. (va-api enabled/disabled no changes as well)

this is my xorg.conf video options:

 Option "AccelMethod" "sna"
 Option "SwapbuffersWait" "false"
 Option "TearFree" "true"

Just want to add that TearFree option is not working as this command shows:

:~$ cat /var/log/Xorg.0.log |grep free
[ 5336.772] (**) intel(0): "Tear free" disabled

(In reply to comment #111)
> I'm on Ubuntu 12.10 using SNA.
>
> Tear is still present on video playback (mainly with VLC) with compositor
> enabled or disabled. (va-api enabled/disabled no changes as well)

Which is expected as Ubuntu 12.10 doesn't carry the required kernel patches.

vsync seems to be fully working now on SNB/IVB with 2.21 and kernel 3.8, so the remaining issue is to get TearFree solid and performant for all use cases.

Changed in xserver-xorg-video-intel:
importance: High → Wishlist

(In reply to comment #113)
> vsync seems to be fully working now on SNB/IVB with 2.21 and kernel 3.8, so
> the remaining issue is to get TearFree solid and performant for all use
> cases.
Thanks for working on this.

I have upgraded to Linux 3.8-rc7 and xf86-video-intel 2.21.2 on my ThinkPad X200 (Intel GM45) and on my workstation (Sandy Bridge GT2).

On my X200, I can use the TearFree option without any side-effects. If I enable it on my workstation though, the result of terminal commands such as ls -hl or ps auxf often lags — the lines appear one after another, just like on a serial connection. Just wanted to let you know in case you were not aware of that yet.

Let me know if you need any more details.

The cause is that replies end up being blocked by the synchronous pageflip used for the tear free update of the scanout. The solution is obvious, but just tricky to implement in an efficient manner that also solves the unnecessary readbacks. If I get it right the extra complexity should help for normal rendering as well.

Works great now, no more tearing. Thank you!

running ubuntu 13.04/kde 4.10 on my laptop (kernel 3.8/ ddx 2.21, ivybridge). kwin still tears at the top of the screen even with sna enabled and vsync on in kwin, but I assume thats just this bug: https://bugs.kde.org/show_bug.cgi?id=307965

So I tried disabling vsync in kwin and using the tearfree option which did remove all tearing, and seems to perform reasonably well for desktop usage and video playback (haven't tried anything else)

Since I saw fbcompose mentioned above as a lightweight standalone compositor that can produce tear-free output working around this issue, I'd like to mention I've found another similar compositor that seems to be under more active development:

Compton: https://github.com/chjj/compton

Its a nice lightweight compositor that doesn't need to replace your window manager or anything, so it can easily be used to work around this issue and get tear-free output. In my testing its been very stable too.

Using it with: compton --backend glx --paint-on-overlay --glx-no-stencil --vsync opengl-swc successfully completely removes tearing for me on both my intel machines (including in fullscreen video and with multiple displays), and performs better than using the TearFree xorg option :)

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

TearFree should be much improved as of:

commit fa2687bdd5a4c8bc608dac8bb711035f0752a725
Author: Chris Wilson <email address hidden>
Date: Mon Oct 21 18:55:23 2013 +0100

    sna: Eliminate the synchronous wait from inside TearFree

    Defer the actual wait until the next use of the screen pixmap, and then
    if needed replace the GPU bo with an alternative back buffer.

    Signed-off-by: Chris Wilson <email address hidden>

I'm happy with TearFree now. Please report any issues you find as separate bugs, thanks everyone.

Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released

Will it be made default? Tx

No. (Though there maybe some hardware which may require TearFree by default to function correctly, in which case it will be enabled automatically.) The problem is that it increases memory allocation considerably and reduces performance, giving you the same penalty as using a compositor. If you then use a compositor on top, you use even more memory to achieve the same effect. As such it is optional.

Displaying first 40 and last 40 comments. View all 169 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.