ubuntu-x-swat team mailing list archive
-
ubuntu-x-swat team
-
Mailing list archive
-
Message #148291
[Bug 755841] Re: [sandybridge] video tearing
Launchpad has imported 55 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=37686.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2011-05-28T08:58:50+00:00 Dmitry Savin wrote:
Any video tears with sandybridge graphics (i5-2500 integrated) with intel driver version 2.14.0. Updating to version 2.15.0 doesn't solve the problem.
Distro LinuxMint 11 (the same was in Ubuntu 11.04 with all updates). OpenGL apps tear as well.
uname -a:
Linux envel 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
xvinfo:
X-Video Extension version 2.2
screen #0
Adaptor #0: "Intel(R) Textured Video"
number of ports: 16
port base: 83
operations supported: PutImage
supported visuals:
depth 24, visualID 0x21
number of attributes: 3
"XV_BRIGHTNESS" (range -128 to 127)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range 0 to 255)
client settable attribute
client gettable attribute (current value is 0)
"XV_SYNC_TO_VBLANK" (range -1 to 1)
client settable attribute
client gettable attribute (current value is 1)
maximum XvImage size: 2048 x 2048
Number of image formats: 5
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x434d5658 (XVMC)
guid: 58564d43-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/15
------------------------------------------------------------------------
On 2011-05-28T09:00:29+00:00 Dmitry Savin wrote:
Created attachment 47245
Xorg log
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/16
------------------------------------------------------------------------
On 2011-05-28T09:02:14+00:00 Chris Wilson wrote:
The ability to wait upon scanlines was apparently defeatured, or at
least disappeared from the specs...
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/17
------------------------------------------------------------------------
On 2011-05-28T09:03:52+00:00 Dmitry Savin wrote:
Created attachment 47246
Tearing screenshot
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/18
------------------------------------------------------------------------
On 2011-05-28T09:08:38+00:00 Dmitry Savin wrote:
(In reply to comment #2)
> The ability to wait upon scanlines was apparently defeatured, or at least
> disappeared from the specs...
Where can I find specs and how it is implemented for other intel
graphics chips? (I have x86-video-intel-2.15.0 source code in front of
me). I think it is important issue for desktop computers with Intel
graphics.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/19
------------------------------------------------------------------------
On 2011-05-28T10:56:24+00:00 Dmitry Savin wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/20
------------------------------------------------------------------------
On 2011-05-29T08:05:48+00:00 Dmitry Savin wrote:
Finally I found the ability to enable wait_for_scan_line support on SandyBridge.
According to specs, we should use DE_LOAD_SL ("This register is used to initiate a display scan line compare on DevSNB:D2 and later steppings"). To load a value to this register it is needed to use MI_LOAD_REGISTER_IMM. So the algorithm should be the following:
1. Calculate start/end scan lines
2. Call MI_LOAD_REGISTER_IMM with DE_LOAD_SL address and parameter equals to (0x11x<<29 | (start_sl<<16) | end_sl), where x represents pipe (0 for A, 1 for B).
3. Call MI_WAIT_FOR_EVENT with corresponding bits set to true (wait for pipe A/B scan line). Notice, that these bits are changed since last docs version.
The above should work but I didn't succeed. The problem could be with
MI_LOAD_REGISTER_IMM (no rights for changing register) or even with
hardware version. Of course, I may be wrong with the algorithm above.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/21
------------------------------------------------------------------------
On 2011-05-30T15:40:01+00:00 Curtis Gedak wrote:
For others reading this thread, this bug has also been reported for Ubuntu at:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/755841
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/27
------------------------------------------------------------------------
On 2011-05-31T02:50:10+00:00 Gordon Jin wrote:
This seems a major problem. Chris, can we not demote it?
But I don't know why I don't meet this issue.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/28
------------------------------------------------------------------------
On 2011-05-31T12:27:28+00:00 Dmitry Savin wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/29
------------------------------------------------------------------------
On 2011-05-31T14:40:08+00:00 Curtis Gedak wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/30
------------------------------------------------------------------------
On 2011-06-02T15:26:33+00:00 Da-fox wrote:
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/backlight/acpi_video0
--
[ 13.993] (II) Initializing built-in extension COMPOSITE
[ 13.993] (II) Initializing built-in extension DAMAGE
[ 14.445] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 14.445] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 14.445] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 14.445] (II) AIGLX: enabled GLX_SGI_make_current_read
[ 14.445] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 14.445] (II) AIGLX: Loaded and initialized /usr/lib64/dri/i965_dri.so
---------
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)
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/31
------------------------------------------------------------------------
On 2011-06-03T07:28:11+00:00 Dmitry Savin wrote:
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_REGISTER_IMM is not allowed (that's why I cannot set DE_LOAD_SL register) and this operation is converted to NOOP.
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_REGISTER_IMM inside the batch buffer (it should be, but I cannot check if it works).
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/32
------------------------------------------------------------------------
On 2011-06-03T15:54:08+00:00 Curtis Gedak wrote:
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://www.youtube.com/watch?v=leuCriOtTlo
Tearing test for Flash video player (30p source)
http://www.youtube.com/watch?v=IRe9ykSfXyQ
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?
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/33
------------------------------------------------------------------------
On 2011-06-03T16:35:25+00:00 Dmitry Savin wrote:
(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://www.youtube.com/watch?v=leuCriOtTlo
>
> Tearing test for Flash video player (30p source)
> http://www.youtube.com/watch?v=IRe9ykSfXyQ
>
> 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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/34
------------------------------------------------------------------------
On 2011-06-03T17:16:15+00:00 Curtis Gedak wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/35
------------------------------------------------------------------------
On 2011-06-03T20:09:45+00:00 Dmitry Savin wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/36
------------------------------------------------------------------------
On 2011-06-03T20:26:27+00:00 Curtis Gedak wrote:
(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
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/37
------------------------------------------------------------------------
On 2011-06-04T10:17:11+00:00 Dmitry Savin wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/38
------------------------------------------------------------------------
On 2011-06-04T15:36:28+00:00 Curtis Gedak wrote:
(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://www.mythtv.org/wiki/Frame_display_timing
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/39
------------------------------------------------------------------------
On 2011-06-04T17:02:59+00:00 Dmitry Savin wrote:
(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://www.mythtv.org/wiki/Frame_display_timing
>
> 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).
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/40
------------------------------------------------------------------------
On 2011-06-04T21:29:42+00:00 Da-fox wrote:
(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://www.mythtv.org/wiki/Frame_display_timing
> >
> > 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?).
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/41
------------------------------------------------------------------------
On 2011-06-05T07:22:09+00:00 Dmitry Savin wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/43
------------------------------------------------------------------------
On 2011-06-05T16:04:15+00:00 Dmitry Savin wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/44
------------------------------------------------------------------------
On 2011-06-05T19:52:26+00:00 Paul Menzel wrote:
(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://www.youtube.com/watch?v=leuCriOtTlo
> >
> > Tearing test for Flash video player (30p source)
> > http://www.youtube.com/watch?v=IRe9ykSfXyQ
> >
> > 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://clive.sourceforge.net/
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/45
------------------------------------------------------------------------
On 2011-06-05T19:57:08+00:00 Paul Menzel wrote:
(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://lists.freedesktop.org/archives/intel-
gfx/2011-June/010893.html
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/46
------------------------------------------------------------------------
On 2011-06-06T08:20:27+00:00 Da-fox wrote:
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...
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/47
------------------------------------------------------------------------
On 2011-06-06T10:55:21+00:00 Da-fox wrote:
(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 :)
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/48
------------------------------------------------------------------------
On 2011-06-06T17:30:19+00:00 Dmitry Savin wrote:
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
-------------------------------- src/i830_reg.h --------------------------------
index 93d03cf..0a5946c 100644
@@ -65,6 +65,19 @@
#define MI_LOAD_SCAN_LINES_DISPLAY_PIPEA (0)
#define MI_LOAD_SCAN_LINES_DISPLAY_PIPEB (0x1<<20)
+/* Gen6 wait for scan line support */
+#define MI_LOAD_REGISTER_IMM (0x22<<23)
+#define MI_DISPLAY_PIPEA_SCAN_LINE_WAIT (1)
+#define MI_DISPLAY_PIPEB_SCAN_LINE_WAIT (1<<8)
+#define MI_DISPLAY_PIPEA_VBLANK_WAIT (1<<3)
+#define MI_DISPLAY_PIPEB_VBLANK_WAIT (1<<11)
+
+/* 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)|(0x40<<22)|(0x3))
#define COLOR_BLT_WRITE_ALPHA (1<<21)
------------------------------ src/intel_video.c ------------------------------
index 5294f73..506178f 100644
@@ -1365,6 +1365,83 @@ intel_wait_for_scanline(ScrnInfoPtr scrn, PixmapPtr pixmap,
ADVANCE_BATCH();
}
+static void
+intel_wait_for_scanline_gen6(ScrnInfoPtr scrn, PixmapPtr pixmap,
+ xf86CrtcPtr crtc, RegionPtr clipBoxes)
+{
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+ pixman_box16_t box, crtc_box;
+ int pipe, event;
+ Bool full_height;
+ int y1, y2;
+
+ pipe = -1;
+ if (pixmap_is_scanout(pixmap))
+ {
+ pipe = intel_crtc_to_pipe(crtc);
+ }
+ if (pipe < 0)
+ return;
+
+ box = *REGION_EXTENTS(unused, clipBoxes);
+
+ if (crtc->transform_in_use)
+ pixman_f_transform_bounds(&crtc->f_framebuffer_to_crtc, &box);
+
+ /* We could presume the clip was correctly computed... */
+ intel_crtc_box(crtc, &crtc_box);
+ intel_box_intersect(&box, &crtc_box, &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_PIPEA_SCAN_LINE_WAIT;
+ if (full_height)
+ event = MI_DISPLAY_PIPEA_VBLANK_WAIT;
+ } else {
+ pipe = DE_LOAD_SL_PIPEB;
+ event = MI_DISPLAY_PIPEB_SCAN_LINE_WAIT;
+ if (full_height)
+ event = MI_DISPLAY_PIPEB_VBLANK_WAIT;
+ }
+
+ /* 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(MI_LOAD_REGISTER_IMM | 1);
+ OUT_BATCH(DE_LOAD_SL_ADDR);
+ OUT_BATCH(pipe | (y1 << 16) | y2);
+ OUT_BATCH(MI_WAIT_FOR_EVENT | event);
+ ADVANCE_BATCH();
+}
+
+
static Bool
intel_setup_video_buffer(ScrnInfoPtr scrn, intel_adaptor_private *adaptor_priv,
int alloc_size, int id, unsigned char *buf)
@@ -1578,8 +1655,11 @@ I830PutImageTextured(ScrnInfoPtr scrn,
return BadAlloc;
}
- if (crtc && adaptor_priv->SyncToVblank != 0 && INTEL_INFO(intel)->gen < 60) {
- intel_wait_for_scanline(scrn, pixmap, crtc, clipBoxes);
+ if (crtc && adaptor_priv->SyncToVblank != 0) {
+ if(INTEL_INFO(intel)->gen < 60)
+ intel_wait_for_scanline(scrn, pixmap, crtc, clipBoxes);
+ else
+ intel_wait_for_scanline_gen6(scrn, pixmap, crtc, clipBoxes);
}
if (INTEL_INFO(intel)->gen >= 60) {
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/49
------------------------------------------------------------------------
On 2011-06-15T22:38:59+00:00 Curtis Gedak wrote:
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-installer 10.3.181.26ubuntu0.11.04.1 Adobe Flash Player plugin installer
$
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?
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/50
------------------------------------------------------------------------
On 2011-06-15T23:12:01+00:00 Curtis Gedak wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/51
------------------------------------------------------------------------
On 2011-06-16T09:09:42+00:00 Dmitry Savin wrote:
> 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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/52
------------------------------------------------------------------------
On 2011-06-18T15:58:45+00:00 Curtis Gedak wrote:
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://www.phoronix.com/scan.php?page=article&item=xorg_vdpau_vaapi&num=1
This site leads to the following code for compiling mplayer with VAAPI support:
Splitted-desktop systems - Video Acceleration (VA) API
http://www.splitted-desktop.com/~gbeauchesne/
I installed the Xorg Edgers PPA on my Kubuntu Natty Narwhal 11.04 system:
https://launchpad.net/~xorg-edgers/+archive/ppa
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-patch-build.sh script to download the SVN version of
mplayer and built it.
Then I tried running it with the following commands:
cd mplayer-vaapi
./mplayer -vo vaapi -va vaapi /home/user/2041_20110420193000.mpg
Unfortunately this provided only sound on my system:
<... snip>
Playing /home/user/2041_20110420193000.mpg.
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/kubuntu1104/home/gedakc/tmp/
Error opening/initializing the selected video_out (-vo) device.
<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/2041_20110420193000.mpg
I also tried using the gl2 video output with the default installed mplayer that does not have VAAPI support:
/usr/bin/mplayer -vo gl2 /home/user/2041_20110420193000.mpg
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/53
------------------------------------------------------------------------
On 2011-06-18T21:57:21+00:00 Curtis Gedak wrote:
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://launchpad.net/~kernel-ppa/+archive/ppa
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/54
------------------------------------------------------------------------
On 2011-06-20T15:08:31+00:00 Da-fox wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/56
------------------------------------------------------------------------
On 2011-06-20T15:52:44+00:00 Curtis Gedak wrote:
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-xorg-video-intel
ii xserver-xorg-video-intel 2:2.15.0+git20110616.17bf0019-0ubuntu0sarvatt~natty X.Org X server -- Intel i8xx, i9xx display driver
$ 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-xorg-video-intel
ii xserver-xorg-video-intel 2:2.15.0+git20110616.17bf0019-0ubuntu0sarvatt~natty X.Org X server -- Intel i8xx, i9xx display driver
$ 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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/57
------------------------------------------------------------------------
On 2011-06-20T18:02:16+00:00 Da-fox wrote:
(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://goodies.xfce.org/projects/applications/xfce4-screenshooter
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/58
------------------------------------------------------------------------
On 2011-06-21T06:26:04+00:00 Hai-lan wrote:
I can reproduce this bug with following file
http://www.youtube.com/watch?v=IRe9ykSfXyQ(In reply to comment #24)
> (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://www.youtube.com/watch?v=leuCriOtTlo
> > >
> > > Tearing test for Flash video player (30p source)
> > > http://www.youtube.com/watch?v=IRe9ykSfXyQ
> > >
> > > 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://clive.sourceforge.net/
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/59
------------------------------------------------------------------------
On 2011-06-25T14:04:59+00:00 Usedasbugtracking wrote:
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.0+git20110531.340cfb7f-0ubuntu0sarvatt2~natty) but it didn't change anything.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/61
------------------------------------------------------------------------
On 2011-06-25T14:44:58+00:00 Curtis Gedak wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/62
------------------------------------------------------------------------
On 2011-07-04T20:04:55+00:00 Curtis Gedak wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/63
------------------------------------------------------------------------
On 2011-07-06T14:11:38+00:00 Da-fox wrote:
(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.)
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/65
------------------------------------------------------------------------
On 2011-07-06T16:14:17+00:00 Curtis Gedak wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/66
------------------------------------------------------------------------
On 2011-07-08T14:12:31+00:00 Usedasbugtracking wrote:
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?
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/67
------------------------------------------------------------------------
On 2011-07-29T07:08:39+00:00 J-iam-3 wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/68
------------------------------------------------------------------------
On 2011-09-05T17:07:02+00:00 Tino-keitel+fdo wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/71
------------------------------------------------------------------------
On 2011-09-22T16:30:18+00:00 Curtis Gedak wrote:
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://bugs.launchpad.net/ubuntu-release-notes/+bug/600178/comments/38
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/72
------------------------------------------------------------------------
On 2011-09-23T22:51:49+00:00 Curtis Gedak wrote:
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. :-)
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/73
------------------------------------------------------------------------
On 2011-10-07T22:23:47+00:00 SIO wrote:
Came to say that I've found a workaround/fix for this bug on my system:
I've upgraded xserver-xorg-video-intel to 2.16 version, and switched
video output to gl. Using xv still causes tearing, but I'm ok with that.
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
:)
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/76
------------------------------------------------------------------------
On 2011-10-12T16:19:06+00:00 Curtis Gedak wrote:
(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?
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/77
------------------------------------------------------------------------
On 2011-10-12T17:13:32+00:00 SIO wrote:
(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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/78
------------------------------------------------------------------------
On 2011-10-31T16:49:33+00:00 Sergeyn wrote:
I have extra/xf86-video-intel 2.16.0-1 but tearing still here and "mplayer -vo gl" doesn't help.
I'm using gnome 3.2 if it is necessary.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/81
------------------------------------------------------------------------
On 2011-11-11T12:11:12+00:00 Eugeni Dodonov wrote:
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).
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/84
------------------------------------------------------------------------
On 2011-11-11T18:45:41+00:00 Dmitry Savin wrote:
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.
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/86
------------------------------------------------------------------------
On 2011-11-12T00:30:48+00:00 Eugeni Dodonov wrote:
> 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...
Reply at: https://bugs.launchpad.net/xserver-xorg-video-
intel/+bug/755841/comments/87
** Changed in: xserver-xorg-video-intel
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/755841
Title:
[sandybridge] video tearing
To manage notifications about this bug go to:
https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/755841/+subscriptions
References
