[sandybridge] Graphics tearing when playing video
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz Core |
Fix Released
|
Medium
|
Daniel van Vugt | ||
Ubutter |
Fix Released
|
Undecided
|
Unassigned | ||
xf86-video-intel |
Fix Released
|
Wishlist
|
|||
compiz (Ubuntu) |
Fix Released
|
Undecided
|
Daniel van Vugt | ||
xserver-xorg-video-intel (Fedora) |
Won't Fix
|
Undecided
|
|||
xserver-xorg-video-intel (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: xserver-
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-
---
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xserver-
ProcVersionSign
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
CompizPlugins: No value set for `/apps/
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/////
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=
Renderer: Unknown
SourcePackage: xserver-
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.
dmi.board.name: P8H67-M PRO
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: System Product Name
dmi.product.
dmi.sys.vendor: System manufacturer
version.compiz: compiz 1:0.9.4+
version.ia32-libs: ia32-libs 20090808ubuntu11
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.
version.
version.
version.
version.
version.
version.
Related branches
- Sam Spilsbury: Approve
- Compiz Maintainers: Pending requested
- Tim Penhey: Pending requested
-
Diff: 408 lines (+89/-150)3 files modifiedapiplugins/composite/src/privates.h (+2/-7)
plugins/composite/src/screen.cpp (+63/-131)
plugins/opengl/src/screen.cpp (+24/-12)
Benjamin Drung (bdrung) wrote : | #1 |
- BootDmesg.txt Edit (56.4 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (4.2 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.7 KiB, text/plain; charset="utf-8")
- GconfCompiz.txt Edit (36.4 KiB, text/plain; charset="utf-8")
- GdmLog.txt Edit (314.1 KiB, text/plain; charset="utf-8")
- GdmLog1.txt Edit (27.5 KiB, text/plain; charset="utf-8")
- GdmLog2.txt Edit (286.2 KiB, text/plain; charset="utf-8")
- Lspci.txt Edit (11.0 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (805 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (3.4 KiB, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (2.5 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (4.5 KiB, text/plain; charset="utf-8")
- UdevDb.txt Edit (153.9 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (333.7 KiB, text/plain; charset="utf-8")
- UnitySupportTest.txt Edit (603 bytes, text/plain; charset="utf-8")
- XorgLog.txt Edit (377.1 KiB, text/plain; charset="utf-8")
- XorgLogOld.txt Edit (39.6 KiB, text/plain; charset="utf-8")
- Xrandr.txt Edit (5.8 KiB, text/plain; charset="utf-8")
- monitors.xml.txt Edit (1.5 KiB, text/plain; charset="utf-8")
- peripherals.txt Edit (1.7 KiB, text/plain; charset="utf-8")
- xdpyinfo.txt Edit (9.7 KiB, text/plain; charset="utf-8")
- xinput.txt Edit (1.0 KiB, text/plain; charset="utf-8")
tags: | added: tearing |
Benjamin Drung (bdrung) wrote : | #2 |
Benjamin Drung (bdrung) wrote : | #3 |
A locally built xserver-
Bryce Harrington (bryce) wrote : | #4 |
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://
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | New → Incomplete |
Benjamin Drung (bdrung) wrote : | #5 |
I started to bisect the changes, but I failed to reproduce the tearing with the 2.14.0 git commit. Then I tried xserver-
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): I830DRI2Schedul
(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 : | #6 |
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 : | #7 |
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 : | #8 |
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 : | #9 |
I experience tearing if I restart compiz.
David Schleef (dschleef) wrote : | #10 |
This can be reproduced/tested quickly and easily by using:
gst-launch videotestsrc pattern=blink ! video/x-
panic_button (panic-button) wrote : | #11 |
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 : | #12 |
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 : | #13 |
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 : | #14 |
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-
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.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #34 |
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_CONTRAST" (range 0 to 255)
"
maximum XvImage size: 2048 x 2048
Number of image formats: 5
id: 0x32595559 (YUY2)
guid: 59555932-
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x434d5658 (XVMC)
guid: 58564d43-
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)
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #35 |
Created attachment 47245
Xorg log
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #36 |
The ability to wait upon scanlines was apparently defeatured, or at least disappeared from the specs...
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #37 |
Created attachment 47246
Tearing screenshot
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #38 |
(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-
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #39 |
(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.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #40 |
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_
1. Calculate start/end scan lines
2. Call MI_LOAD_
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_
Dmitry Savin (envelsavinds) wrote : | #15 |
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:/
Curtis Gedak (gedakc) wrote : | #16 |
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://
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?
panic_button (panic-button) wrote : Re: [Bug 755841] Re: [sandybridge] video tearing | #17 |
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://
>
> 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:/
>
> Title:
> [sandybridge] video tearing
>
> Status in “xserver-
> New
>
> Bug description:
> Binary package hint: xserver-
>
> Videos tear heavily.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.04
> Package: xserver-
> ProcVersionSign
> Uname: Linux 2.6.38-8-generic x86_64
> Architecture: amd64
> CompizPlugins: No value set for
> `/apps/
> 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/////
> 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=
> root=UUID=
> Renderer: Unknown
> SourcePackage: xserver-
> UpgradeStatus: Upgraded to natty on 2011-03-11 (29 days ago)
> dmi.bios.date: 02/11/2011
> dmi.bios.vendor: American Megatrends Inc....
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | New → Confirmed |
Dmitry Savin (envelsavinds) wrote : Re: [sandybridge] video tearing | #18 |
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 : | #19 |
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.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #41 |
For others reading this thread, this bug has also been reported for Ubuntu at:
https:/
Dmitry,
If you get stumped trying to solve this problem you reported, let me know. I am certainly not an expert in video graphic drivers, but I do have a background in C and might be able to provide a different perspective.
In freedesktop.org Bugzilla #37686, Gordon Jin (gordon-jin) wrote : | #42 |
This seems a major problem. Chris, can we not demote it?
But I don't know why I don't meet this issue.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #43 |
(In reply to comment #8)
> This seems a major problem. Chris, can we not demote it?
>
> But I don't know why I don't meet this issue.
I think you use a screen with smaller resolution (I've got 1920x1080). But if you make a screenshot you will see it teared especially for dynamic scenes.
Changed in xserver-xorg-video-intel: | |
importance: | Unknown → Wishlist |
status: | Unknown → Confirmed |
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #44 |
On my computers the problem most often appears when the scene is shifting from right to left, or vice versa. A common location for the tearing to appear is in the upper third of the screen. This happens when viewing HD content (1080i) using an LCD monitor with 1920x1080 resolution and also on one with 1680x1050 resolution.
On scenes with little or no movement the problem does not occur, or at least is not visible to the naked eye.
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #45 |
Just adding myself as a 'me too'. Video tears heavily, and it does not matter whether compositing is turned on or off, the tearing is the same.
I would also like to point out that 'SwapBuffers' is enabled, which as I understand should prevent any video-tearing. However it does not seem to work for some reason. Xorg log contains the following on 'swap':
--- Xorg.0.log ---
[ 13.803] (**) intel(0): Framebuffer tiled
[ 13.803] (**) intel(0): Pixmaps tiled
[ 13.803] (**) intel(0): 3D buffers tiled
[ 13.803] (**) intel(0): SwapBuffers wait enabled
[ 13.803] (==) intel(0): video overlay key set to 0x101fe
[ 13.810] (II) intel(0): Output LVDS1 has no monitor section
[ 13.810] (II) intel(0): found backlight control interface /sys/class/
--
[ 13.993] (II) Initializing built-in extension COMPOSITE
[ 13.993] (II) Initializing built-in extension DAMAGE
[ 14.445] (II) AIGLX: enabled GLX_MESA_
[ 14.445] (II) AIGLX: enabled GLX_INTEL_
[ 14.445] (II) AIGLX: enabled GLX_SGI_
[ 14.445] (II) AIGLX: enabled GLX_SGI_
[ 14.445] (II) AIGLX: GLX_EXT_
[ 14.445] (II) AIGLX: Loaded and initialized /usr/lib64/
---------
Other logs don't seems to have anything useful.
My hardware is Dell XPS 15 (L502x) with:
00:02.0 VGA compatible controller: Intel Corporation Device 0116 (rev 09)
[ 13.803] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #46 |
I spent a couple of days trying to understand what could be wrong with the algorithm I described. There could be two things:
1. MI_LOAD_
2. For the same reason, I cannot unmask VBLANK bit in DERRMR register.
I believe that MI_WAIT_FOR_EVENT works properly because it really locks the GPU while waiting for event which never happens (and I get slide-show but without tearing!)
Thus, I think that it may require to modify both user-space driver and kernel driver. But I still haven't found if it is possible to do MI_LOAD_
Sorry, I really have not enough time for this because of my main job.
In addition, Chris Wilson has dissapeared unexpectedly, a person who may help.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #47 |
Following are links to two vertical bar flash videos that will help test for video tearing.
Tearing test for Flash video player (24p source)
http://
Tearing test for Flash video player (30p source)
http://
On both of my Sandybridge GPU's (i5-2500K and i7-2600K) video tearing is apparent because the vertical bars do not always display as perfectly aligned.
Gordon Jin,
Would you be able to retry your testing to see if these videos demonstrate video tearing on your system?
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #48 |
(In reply to comment #13)
> Following are links to two vertical bar flash videos that will help test for
> video tearing.
>
> Tearing test for Flash video player (24p source)
> http://
>
> Tearing test for Flash video player (30p source)
> http://
>
> On both of my Sandybridge GPU's (i5-2500K and i7-2600K) video tearing is
> apparent because the vertical bars do not always display as perfectly aligned.
>
> Gordon Jin,
>
> Would you be able to retry your testing to see if these videos demonstrate
> video tearing on your system?
I believe flash tearing has another reasons. I doesn't use xvideo. When I checked my driver changes flash didn't lock while Totem did.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #49 |
(In reply to comment #14)
> I believe flash tearing has another reasons. I doesn't use xvideo. When I
> checked my driver changes flash didn't lock while Totem did.
Is there another definitive test that we could use for demonstrating this problem?
I have run the above flash video's on my Sandybridge computers, and on an older computer with an NVidia 8600 GT video card with proprietary drivers. The tearing problem rarely occurs with the NVidea 8600 GT. With the Sandybridge computers the tearing occurs frequently.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #50 |
(In reply to comment #15)
> (In reply to comment #14)
> > I believe flash tearing has another reasons. I doesn't use xvideo. When I
> > checked my driver changes flash didn't lock while Totem did.
>
> Is there another definitive test that we could use for demonstrating this
> problem?
>
> I have run the above flash video's on my Sandybridge computers, and on an older
> computer with an NVidia 8600 GT video card with proprietary drivers. The
> tearing problem rarely occurs with the NVidea 8600 GT. With the Sandybridge
> computers the tearing occurs frequently.
The test is very simple. Disable compiz and play video. If you cannot see tearing than press PrnScrn (better in fullscreen) and save the picture. When you open it you will see teared image.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #51 |
(In reply to comment #16)
> The test is very simple. Disable compiz and play video. If you cannot see
> tearing than press PrnScrn (better in fullscreen) and save the picture. When
> you open it you will see teared image.
Unfortunately I have not been able to capture the video tearing in the screenshot when I perform this test. I can see the video tearing occurring while the video plays (both in full screen and windowed), but I have been unsuccessful in capturing evidence of the video tearing in the screenshot.
The two systems I have are:
System A
--------
Asus P8H67-M Pro/CSM motherboard
Intel i7-2600K processor
Kubuntu 11.04 operating system
System B
--------
Asus P8H61-M motherboard
Intel i5-2500K processor
Mythbuntu 11.04 operating system
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #52 |
(In reply to comment #17)
> (In reply to comment #16)
> > The test is very simple. Disable compiz and play video. If you cannot see
> > tearing than press PrnScrn (better in fullscreen) and save the picture. When
> > you open it you will see teared image.
>
> Unfortunately I have not been able to capture the video tearing in the
> screenshot when I perform this test. I can see the video tearing occurring
> while the video plays (both in full screen and windowed), but I have been
> unsuccessful in capturing evidence of the video tearing in the screenshot.
>
> The two systems I have are:
>
> System A
> --------
> Asus P8H67-M Pro/CSM motherboard
> Intel i7-2600K processor
> Kubuntu 11.04 operating system
>
> System B
> --------
> Asus P8H61-M motherboard
> Intel i5-2500K processor
> Mythbuntu 11.04 operating system
Do it on dynamic scenes.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #53 |
(In reply to comment #18)
> Do it on dynamic scenes.
I have been doing this. I can see the video tearing occurring, but have been unable to capture it in a screenshot. Perhaps I am not fast enough in pressing the PrintScreen key. :-)
The picture you attached to this bug report definitely captured the screen tearing problem.
I have found more information about screen tearing on the MythTV web site:
http://
NVidia appears to have the best hardware and driver combination for avoiding video tearing on GNU/Linux. My testing with my 4 year old NVidia 8600 GT video card confirms this to be true. I experience no video tearing at all when using this old video card.
I have hope for the Intel drivers and Sandybridge GPUs because it has been stated that the video tearing problem does not occur in MS Windows.
Hopefully someone from the Intel team will be able to investigate this problem and develop a fix soon.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #54 |
(In reply to comment #19)
> (In reply to comment #18)
> > Do it on dynamic scenes.
>
> I have been doing this. I can see the video tearing occurring, but have been
> unable to capture it in a screenshot. Perhaps I am not fast enough in pressing
> the PrintScreen key. :-)
>
> The picture you attached to this bug report definitely captured the screen
> tearing problem.
>
> I have found more information about screen tearing on the MythTV web site:
> http://
>
> NVidia appears to have the best hardware and driver combination for avoiding
> video tearing on GNU/Linux. My testing with my 4 year old NVidia 8600 GT video
> card confirms this to be true. I experience no video tearing at all when using
> this old video card.
>
> I have hope for the Intel drivers and Sandybridge GPUs because it has been
> stated that the video tearing problem does not occur in MS Windows.
>
> Hopefully someone from the Intel team will be able to investigate this problem
> and develop a fix soon.
I don't have to do anything to see tearing. It is not so hard when compiz enabled because it limits frame rate to 60. When I disable it I can see teared image. If it was not so visible, I think I wouldn't open the bug and wouldn't try to fix it. As I can see for now, no one of developers cares about this. I think the better solution would be to buy cheap nvidia card (Nvidia drivers also have tearing with compiz enabled and "Redirect fullscreen" option not set but it is easy to solve).
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #55 |
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > Do it on dynamic scenes.
> >
> > I have been doing this. I can see the video tearing occurring, but have been
> > unable to capture it in a screenshot. Perhaps I am not fast enough in pressing
> > the PrintScreen key. :-)
> >
> > The picture you attached to this bug report definitely captured the screen
> > tearing problem.
> >
> > I have found more information about screen tearing on the MythTV web site:
> > http://
> >
> > NVidia appears to have the best hardware and driver combination for avoiding
> > video tearing on GNU/Linux. My testing with my 4 year old NVidia 8600 GT video
> > card confirms this to be true. I experience no video tearing at all when using
> > this old video card.
> >
> > I have hope for the Intel drivers and Sandybridge GPUs because it has been
> > stated that the video tearing problem does not occur in MS Windows.
> >
> > Hopefully someone from the Intel team will be able to investigate this problem
> > and develop a fix soon.
>
> I don't have to do anything to see tearing. It is not so hard when compiz
> enabled because it limits frame rate to 60. When I disable it I can see teared
> image. If it was not so visible, I think I wouldn't open the bug and wouldn't
> try to fix it. As I can see for now, no one of developers cares about this. I
> think the better solution would be to buy cheap nvidia card (Nvidia drivers
> also have tearing with compiz enabled and "Redirect fullscreen" option not set
> but it is easy to solve).
Please don't give up on this, I would like to help fix this as well. I don't have any experience with actually writing video-drivers but I can test patches etc. Can you please give some pointers on where exactly the problem is (kernel side or xorg-driver), and attach to this bug the code you already have? What documents are you using?
You say that the developers 'do not care', have you actually talked to them (perhaps they have a valid reason?).
Cam Hutchison (camh) wrote : | #20 |
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.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #56 |
If your e-mail is not responded for a long time it usually means that the person doesn't have enough time or simply ignores you. For me it means that I will not be able to solve the problem fastly.
I'll post my patches a bit later today. It would be great if you test it (may be hardware version is different and it will work on yours). It seems that the patch should be correct according to spec but it doesn't work on my machine.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #57 |
I've found that video tears also on iCore 1st generation. I don't know if it was with previous driver version (even more without compiz).
Actually, intel video driver tears on all modern equipment. That's the conclusion. This is probably more complex problem with XServer.
In freedesktop.org Bugzilla #37686, Paul Menzel (pm-debian) wrote : | #58 |
(In reply to comment #14)
> (In reply to comment #13)
> > Following are links to two vertical bar flash videos that will help test for
> > video tearing.
> >
> > Tearing test for Flash video player (24p source)
> > http://
> >
> > Tearing test for Flash video player (30p source)
> > http://
> >
> > On both of my Sandybridge GPU's (i5-2500K and i7-2600K) video tearing is
> > apparent because the vertical bars do not always display as perfectly aligned.
> >
> > Gordon Jin,
> >
> > Would you be able to retry your testing to see if these videos demonstrate
> > video tearing on your system?
>
> I believe flash tearing has another reasons. I doesn't use xvideo. When I
> checked my driver changes flash didn't lock while Totem did.
You can download the video files from YouTube using for example `clive` [1] and play it using any video player you like.
In freedesktop.org Bugzilla #37686, Paul Menzel (pm-debian) wrote : | #59 |
(In reply to comment #22)
> If your e-mail is not responded for a long time it usually means that the
> person doesn't have enough time or simply ignores you. For me it means that I
> will not be able to solve the problem fastly.
> I'll post my patches a bit later today. It would be great if you test it (may
> be hardware version is different and it will work on yours). It seems that the
> patch should be correct according to spec but it doesn't work on my machine.
Please also send the patches to the list (as a response to your message you just send) using `git format-patch -s` (and `git send-email`). Please describe your problem and your fix in the commit message [1] and state what does not work. I am pretty sure you will get more attention and reviews that way.
Thank you for working on this!
[1] http://
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #60 |
Created attachment 47585
Screenshot showing strange artifact(s) in tearing.
I downloaded one of the youtube video's mr. Savin linked to and made a screenshot too.
This is a screenshot of "Tearing test for Flash video player (30p source).1080p.mp4" played back using 'mplayer -vo xv', with XFCE compositing enabled. The turning compositing off does not make a difference and gives identical results. Also '-vo gl' gives identical results.
There are two interesting things to note here. The first is that there is not just *one* line where the video tears, but many (really a lot tbh). This can be seen in the previous screenshot of the playground too, but here it becomes really apparent.
What is even more interesting is the the strange artefact which can be seen on the right-most line, just below the middle of the screen. Here we can see *on the same line part* of the new AND of the old line (the lines in the video are moving left-to-right)! So the small thin upstanding line to the right is actually part of the next frame, and hence we are seeing parts of two frames on the same line.
Combining the above two facts I don't think this is a simple 'scanline interrupt not being triggered' bug, but indeed something else. This would also explain why mr. Savin's patch doesn't seem to fix the issue. Unfortunately I have no idea what could cause such strange artefacts in the video rendering...
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #61 |
(In reply to comment #26)
> Created an attachment (id=47585) [details]
> Screenshot showing strange artifact(s) in tearing.
>
> I downloaded one of the youtube video's mr. Savin linked to and made a
> screenshot too.
>
> This is a screenshot of "Tearing test for Flash video player (30p
> source).1080p.mp4" played back using 'mplayer -vo xv', with XFCE compositing
> enabled. The turning compositing off does not make a difference and gives
> identical results. Also '-vo gl' gives identical results.
>
> There are two interesting things to note here. The first is that there is not
> just *one* line where the video tears, but many (really a lot tbh). This can be
> seen in the previous screenshot of the playground too, but here it becomes
> really apparent.
>
> What is even more interesting is the the strange artefact which can be seen on
> the right-most line, just below the middle of the screen. Here we can see *on
> the same line part* of the new AND of the old line (the lines in the video are
> moving left-to-right)! So the small thin upstanding line to the right is
> actually part of the next frame, and hence we are seeing parts of two frames on
> the same line.
>
> Combining the above two facts I don't think this is a simple 'scanline
> interrupt not being triggered' bug, but indeed something else. This would also
> explain why mr. Savin's patch doesn't seem to fix the issue. Unfortunately I
> have no idea what could cause such strange artefacts in the video rendering...
whoops, made a mistake. Where I said 'just below the middle of the screen' I meant to say 'just below the top of the screen' (I must have been looking at another screenshot). Sorry if I confused anyone :)
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #62 |
Here's my patch below. Sorry for late response. I wonder what pixmap_is_scanout does. It always returns FALSE. Patch for intel driver 2.14.0 (the one in Ubuntu distro).
Gen6 wait for scanline event support
-------
index 93d03cf..0a5946c 100644
@@ -65,6 +65,19 @@
#define MI_LOAD_
#define MI_LOAD_
+/* Gen6 wait for scan line support */
+#define MI_LOAD_
+#define MI_DISPLAY_
+#define MI_DISPLAY_
+#define MI_DISPLAY_
+#define MI_DISPLAY_
+
+/* Scan lines register */
+#define DE_LOAD_SL_ADDR (0x4f100)
+#define DE_LOAD_SL_PIPEA (0x110<<29)
+#define DE_LOAD_SL_PIPEB (0x111<<29)
+#define DERRMR_ADDR (0x44050)
+
/* BLT commands */
#define COLOR_BLT_CMD ((2<<29)
#define COLOR_BLT_
-------
index 5294f73..506178f 100644
@@ -1365,6 +1365,83 @@ intel_wait_
ADVANCE_BATCH();
}
+static void
+intel_
+ xf86CrtcPtr crtc, RegionPtr clipBoxes)
+{
+ intel_screen_
+ pixman_box16_t box, crtc_box;
+ int pipe, event;
+ Bool full_height;
+ int y1, y2;
+
+ pipe = -1;
+ if (pixmap_
+ {
+ pipe = intel_crtc_
+ }
+ if (pipe < 0)
+ return;
+
+ box = *REGION_
+
+ if (crtc->
+ pixman_
+
+ /* We could presume the clip was correctly computed... */
+ intel_crtc_
+ intel_box_
+
+ /*
+ * Make sure we don't wait for a scanline that will
+ * never occur
+ */
+ y1 = (crtc_box.y1 <= box.y1) ? box.y1 - crtc_box.y1 : 0;
+ y2 = (box.y2 <= crtc_box.y2) ?
+ box.y2 - crtc_box.y1 : crtc_box.y2 - crtc_box.y1;
+
+ if (y2 <= y1)
+ return;
+
+ full_height = FALSE;
+ if (y1 == 0 && y2 == (crtc_box.y2 - crtc_box.y1))
+ full_height = TRUE;
+
+ if (pipe == 0) {
+ pipe = DE_LOAD_SL_PIPEA;
+ event = MI_DISPLAY_
+ if (full_height)
+ event = MI_DISPLAY_
+ } else {
+ pipe = DE_LOAD_SL_PIPEB;
+ event = MI_DISPLAY_
+ if (full_height)
+ event = MI_DISPLAY_
+ }
+
+ /* According to docs only upper 10 bits are significant */
+ if(!(y2 & 0x3))
+ y2 += 8;
+
+
+ y1 &= 0x1ff8;
+ y2 &= 0x1ff8;
+
+ if (crtc->mode.Flags & V_INTERLACE) {
+ /* DSL count field lines */
+ y1 /= 2;
+ y2 /= 2;
+ }
+
+ BEGIN_BATCH(4);
+ OUT_BATCH(
+ OUT_BATCH(
+ OUT_BATCH(pipe | (y1 << 16) | y2);
+ OUT_BATCH(
+ ADVANCE_BATCH();
+}
+
+
static Bool
intel_
int alloc_size, int id, unsigned char *buf)
@@ -1578,8 +1655,11 @@ I830PutImageTex
return Bad...
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #63 |
Thanks Dmitry for posting your attempt to address the video tearing problem. I hope to test your patch too, even if it does not yet resolve this problem.
Today I installed Ubuntu Desktop amd64 from scratch and then immediately tried the flash videos for video tearing. Neither of the flash videos showed any signs of video tearing. So it would seem that the problem with video tearing in flash is more related to the flash version and is a separate problem.
The flash version that I have installed currently is:
$ dpkg -l | grep -i flash
ii flashplugin-
$
So with some hope that the problem was fixed, I tried playing a Big Bang Theory video that I recorded using Mythtv. Unfortunately this video still displays the video tearing problem.
Dmitry, do you have any tips for installing the Intel source code and hacking on it?
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #64 |
In comment #29, I meant to say that I installed Ubuntu Desktop 11.04 amd64.
With regards to this video tearing problem, it appears that the desktop plays a role too.
With the same flash version installed I see the following results:
Flash video tearing occurs with KDE desktop, and XFCE4 desktop.
Flash video tearing _does not occur_ with Unity desktop.
I had expected that flash video would work identically in each of these desktops.
With the Big Bang Theory video (and different default video players) I see video tearing with each of the KDE desktop, XFCE4 desktop, and the Unity Desktop. These desktops are the defaults with kubuntu 11.04, mythbuntu 11.04, and ubuntu 11.04 respectively.
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #65 |
> Dmitry, do you have any tips for installing the Intel source code and hacking
> on it?
The problem I tried to solve is more complicated. Compiz uses other stuff for vertical sync. Using compiz vsync + video wait for scan line may give unpredictable results. Probably, it will tear even harder (like with radeon fglrx driver). So, solving the problem this way is not a good idea (it means don't care about this patch).
By the way, Eric Anholt from intel-gfx mailing list gave me the following answer why my patch doesn't work:
-----
You can't wait_for_event on scanlines in the BLT ring, so you'd want the
swap to be done using the 3D engine and have it preceded by a wait for
scanline there (if it works).
-----
I dig through the specs and found that all commands actually executed from one ring buffer and each certain command comes to the corresponding ring which actually executes it. Moreover, the similar code used to work in the similar place. So the problem is in hardware, I think.
The another possible solution may be to add overlay support for SandyBridge (putOverlayImage). It will solve tearing problem but, unfortunately, only for non-composite display.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #66 |
Thank you Dmitry for the follow up information on your patch. Your response led me to pursue other options.
One option I have been investigating is compiling VAAPI support into mplayer. I learned about this possibility at the following web site:
A NVIDIA VDPAU Back-End For Intel's VA-API
http://
This site leads to the following code for compiling mplayer with VAAPI support:
Splitted-desktop systems - Video Acceleration (VA) API
http://
I installed the Xorg Edgers PPA on my Kubuntu Natty Narwhal 11.04 system:
https:/
Then I installed the necessary prerequisites:
sudo apt-get install subversion yasm libxfixes-dev \
libva1 vainfo i965-va-driver libva-glx1 libva-dev
The following command will install the mplayer dependencies:
sudo apt-get build-dep mplayer
Next I downloaded, extracted, and compiled the VAAPI enabled mplayer. I used the ./checkout-
Then I tried running it with the following commands:
cd mplayer-vaapi
./mplayer -vo vaapi -va vaapi /home/user/
Unfortunately this provided only sound on my system:
<... snip>
Playing /home/user/
TS file format detected.
VIDEO MPEG2(pid=33) AUDIO A52(pid=36) NO SUBS (yet)! PROGRAM N. 1
VIDEO: MPEG2 1920x1080 (aspect 3) 29.970 fps 17500.0 kbps (2187.5 kbyte/s)
Load subtitles in /media/
Error opening/
<snip....>
Since the command failed to display any video output, I used the following command to list all of the valid video outputs for mplayer:
./mplayer -vo help
Unfortunately the vaapi option was not listed. ;-(
Then I tried using the gl2 video output with very promising results (no tearing):
./mplayer -vo gl2 -va vaapi /home/user/
I also tried using the gl2 video output with the default installed mplayer that does not have VAAPI support:
/usr/
To my surprise, this video played _without_ video tearing as well. :-)
I will need to experiment with this more to see how I might be able to get this to work with mythtv.
At the moment these results look very promising.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #67 |
In follow-up to comment #32, I meant to mention that I am also running the 2.6.39 kernel from the following site:
PPA for Ubuntu Kernel PPA
https:/
Chris Thompson (chris-thompson) wrote : | #21 |
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.
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #68 |
mr. Gedak: Are you sure that you are using the Intel drivers for your video-output? Because it sounds like you are experiencing a different issue to me and mr. Savin.
For example you are unable to capture the issue on a screenshot, and also it seems that your video playback does not tear when using mplayer's 'gl2' video-output. I experience video tearing regardless of output, e.g. when using mplayer's 'gl2' video-output the video still tears, and this tearing can be captured in a screenshot. Please verify your driver is indeed the intel driver, and that you can (or cannot) take a screenshot of the tearing. For example what is the output of "xvinfo | grep Adaptor"? Also please try to somehow see how many tearing lines there are (this is probably very difficult to impossible to do without a screenshot). As you can see in the screenshots provided by mr. Savin and me we both have multiple tearing lines.
Everyone: please carefully re-read comment #26 (and the addendum in comment #27). I should add to that that not only are these artifacts strange, but if indeed this was (just) an issue with the missing 'wait for scanline'-support that we should in fact not be able to capture the tearing in a screenshot because the tearing would be happing 'at a lower level'.
I've had (brief) contact with one of the developers on IRC ('ickle'), and he confirmed that this is indeed a different issue from the missing 'wait for scanline'-support. Unfortunately he did not know what could be the cause of this type of tearing either.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #69 |
Following is the information requested by Da Fox, plus some more for both of the systems I am using for testing:
System A
--------
Asus P8H67-M Pro/CSM motherboard
Intel i7-2600K processor
Kubuntu 11.04 operating system
$ xvinfo | grep Adaptor
Adaptor #0: "Intel(R) Textured Video"
$ uname -a
Linux octo 2.6.39-0-generic #5~20110427-Ubuntu SMP Wed Apr 27 15:27:41 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg -l | grep -i xserver-
ii xserver-
$ mplayer --version
Unknown option on the command line: --version
Error parsing option on the command line: --version
MPlayer 1.0rc4-4.5.2 (C) 2000-2010 MPlayer Team
$
System B
--------
Asus P8H61-M motherboard
Intel i5-2500K processor
Mythbuntu 11.04 operating system
$ xvinfo | grep Adaptor
Adaptor #0: "Intel(R) Textured Video"
$ uname -a
Linux pvrbox 2.6.39-0-generic #5~20110427-Ubuntu SMP Wed Apr 27 15:27:41 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg -l | grep xserver-
ii xserver-
$ mplayer --version
Unknown option on the command line: --version
Error parsing option on the command line: --version
MPlayer 1.0rc4-4.5.2 (C) 2000-2010 MPlayer Team
$
Test Results
------------
When I play video using the "mplayer -vo gl2" option, no video tearing is seen on either of the above systems.
When I play video using the "mplayer -vo xv" option, I can clearly see video tearing on both of the above systems.
When I capture screen shots using System A, I can never seem to capture the moment that I can see the screen tearing. This system is using the KDE desktop.
System B is running mythbuntu with XFCE4 which currently does not have a screen capture program installed. If you have a screen capture program suggestion for XFCE4 then I am all ears.
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #70 |
(In reply to comment #35)
> When I play video using the "mplayer -vo gl2" option, no video tearing is seen
> on either of the above systems.
>
> When I play video using the "mplayer -vo xv" option, I can clearly see video
> tearing on both of the above systems.
Curious, you are indeed running the intel driver, yet you experience very different behaviour. Does turning compositing on/off make any difference for you?
> System B is running mythbuntu with XFCE4 which currently does not have a screen
> capture program installed. If you have a screen capture program suggestion for
> XFCE4 then I am all ears.
XFCE provides a panel plugin for taking screenshots: http://
In freedesktop.org Bugzilla #37686, Hai-lan (hai-lan) wrote : | #71 |
I can reproduce this bug with following file
http://
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Following are links to two vertical bar flash videos that will help test for
> > > video tearing.
> > >
> > > Tearing test for Flash video player (24p source)
> > > http://
> > >
> > > Tearing test for Flash video player (30p source)
> > > http://
> > >
> > > On both of my Sandybridge GPU's (i5-2500K and i7-2600K) video tearing is
> > > apparent because the vertical bars do not always display as perfectly aligned.
> > >
> > > Gordon Jin,
> > >
> > > Would you be able to retry your testing to see if these videos demonstrate
> > > video tearing on your system?
> >
> > I believe flash tearing has another reasons. I doesn't use xvideo. When I
> > checked my driver changes flash didn't lock while Totem did.
>
> You can download the video files from YouTube using for example `clive` [1] and
> play it using any video player you like.
>
>
> [1] http://
Changed in xserver-xorg-video-intel: | |
importance: | Wishlist → High |
Chris Thompson (chris-thompson) wrote : | #22 |
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.
In freedesktop.org Bugzilla #37686, Usedasbugtracking (usedasbugtracking) wrote : | #72 |
Hi there,
The behaviour I encounter is similar to Curtis Gedak's: tearing in videos using the xv output, tearing in flash videos but everything is fine using the gl2 output with mplayer.
My system relies on an i2500k with an asus P8H67-M Pro (rev B3). I installed a kubuntu 11.04 (64-bit version).
uname -a
2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
I had to disable the desktop effects of KDE otherwise plasma crashes at the end of any video playback in mplayer (at least using the gl output. At that time I didn't try the gl2 output). I tried updating my video stack (2:2.15.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #73 |
Thanks Da Fox for the suggestion of a screen capture program for xfce4. The screen shot was larger than 1 MB so I did not attach it to this bug report. Basically the screen shot demonstrated the problem of video tearing and an extra screen shot probably does not help to solve this problem. The source video I used was 1080i recorded direct from an over-the-air HDTV transmission.
I have noticed that when I use the bleeding edge kernel and intel video driver ppas that the problem still occurs. The only time I do not see video tearing is if I use mplayer with the -vo gl or -vl gl2 options. These options; however, do seem to add juddering or stuttering to the picture and so are not a good solution.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #74 |
Through trial and error I have discovered a work around to get 1080i video to play without tearing using the mythtv player.
In order to play 1080i video content on my system running mythbuntu-11.04, I created a new playback profile modeled after the "High Quality" playback profile. The new profile differs in that it uses xshm for the video renderer (as opposed to xv-blit). Please note that xshm says that it cannot scale video in case this a problem for your setup
The steps to create the new playback profile from the MythTV frontend are as follows:
Select Utilities/Setup -> Setup -> TV Settings -> Playback
Select Next 3 times
On Playback Profiles (3/8) page:
Select "Add New" by Current Video Playback Profile
Enter Playback Group Name: Intel HD Graphics
Select OK
Select "Add New Entry"
Match Criteria: >= W: 320 H: 200
Match Criteria: W: 0 H: 0
Decoder: Standard Max CPUs: 2 Y - Deblocking filter
Video renderer: xshm OSD renderer: softblend Y - OSD fade
Select Next
Primary deinterlacer: linear blend
Fallback deinterlacer: linear blend
Custom filters:
Select Finish
Select Next 5 times
Select Finish
Select Playback (again)
On Playback Profiles (3/8) page: (now shows Intel HD Graphics)
Select "Add New Entry"
Match Criteria: > W: 0 H: 0
Match Criteria: W: 0 H: 0
Decoder: Standard Max CPUs: 1 Y - Deblocking filter
Video renderer: xv-blit OSD renderer: softblend Y - OSD fade
Select Next
Primary deinterlacer: Yadif (2x)
Fallback deinterlacer: Yadif
Custom filters:
Select Finish
Hopefully this work around will help others who use mythtv, while we await a better solution.
Curtis Gedak (gedakc) wrote : | #23 |
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:/
For mythtv see the following link:
https:/
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #75 |
(In reply to comment #40)
> Through trial and error I have discovered a work around to get 1080i video to
> play without tearing using the mythtv player.
>
> In order to play 1080i video content on my system running mythbuntu-11.04, I
> created a new playback profile modeled after the "High Quality" playback
> profile. The new profile differs in that it uses xshm for the video renderer
> (as opposed to xv-blit). Please note that xshm says that it cannot scale video
> in case this a problem for your setup
>
> The steps to create the new playback profile from the MythTV frontend are as
> follows:
>
> Select Utilities/Setup -> Setup -> TV Settings -> Playback
> Select Next 3 times
> On Playback Profiles (3/8) page:
> Select "Add New" by Current Video Playback Profile
> Enter Playback Group Name: Intel HD Graphics
> Select OK
> Select "Add New Entry"
> Match Criteria: >= W: 320 H: 200
> Match Criteria: W: 0 H: 0
> Decoder: Standard Max CPUs: 2 Y - Deblocking filter
> Video renderer: xshm OSD renderer: softblend Y - OSD fade
> Select Next
> Primary deinterlacer: linear blend
> Fallback deinterlacer: linear blend
> Custom filters:
> Select Finish
> Select Next 5 times
> Select Finish
> Select Playback (again)
> On Playback Profiles (3/8) page: (now shows Intel HD Graphics)
> Select "Add New Entry"
> Match Criteria: > W: 0 H: 0
> Match Criteria: W: 0 H: 0
> Decoder: Standard Max CPUs: 1 Y - Deblocking filter
> Video renderer: xv-blit OSD renderer: softblend Y - OSD fade
> Select Next
> Primary deinterlacer: Yadif (2x)
> Fallback deinterlacer: Yadif
> Custom filters:
> Select Finish
>
>
> Hopefully this work around will help others who use mythtv, while we await a
> better solution.
Can you reproduce this using only mplayer? I think that mplayer's "-vo x11" is the same as mythtv's "xshm" driver? But using "-vo x11" I still get tearing (which is what I would expect).
Is the rest of your desktop somehow vsynced? By that I mean that when you for example rapidly move a window left-right-left-etc ('shaking' it), do you see tearing on the window (I do)? Are you using compiz (or related wm)? Or do you have some other form of compositing enabled? (e.g. xfce's windowmanager also supports compositing, to draw a dropshadow beneath windows.)
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #76 |
(In reply to comment #41)
> Can you reproduce this using only mplayer? I think that mplayer's "-vo x11" is
> the same as mythtv's "xshm" driver? But using "-vo x11" I still get tearing
> (which is what I would expect).
Using "mplayer -vo x11" I still see video tearing.
Are you sure that mplayer's "-vo x11" is the same as mythtv's "xshm" driver?
MythTV also provides a xlib driver that I would think is more in line with the mplayer "-vo x11" option.
When I use mythtv's "xlib" driver I still see video tearing.
I do not see video tearing when I use mythtv "xshm" driver.
> Is the rest of your desktop somehow vsynced? By that I mean that when you for
> example rapidly move a window left-right-left-etc ('shaking' it), do you see
> tearing on the window (I do)?
On my production PVR, I am using a up-to-date mythbuntu 11.04 build with the mythtv ppa 0.24.x updates applied. I do not have the desktop "vysnced". When I rapidly move a window left-right-left, I see video tearing.
On my motherboard I set the BIOS to use the maximum amount of dedicated shared memory for the GPU -- 128 MB in my case. As far as I know, any extra memory required is dynamically allocated.
> Are you using compiz (or related wm)? Or do you
> have some other form of compositing enabled? (e.g. xfce's windowmanager also
> supports compositing, to draw a dropshadow beneath windows.)
The compositor is not enabled in XFCE4, at least according to the settings manager.
In freedesktop.org Bugzilla #37686, Usedasbugtracking (usedasbugtracking) wrote : | #77 |
I just forgot to add that I only use my TV as display output using hdmi (didn't try dvi). This problem doesn't seem to gain a lot of attention. Don't people watch videos on linux using the native intel display card?
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #78 |
There IS video tearing on windows 7. Just disable compositing(AERO) and use media player classic for example. You can see tearing on all renders except overlay.
But if you enable aero everything would be fine even with flash. That's so sad.
aefaradien (sen-aefaradien-deactivatedaccount) wrote : | #24 |
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 : | #25 |
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.
In freedesktop.org Bugzilla #37686, Tino-keitel+fdo (tino-keitel+fdo) wrote : | #79 |
I also have tearing video in MythTV using XV output, vlc (XV and vaapi) and mplayer (-vo xv and -vo vaapi). I'm using kernel 3.1-rc4, Xorg 1.11, Mesa 7.11, libdrm 2.4.26 and intel-xorg 2.16. The tearing happends without moving windows or doing anything in the GUI, just during normal playback in a window or fullscreen.
I'm using Debian Sid with gnome-shell from experimental on a Sandy Bridge i5-2400.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #80 |
Has anyone from the Intel team been able to confirm this problem?
If not, what GNU/Linux distribution, desktop and settings are you using?
VIDEO TEARING / SHEARING TEST
-------
The test clip "teartest.mp4" from the following Ubuntu bug report clearly demonstrates the video tearing / shearing problem on all of my desktop computers.
https:/
KDE APPLICATION WINDOW WORKAROUND TO PROBLEM (NOT FULL SCREEN)
-------
On my kubuntu 11.04 system with the KDE desktop I seem to be able to avoid the tearing problem in an application window (not full screen) if I do the following:
Enable desktop effects and vertical synchronization steps:
Start K --> Settings --> System Settings
Under "Workspace Appearance and Behaviour" section:
Click on "Desktop Effects" to open this setting
Choose the "General" tab
Enable "Enable desktop effects"
Choose the "Advanced" tab
Enable "Use VSync"
Click on "Apply"
I also tried disabling "Suspend desktop effects for fullscreen
windows". This did seem to reduce the video tearing problem but did
not eliminate it.
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #81 |
Eureka! I just discovered an even better workaround to the screen tearing problem. This solution also reduces the small amount of juddering that was present in the Mythbuntu MythTV workaround identified in comment #40.
MYTHBUNTU 11.04 MYTHTV VIDEO TEARING WORKAROUND
-------
From the XFCE4 desktop use the following steps to turn on the compositor:
Start Applications -> Settings -> Window Manager Tweaks
Click on the "Compositor" tab
Enable checkbox "Enable display compositing"
Close this window
From the MythTV frontend, select the High Quality playback profile:
Start Applications -> Multimedia -> MythTV Frontend
Select Utilities/Setup -> Setup -> TV Settings -> Playback
Select Next 3 times
On Playback Profiles (3/8) page:
Set "Content Video Playback Profile": " High Quality"
Select Next a few times and then Finish
From my testing, the above solution significantly reduces if not eliminates all video tearing or juddering with full screen video. :-)
Curtis Gedak (gedakc) wrote : | #26 |
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:/
For reduced video tearing for the Kubuntu 11.04 KDE desktop see the following link:
https:/
For a sample .mp4 file to test the video tearing problem see the following link:
https:/
PhilippeDePass (depassp) wrote : | #27 |
This bug is also affecting me. I'm quite disappointed that I decided to "upgrade" to 11.04.
In freedesktop.org Bugzilla #37686, SIO (sio-wtf) wrote : | #82 |
Came to say that I've found a workaround/fix for this bug on my system: I've upgraded xserver-
Looks like this also fixed tearing in opengl games.
I use Debian GNU/Linux on Intel Core i3-2310M. Driver package I used was the one from official Debian unstable repos. Thank you all for comprehensive discussion on this bug, it saved me a lot of time googling :)
In freedesktop.org Bugzilla #37686, Curtis Gedak (gedakc) wrote : | #83 |
(In reply to comment #48)
> ... and switched video output to gl.
Vitaly, did you switch the video output for the whole desktop?
If so which desktop are you using (KDE, GNOME, LXDE, XFCE4, other)?
What were the steps you used to switch the video output to gl?
In freedesktop.org Bugzilla #37686, SIO (sio-wtf) wrote : | #84 |
(In reply to comment #49)
Of course I switched video output only for the video player. In my case it is smplayer - video output options are in "Preferences > General > Video" menu. You can try `mplayer -vo gl` as well. But there was never any tearing in interface at my system.
The step that helped me was not only switching vo, but also (and mostly) upgrading the video driver. As I see it, the problem is halfway fixed in newer drivers, that's why opengl rendering causes no tearing.
Daniel van Vugt (vanvugt) wrote : | #28 |
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-
Benjamin Drung (bdrung) wrote : | #29 |
I can confirm, that these settings fix the tearing issue on my sandybridge system on Ubuntu 11.10 (oneiric).
description: | updated |
In freedesktop.org Bugzilla #37686, Sergeyn (sergeyn) wrote : | #85 |
I have extra/xf86-
I'm using gnome 3.2 if it is necessary.
Daniel van Vugt (vanvugt) wrote : | #30 |
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 : | #31 |
Fix from post #28 does not work for me. Am using Ubuntu 11.10 with i3 sandy bridge and gnome-shell dm.
In freedesktop.org Bugzilla #37686, Eugeni Dodonov (eugeni) wrote : | #86 |
Hi folks,
due to changes in Sandy Bridge hardware in the way that registers work, to properly fix this issue it would be necessary to make changes in:
- kernel
- libdrm
- xf86-video-intel
so it is not an easy fix.
I have some work-in-progress for this, but no ETA so far. In any case, I'll let you know when I'll have some changes or fixes.
Meanwhile, what seems to somewhat mitigate the issues is the usage of '-vo gl' or '-vo vaapi', or '-vo gl2' in some cases. The tearing seems to be improved on some systems with such options. It also gets improved in full-screen mode with such modes most of the times. But it is really system-depending and timing-related, it gets better on some systems, and without much changes on other.
The proper fix for this would require changes to the aforementioned packages.
(For more technical description of the problem: the way of passing messages between rings has changed for security reasons, so we need to use additional registers to control when batch buffers can be signaled between rings).
era (erik-thysell) wrote : | #32 |
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)
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #87 |
Almost half a year has passed since I firstly reported the bug. It is pleasant to see that there's an explanation of the problem.
I tried to solve the issue but due to lack of knowledge and time I wasn't succeed. Thank you very much Eugeni for you efforts.
In freedesktop.org Bugzilla #37686, Eugeni Dodonov (eugeni) wrote : | #88 |
> It is pleasant to see that there's an explanation of the problem.
Well, technically, my answer is the same one as Chris's on comment #3, I just put it in a more verbose form :).
But yes, it is not something trivial to fix...
Daniel van Vugt (vanvugt) wrote : | #33 |
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 |
In freedesktop.org Bugzilla #37686, Eugeni Dodonov (eugeni) wrote : | #89 |
So, just as an update here while still working on a fix.
You should not experience tearing if you disable compositing and use gl or vaapi output. Tearing still happens with xv/x11 due to vsync not working properly on Sandy Bridge yet, even with compositing disabled.
With compositing enabled, I guess there is not much to do - the problem happens due to the nature of compositing itself. When it is used, the windows do not render directly to screen, but to an off-screen area. So the vsync is not helpful in any case - the off-screen does not synchronizes itself with it. Such tearing is not Intel-specific, it also happens on nvidia (http://
As for the vsync fix for making it work with xv/x11, I still don't have a working fix for it. I'll keep this bug updated when I'll have one.
Thanks!
Eugeni
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #90 |
Thanks for the update, Eugeni
I would like to mention that there's no OpenGL tearing (VSYNC works well) with NVIDIA. Moreover, some tearing problems with NVIDIA board while watching movies could be solved by disabling 'Redirect fullscreen windows' in compiz-settings which is equivalent to watching fullscreen movies with compositing disabled. This trick doesn't work on SandyBridge because video texture output doesn't sync to VBLANK.
In freedesktop.org Bugzilla #37686, Tomas Janousek (lis) wrote : | #91 |
Well, I do experience tearing even with disabled compositing and GL output. Sure, it's much better than all the other options, and tearing happens exclusively in the top 50 pixels of the screen, but it does happen. It's clearly visible using the videos from youtube (downloaded using youtube-dl and played with mplayer -vo gl).
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #92 |
(In reply to comment #55)
> With compositing enabled, I guess there is not much to do - the problem happens
> due to the nature of compositing itself. When it is used, the windows do not
> render directly to screen, but to an off-screen area. So the vsync is not
> helpful in any case - the off-screen does not synchronizes itself with it. Such
> tearing is not Intel-specific, it also happens on nvidia
> (http://
> http://
> description at https:/
In such cirumstances,the compositor uses CopySubBuffer which is meant to be vsync'ed.The caveat is that it is implemented inside an Xserver using a function that is not specified to be either synchronous or asynchronous (DRI2CopyRegion), and that same function is also used in a performance sensitive path (vblank_mode=0!). For UXA, we actually do enable vsync so that the compositor does not tear. I proposed http://
In freedesktop.org Bugzilla #37686, Petko Bordjukov (ignis) wrote : | #98 |
Hello all,
I am using Gnome 3 for my desktop environment.
I managed to work around this tearing issue by adding the following line to my /etc/environment file:
CLUTTER_
I am not sure how much does this affect the overall performance, but now there is no visible tearing in gnome-shell.
Somewhat similar workaround has been devised for Compiz as may be seen over at Ubuntu's Launchpad issue tracker. The tearing disappears when the 'Force full screen redraws on repaint' option in the Workaround plug-in is enabled.
More info for my laptop is available at the RH bugzilla:
https:/
In freedesktop.org Bugzilla #37686, Dmitry Savin (envelsavinds) wrote : | #99 |
Thank you very much, Mr. Bordjukov. The workaround solves tearing issue in compiz without any noticible performance degradation.
In freedesktop.org Bugzilla #37686, Petko Bordjukov (ignis) wrote : | #100 |
Hello Dmitry,
Please note that different permutations of the 'Sync to VBlank' option in the OpenGL plugin and the 'Don't wait for video sync' in the Workarounds plugin may affect positively or negatively the performance (I experienced stuttering in some configurations not sure which).
There are no such issues with Gnome 3 even when playing 1080p video.
Daniel van Vugt (vanvugt) wrote : | #93 |
OK, it turns out the desktop tearing fix in bug 880707 is not enough to also fix this bug. This one seems to mostly be about tearing when playing video (usually HD) if I'm not mistaken.
summary: |
- [sandybridge] video tearing + [sandybridge] Graphics tearing when playing video |
description: | updated |
Daniel van Vugt (vanvugt) wrote : | #94 |
Looks like I've got a compiz fix for this bug after all. It seems to eliminate all tearing when playing HD video on sandybridge under compiz/unity at least. Still testing the fix, but it looks good so far.
Stay tuned for more news soon.
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 |
Daniel van Vugt (vanvugt) wrote : | #95 |
OK, the fix is available for testing in ppa:vanvugt/compiz. But I highly recommend you also use ppa:vanvugt/unity because it contains a critical related performance fix.
In my testing (with both PPAs) this resolves all tearing in 24-30 FPS video, and almost all tearing in 60 FPS video. It's really getting close to the limit of how many pixels compiz can push around :)
ppa:vanvugt/compiz | https:/
compiz (1:0.9.
* Significantly reduced tearing even more. This now resolves the tearing seen
during HD video playback (LP: #755841)
This also dramatically improves GL benchmark results for those who like to
measure framerates with sync-to-vblank disabled.
-- Daniel van Vugt <email address hidden> Wed, 07 Dec 2011 17:54:09 +0800
ppa:vanvugt/unity | https:/
unity (4.24.0-
* Fix major performance regressions due to unnecessary UnityFBO binding
(LP: #861061) (LP: #880707)
UnityFBO was being bound even when not required. This caused major lag in
glPaintOutput, which slowed down all rendering. This was seen in reduced
framerates in apps (LP: #861061) and significantly worse screen tearing
with Unity 4.x compared to 3.x (LP: #880707).
-- Daniel van Vugt <email address hidden> Sat, 03 Dec 2011 14:34:01 +0800
tags: | added: performance |
Mark Howell (markjhowell) wrote : | #96 |
Thanks Daniel, your compiz and unity updates in your PPA have much improved the tearing on playback on a system I have here. This system displays from integrated video on its i7-2630QM (sandy bridge) CPU. Previously I've seen really bad tearing while playing back h264/mp4 at 30 fps with vlc and mplayer (in various modes) within the Unity desktop.
Now if only I could get directfb to stop tearing on this system ;-)
Daniel van Vugt (vanvugt) wrote : | #97 |
If you would like to eliminate absolutely all tearing then the solution is in CCSM:
Workarounds > "Force full screen redraw (buffer swap) on repaint" = ON
And with Intel Sandy Bridge graphics I seem to get the best performance by combining that setting with:
OpenGL > "Sync To VBlank" = OFF
(this doesn't work with other drivers like NVIDIA)
Keep using ppa:vanvugt/compiz for the best performance too.
In my experience this config looks the nicest. But it's not enabled by default because it uses more CPU to redraw the whole screen every frame.
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #102 |
(In reply to comment #58)
> (In reply to comment #55)
> > With compositing enabled, I guess there is not much to do - the problem happens
> > due to the nature of compositing itself. When it is used, the windows do not
> > render directly to screen, but to an off-screen area. So the vsync is not
> > helpful in any case - the off-screen does not synchronizes itself with it. Such
> > tearing is not Intel-specific, it also happens on nvidia
> > (http://
> > http://
> > description at https:/
>
> In such cirumstances,the compositor uses CopySubBuffer which is meant to be
> vsync'ed.The caveat is that it is implemented inside an Xserver using a
> function that is not specified to be either synchronous or asynchronous
> (DRI2CopyRegion), and that same function is also used in a performance
> sensitive path (vblank_mode=0!). For UXA, we actually do enable vsync so that
> the compositor does not tear. I proposed
> http://
> to disambiguate that case and to permit even faster vblank_mode=0 swapping.
I heard about that for full-screen opengl something called 'page flipping' is used, which is able to provide vsync on sandybridge (this is the work around with "mplayer -vo gl" discussed above).
Q:
Is there a way to modify the xrender compositor(s) so that it ensures that
1) rendering to the offscreen area is complete before calling CopySubBuffer (or equivalent), e.g. by using double buffering,
2) calling some equivalent of CopySubBuffer which can do page flipping for 2d xrender calls. I.e. the goal is to get the 2d xrender case to also use page flipping.
I don't know to what extend this is the same as the idea that was proposed a few months back (which I also tried to discuss with the xfce developers, see http://
Hendy Irawan (ceefour) wrote : | #101 |
"You should not experience tearing if you disable compositing and use gl or vaapi output. Tearing still happens with xv/x11 due to vsync not working properly on Sandy Bridge yet, even with compositing disabled."
- https:/
I confirm that this workaround works on my system with Intel/ATI Hybrid graphics, using Intel graphics as active. I'm in KDE, before playing video I will switch off KDE compositing (Alt+Shift+F2) then play video using mplayer with gl output. No tearing at all! :-) Finally, I can watch movies in great shape on my 32" HDMI TV ^_^
Using VLC still tears, because when with VLC-GLX the video is corrupted, and with XV there's still video tearing even with compositing disabled.
Changed in compiz-core: | |
status: | In Progress → Fix Committed |
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #104 |
Please take a look at this bug https:/
Launchpad Janitor (janitor) wrote : | #103 |
This bug was fixed in the package compiz - 1:0.9.7.
---------------
compiz (1:0.9.
[ Didier Roche ]
* New upstream snapshot:
- Fix slow/stuttering display with fglrx (LP: #763005)
- Don't dynamically link to compiz_core
- Fix build failures with glib 2.30 (oneiric) (LP: #921406)
- Fix uninitialized variable warnings in valgrind (LP: #921451)
- Fixes up a bunch of boost::variant edge cases
- Fixes a race condition where the xig restart test would fail spuriously
- Incorrect (low/stuttering) refresh rate with NVIDIA driver (LP: #92599)
- Benchmark window slows the system and degrades graphics resources
(LP: #254561)
- Windows that hide themselves when closed don't appear in any
"this workspace" switcher (LP: #684731)
- hang in g_spawn_sync and select() (LP: #690239)
- word misspelled - bunding (LP: #694169)
- sometimes, restored window placed too high. (LP: #716521)
- Compiz clears the root window in the installer session (LP: #720679)
- unity-window-
not speak the title of the focused window. (LP: #724093)
- Cannot open a window that starts iconified (LP: #732997)
- Minimize animation flickr when for maximized apps (LP: #737125)
- Pixmap memory leak in gtk-window-
- Windows should not automatically be focused when opened if the
focus is on another application (LP: #748840)
- [sandybridge] Graphics tearing when playing video (LP: #755841)
- Compiz's "Sync to Vblank" makes display stutter/slow with fglrx
(LP: #763005)
- [regression] Moving windows lags behind the mouse by 1-2 seconds;
appear to freeze when dragging. (LP: #764330)
- Launcher - Spread should not affect the state of window (LP: #764673)
- Clicking on a tweet/message link sometimes does not work (LP: #790565)
- scrolling on top of a close animation switches viewports (LP: #795065)
- unity video tearing when moving windows in oneiric with
nvidia-
- dialogs really slow to be displayed since the compiz update (LP: #812711)
- It is possible to stack windows relative to windows that are
destroyed (LP: #837252
- Should keep list of windows last sent to server and last recv
from server (LP: #841727)
- compiz and X can disagree on the stacking order (LP: #845719)
- A minimized window 'remains' behind on the desktop if
/
show_
- maximized windows fail to update their input extents when
undecorated (LP: #853734)
- resizing bugs with xterm (LP: #854725)
- crash on closing a window (LP: #856015)
- Java application windows cut-off/
(LP: #857201)
- compiz crashed with SIGSEGV in CompScreen:
(LP: #857487)
- compiz crashed with SIGABRT in raise() (LP: #857738)
- Applications which create multiple windows that are transients of
each other...
Changed in compiz (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in compiz-core: | |
status: | Fix Committed → Fix Released |
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #105 |
*** Bug 43674 has been marked as a duplicate of this bug. ***
JC Hulce (soaringsky) wrote : | #106 |
This bug was fixed in one of the other packages attached to this bug, closing
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Confirmed → Fix Released |
Chun-Yu (cshei) wrote : | #107 |
I just tried Ubuntu 12.04 and this is definitely not fixed in the default Unity interface… there is still a lot of tearing when playing https:/
Daniel van Vugt (vanvugt) wrote : | #108 |
Chun-Yu, if you still have such problems in 12.04 then please log a new bug because this one won't get much attention since it's now Fix Released.
I assume you're using the intel graphics output on your i5? Please also try the workaround listed in the Bug Description at the top of this bug. And report your findings in a new bug.
Thanks...
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #109 |
Meanwhile, it's been a year and change without a solution.
#52 mentions this being caused by new security rules. Considering that, by and large, there won't be multiple users concurrently using the GPU *anyway* - is there any possibility of backing out that change instead, even just locally?
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #110 |
(In reply to comment #65)
> Meanwhile, it's been a year and change without a solution.
>
> #52 mentions this being caused by new security rules. Considering that, by and
> large, there won't be multiple users concurrently using the GPU *anyway* - is
> there any possibility of backing out that change instead, even just locally?
aahhh, I forgot to buy a present :( Happy (belated) bug-birthday still!
Seriously though, I think the change though in comment #52 is a change to the *hardware*, so unless you have some mad soldering skills there is no way 'back out that change', even just locally.
Some more frequent status updates would certainly be nice though, and at least serve to let people know that work on fixing this glaring omission is still ongoing (this was also promised in comment #52).
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #111 |
You never know, I might decide to break out my soldering iron. See, I look at it this way: Best case, a random god intervenes and it gets fixed; worst case, I get to tell the insurance company that a madman with a soldering iron assaulted my laptop and I get a new, working one.
Seriously, though. *Is* work ongoing? Is there anything I can do to help?
I obviously don't know the API details here, so I doubt I can be much help on the programming side of things. I'm willing to test patches, of course, and in general I'd like to make myself useful.
But if I knew this was going to take a year, I'd have sent the laptop back and found a working replacement. That's no longer feasible. I'd like to know if I'm going to wait *another* year, because finding a new one probably is.
In freedesktop.org Bugzilla #37686, Petko Bordjukov (ignis) wrote : | #112 |
Hello,
I was unable to reproduce the bug on Fedora 17 with Gnome Shell.
On Wed, May 16, 2012 at 12:42 PM, <email address hidden> wrote:
>
> https:/
>
> --- Comment #67 from Svein Ove Aas <email address hidden> 2012-05-16 02:42:42
> PDT ---
> You never know, I might decide to break out my soldering iron. See, I look
> at
> it this way: Best case, a random god intervenes and it gets fixed; worst
> case,
> I get to tell the insurance company that a madman with a soldering iron
> assaulted my laptop and I get a new, working one.
>
> Seriously, though. *Is* work ongoing? Is there anything I can do to help?
>
> I obviously don't know the API details here, so I doubt I can be much help
> on
> the programming side of things. I'm willing to test patches, of course,
> and in
> general I'd like to make myself useful.
>
> But if I knew this was going to take a year, I'd have sent the laptop back
> and
> found a working replacement. That's no longer feasible. I'd like to know
> if I'm
> going to wait *another* year, because finding a new one probably is.
>
> --
> Configure bugmail: https:/
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #113 |
(In reply to comment #68)
> Hello,
>
> I was unable to reproduce the bug on Fedora 17 with Gnome Shell.
Take a look
https:/
In freedesktop.org Bugzilla #37686, Eric Appleman (erappleman) wrote : | #114 |
Even with SNA enabled, the only solution that has worked for me is the workaround bord offered:
CLUTTER_
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #115 |
(In reply to comment #70)
> Even with SNA enabled, the only solution that has worked for me is the
> workaround bord offered:
>
> CLUTTER_
Unfortunately that's an option to gnome-shell (it is, isn't it?), which means it's less than useful to those of us running other window managers.
XMonad, in my case. It doesn't do any compositing whatsoever, and the compose extension is off, so it's not that.
In freedesktop.org Bugzilla #37686, Eugeni Dodonov (eugeni) wrote : | #116 |
Just as an update from the past post.
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.
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.
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #117 |
(In reply to comment #72)
> Just as an update from the past post.
>
> 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.
>
> 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.
Please, see (In reply to comment #72)
> Just as an update from the past post.
>
> 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.
>
> 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.
> This way, I see no tearing.
Please, take a look at Comment 6 in this bug
https:/
I have tearing on tearing test 720x406 video file both via vaapi and gl without compositing.
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #118 |
(In reply to comment #72)
> Just as an update from the past post.
>
> 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.
>
> 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 have no tearing on GL in fullscreen.
I do, however, have tearing for very simple GL code in windowed mode (fill window black, flip, fill screen white, flip - tearing is painfully obvious), mplayer -vo gl in both windowed and fullscreen mode (since its "fullscreen" is actually a screen-covering window and doesn't trigger the same mechanism), and mplayer -vo xv in all modes.
This is with all compositing turned off *and* using a window manager that doesn't support in anyway, by the way.
vaapi might possibly work, but mplayer doesn't support it. (I know about the mplayer-vaapi patch; it hasn't worked with modern mplayer(2) code for some time, sorry.)
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #119 |
(In reply to comment #74)
> I have no tearing on GL in fullscreen.
Please test it with tearing test 720x406 from https:/
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #120 |
(In reply to comment #75)
> (In reply to comment #74)
> > I have no tearing on GL in fullscreen.
> Please test it with tearing test 720x406 from
> https:/
I can't do that.
Those are movies, and the test program I'm using that doesn't tear doesn't play any movies, it just does raw GL output. mplayer *does* tear in fullscreen, but that's because it doesn't actually set the fullscreen bit.
Here's the full code, so you can try it yourself:
#include <GL/gl.h>
#include <SDL/SDL.h>
#include <strings.h>
#include <stdio.h>
int main(int argc, char **argv) {
Uint32 i, mode;
if (argc != 2)
goto usage;
if (strcmp(argv[1], "w") == 0)
mode = SDL_OPENGL;
else if (strcmp(argv[1], "f") == 0)
mode = SDL_OPENGL | SDL_FULLSCREEN;
else
goto usage;
SDL_Init(
SDL_GL_
SDL_SetVideoM
for (i = 0; i < 100; i++) {
glClearColor(1, 1, 1, 1);
glClear(
SDL_
glClearColor(0, 0, 0, 1);
glClear(
SDL_
}
return EXIT_SUCCESS;
usage:
printf("Usage: %s [w|f]\n", argv[0]);
return EXIT_FAILURE;
}
// Compile with gcc test-gl.c -o test-gl -lSDL -lGL
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #121 |
(In reply to comment #76)
> Those are movies, and the test program I'm using that doesn't tear doesn't play
> any movies, it just does raw GL output. mplayer *does* tear in fullscreen, but
> that's because it doesn't actually set the fullscreen bit.
I have no tearing in mplayer in fullscreen if the resolution is 16:9, but when it's anamorphic or just not exactly 16:9 (1,(7)), there is tearing in mplayer. So I have no tearing when playing 1280x720 or 1920x1080 video files, but have tearing with 720x406
I've just compiled your code, changed SDL_SetVideoMod
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #122 |
As I expected, then.
I picked 800x600 because every laptop should be able to set that mode, but by all means switch it around. :-)
In the meantime, maybe we should switch to using my program for testing? mplayer is a huge codebase, and it's hard to tell whether any tearing is the fault of the player or the environment, while it's perfectly obvious what the program is doing.
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #123 |
(In reply to comment #78)
> As I expected, then.
>
> I picked 800x600 because every laptop should be able to set that mode, but by
> all means switch it around. :-)
There is tearing in fullscreen with 800x600. That's definitely 16:9 problem for me.
> In the meantime, maybe we should switch to using my program for testing?
> mplayer is a huge codebase, and it's hard to tell whether any tearing is the
> fault of the player or the environment, while it's perfectly obvious what the
> program is doing.
Yes, that would be great. May I ask you to write some code to render something not 16:9 and to stretch it to 16:9 in hardware, so act as you're watching non-16:9 video in mplayer.
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #124 |
(In reply to comment #79)
> (In reply to comment #78)
> > As I expected, then.
> >
> > I picked 800x600 because every laptop should be able to set that mode, but by
> > all means switch it around. :-)
>
> There is tearing in fullscreen with 800x600. That's definitely 16:9 problem for
> me.
>
Interesting.
In retrospect, when I last tried it in fullscreen on my laptop, I had manually set it to 1920x1200; I (re)wrote the program against an nvidia card, just now. (Which means no tearing anywhere. Love those nvidia cards.)
> > In the meantime, maybe we should switch to using my program for testing?
> > mplayer is a huge codebase, and it's hard to tell whether any tearing is the
> > fault of the player or the environment, while it's perfectly obvious what the
> > program is doing.
>
> Yes, that would be great. May I ask you to write some code to render something
> not 16:9 and to stretch it to 16:9 in hardware, so act as you're watching
> non-16:9 video in mplayer.
The way opengl works, that isn't actually a coherent request. It uses a (0,0)-(1,1) geometry no matter what the resolution or aspect rate of the window is, and it's up to the application to map something sensible to that.
Admittedly modern opengl has some texture-
I suspect your tearing isn't caused by having a not 16:9 aspect ratio so much as not using your laptop screen's native resolution, but could you check that? Try setting some other 16:9 resolutions with SetVideoMode?
What I *can* do is get it to check the maximum screen resolution and always use that for fullscreen mode.
In freedesktop.org Bugzilla #37686, Baughn (sveina) wrote : | #125 |
Updated tester:
#include <GL/gl.h>
#include <SDL/SDL.h>
#include <strings.h>
#include <stdio.h>
int main(int argc, char **argv) {
Uint32 i, mode, w, h;
if (argc != 2)
goto usage;
SDL_Init(
if (strcmp(argv[1], "w") == 0) {
mode = SDL_OPENGL;
w = 800;
h = 600;
} else if (strcmp(argv[1], "f") == 0) {
mode = SDL_OPENGL | SDL_FULLSCREEN;
const SDL_VideoInfo *info = SDL_GetVideoInfo();
w = info->current_w;
h = info->current_h;
printf("Setting %dx%d fullscreen mode\n", w, h);
} else {
goto usage;
}
SDL_GL_
SDL_SetVideoM
for (i = 0; i < 100; i++) {
glClearColor(1, 1, 1, 1);
glClear(
SDL_
glClearColor(0, 0, 0, 1);
glClear(
SDL_
}
return EXIT_SUCCESS;
usage:
printf("Usage: %s [w|f]\n", argv[0]);
return EXIT_FAILURE;
}
// Compile with gcc test-gl.c -o test-gl -lSDL -lGL
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #126 |
(In reply to comment #81)
With this new version I have no tearing on 1366x768, 1024x768, 800x600 fullscreen. But, of course, still have in windowed mode. I have rc6 enabled, and there is tearing on top of the screen. With rc6=0 I have only one top pixel line tearing.
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #127 |
(In reply to comment #72)
> 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.
This is only a very partial work-around though, only applicable to video, and only if played through a player supporting vaapi or gl output.
- How do I tell my flash game to render with vaapi?
- How do I tell firefox's html-5 video renderer to use gl?
- How do I tell my window manager to render with either gl or vaapi (yet keeping compositing disabled)? (i.e. I'd like tear-free windows movements, too)
There are more use-cases for basic v-sync support other than just being able to watch a simple video!
In other news, I just noticed something: for some reason my video's were tearing even when using the vaapi and gl outputs just now. This was with kernel-
Toggling the resolution with xrandr fixed it. I don't know how or why it stopped working, but now if/when this happens you should at least be able to fix it without a reboot.
In freedesktop.org Bugzilla #37686, valdikss (valdikss1) wrote : | #128 |
(In reply to comment #83)
> In other news, I just noticed something: for some reason my video's were
> tearing even when using the vaapi and gl outputs just now. This was with
> kernel-
> Toggling the resolution with xrandr fixed it. I don't know how or why it
> stopped working, but now if/when this happens you should at least be able to
> fix it without a reboot.
I believe I saw this too.
For example, code from Comment 76 gives me tearing and code from Comment 81 does not, because the first one sets resolution on by itself and in second one I set it myself using xrandr, and the code is basically the same.
In freedesktop.org Bugzilla #37686, Ryan Oram (fernandotcl) wrote : | #129 |
(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).
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?
For the record, I'm not running a composite manager.
Thanks for looking into this Eugeni.
In freedesktop.org Bugzilla #37686, Eric Appleman (erappleman) wrote : | #130 |
Using the GL tester, I get tearing in windowed mode when I have my TV hooked up.
In freedesktop.org Bugzilla #37686, Da-fox (da-fox) wrote : | #131 |
(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:/
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
>
> For the record, I'm not running a composite manager.
>
> Thanks for looking into this Eugeni.
In freedesktop.org Bugzilla #37686, Ryan Oram (fernandotcl) wrote : | #132 |
(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:/
> 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
> 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.
In freedesktop.org Bugzilla #37686, taolab (marco-demichele-taolab) wrote : | #133 |
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 freedesktop.org Bugzilla #37686, taolab (marco-demichele-taolab) wrote : | #134 |
(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: 2941a5fe1562673
In freedesktop.org Bugzilla #37686, Joelthelion (joelthelion) wrote : | #135 |
Just wanted to report that I seem to have less problems when using the SNA driver.
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #136 |
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.
In freedesktop.org Bugzilla #37686, Zdzichu (zdzichu) wrote : | #137 |
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.
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #138 |
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/
In the meantime, the only answer is take a leaf out of the other OSes playbook and only use pageflipping.
In freedesktop.org Bugzilla #37686, antistress (antistress) wrote : | #139 |
(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/
> 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
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #140 |
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 freedesktop.org Bugzilla #37686, Michael+freedesktop (michael+freedesktop) wrote : | #141 |
(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 8066bc33d78e78c
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 freedesktop.org Bugzilla #37686, Ryan Oram (fernandotcl) wrote : | #142 |
(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
> 8066bc33d78e78c
> 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 |
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #143 |
*** Bug 52470 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #37686, Oleksij Rempel (olerem) wrote : | #144 |
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?
In freedesktop.org Bugzilla #37686, Oleksij Rempel (olerem) wrote : | #145 |
I checked the screenshots and in may case it is not tearing.
In freedesktop.org Bugzilla #37686, taolab (marco-demichele-taolab) wrote : | #146 |
(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
146959dd5ef2838
In freedesktop.org Bugzilla #37686, Jony akross (akrossnostromo) wrote : | #147 |
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.
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #148 |
Forwarding a message from Axel Rohde
Hi Chris,
I just tested the standalone OpenGL compositor fbcompose
from this site
https:/
fluxbox-
... on a i5-3550, Debian wheezy, xf86-video-
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/
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://
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:/
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.
In freedesktop.org Bugzilla #37686, taolab (marco-demichele-taolab) wrote : | #149 |
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 freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #150 |
(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.
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #151 |
Note in addition to using pageflipping via the TearFree option, there is a glimmer of light in the form of
kernel commit d7d4eeddb8f7234
Author: Chris Wilson <email address hidden>
Date: Wed Oct 17 12:09:54 2012 +0100
drm/i915: Allow DRM_ROOT_
and
xf86-video-intel commit 891bae4aa91e855
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...)
In freedesktop.org Bugzilla #37686, Mariocortis (mariocortis) wrote : | #152 |
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 freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #153 |
(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.
In freedesktop.org Bugzilla #37686, Usedasbugtracking (usedasbugtracking) wrote : | #154 |
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?
In freedesktop.org Bugzilla #37686, postadelmaga (postadelmaga) wrote : | #156 |
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
In freedesktop.org Bugzilla #37686, postadelmaga (postadelmaga) wrote : | #157 |
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 freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #158 |
(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.
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #159 |
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 freedesktop.org Bugzilla #37686, Michael+freedesktop (michael+freedesktop) wrote : | #160 |
(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.
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #161 |
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.
In freedesktop.org Bugzilla #37686, Mariocortis (mariocortis) wrote : | #162 |
Works great now, no more tearing. Thank you!
In freedesktop.org Bugzilla #37686, bwat47 (bwat47) wrote : | #163 |
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:/
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)
In freedesktop.org Bugzilla #37686, bwat47 (bwat47) wrote : | #164 |
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:/
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 :)
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #165 |
*** Bug 67823 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #166 |
TearFree should be much improved as of:
commit fa2687bdd5a4c8b
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>
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #167 |
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 |
In freedesktop.org Bugzilla #37686, Maxtin (maxtin) wrote : | #168 |
Will it be made default? Tx
In freedesktop.org Bugzilla #37686, Chris Wilson (ickle) wrote : | #169 |
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.
In freedesktop.org Bugzilla #37686, N. W. (nw9165-3201) wrote : | #170 |
The Arch Linux Wiki says that TearFree is no longer needed when using DRI3:
https:/
Is that correct?
Does enabling TearFree actually do anything when using DRI3? Or is TearFree=True being ignored when using DRI3?
Changed in xserver-xorg-video-intel (Fedora): | |
importance: | Unknown → Undecided |
status: | Unknown → Won't Fix |
I get multiple of these in my Xorg.log:
(WW) intel(0): first get vblank counter failed: Invalid argument