Any video tears with sandybridge graphics (i5-2500 integrated) with intel driver version 2.14.0. Updating to version 2.15.0 doesn't solve the problem. Distro LinuxMint 11 (the same was in Ubuntu 11.04 with all updates). OpenGL apps tear as well. uname -a: Linux envel 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux xvinfo: X-Video Extension version 2.2 screen #0 Adaptor #0: "Intel(R) Textured Video" number of ports: 16 port base: 83 operations supported: PutImage supported visuals: depth 24, visualID 0x21 number of attributes: 3 "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 0) "XV_SYNC_TO_VBLANK" (range -1 to 1) client settable attribute client gettable attribute (current value is 1) maximum XvImage size: 2048 x 2048 Number of image formats: 5 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x434d5658 (XVMC) guid: 58564d43-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
Created attachment 47245 [details] Xorg log
The ability to wait upon scanlines was apparently defeatured, or at least disappeared from the specs...
Created attachment 47246 [details] Tearing screenshot
(In reply to comment #2) > The ability to wait upon scanlines was apparently defeatured, or at least > disappeared from the specs... Where can I find specs and how it is implemented for other intel graphics chips? (I have x86-video-intel-2.15.0 source code in front of me). I think it is important issue for desktop computers with Intel graphics.
(In reply to comment #2) > The ability to wait upon scanlines was apparently defeatured, or at least > disappeared from the specs... It looks like it is defeatured. glxgears shows me 60fps with tearing.
Finally I found the ability to enable wait_for_scan_line support on SandyBridge. According to specs, we should use DE_LOAD_SL ("This register is used to initiate a display scan line compare on DevSNB:D2 and later steppings"). To load a value to this register it is needed to use MI_LOAD_REGISTER_IMM. So the algorithm should be the following: 1. Calculate start/end scan lines 2. Call MI_LOAD_REGISTER_IMM with DE_LOAD_SL address and parameter equals to (0x11x<<29 | (start_sl<<16) | end_sl), where x represents pipe (0 for A, 1 for B). 3. Call MI_WAIT_FOR_EVENT with corresponding bits set to true (wait for pipe A/B scan line). Notice, that these bits are changed since last docs version. The above should work but I didn't succeed. The problem could be with MI_LOAD_REGISTER_IMM (no rights for changing register) or even with hardware version. Of course, I may be wrong with the algorithm above.
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.
This seems a major problem. Chris, can we not demote it? But I don't know why I don't meet this issue.
(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.
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.
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)
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.
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?
(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.
(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 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 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 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 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.
(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).
(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?).
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.
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 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/
(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
Created attachment 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...
(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 :)
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) {
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?
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.
> 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.
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.
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
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.
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.
(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
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/
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.
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.
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.
(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 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.
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?
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.
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.
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.
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. :-)
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 :)
(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 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.
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.
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).
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.
> 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...
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://www.nvnews.net/vbulletin/showthread.php?t=149276, http://nvnews.net/vbulletin/showthread.php?t=149776), and there is a nice description at https://bugzilla.gnome.org/show_bug.cgi?id=562669 as well. 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
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.
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 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://www.nvnews.net/vbulletin/showthread.php?t=149276, > http://nvnews.net/vbulletin/showthread.php?t=149776), and there is a nice > description at https://bugzilla.gnome.org/show_bug.cgi?id=562669 as well. 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://cgit.freedesktop.org/~ickle/xserver/commit/?id=9e92c256853fa29bddd27e41fdd24e0b140e7fd4 to disambiguate that case and to permit even faster vblank_mode=0 swapping.
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_PAINT=disable-clipped-redraws:disable-culling 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://bugzilla.redhat.com/show_bug.cgi?id=747668
Thank you very much, Mr. Bordjukov. The workaround solves tearing issue in compiz without any noticible performance degradation.
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.
(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://www.nvnews.net/vbulletin/showthread.php?t=149276, > > http://nvnews.net/vbulletin/showthread.php?t=149776), and there is a nice > > description at https://bugzilla.gnome.org/show_bug.cgi?id=562669 as well. > > 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://cgit.freedesktop.org/~ickle/xserver/commit/?id=9e92c256853fa29bddd27e41fdd24e0b140e7fd4 > 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://mail.xfce.org/pipermail/xfce4-dev/2011-September/029051.html), and if it is now possible to implement any of this yet? (I think the idea there was to implement a vsync-wait call to xrender?)
Please take a look at this bug https://bugs.freedesktop.org/show_bug.cgi?id=43674 and confirm it.
*** Bug 43674 has been marked as a duplicate of this bug. ***
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 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).
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.
Hello, I was unable to reproduce the bug on Fedora 17 with Gnome Shell. On Wed, May 16, 2012 at 12:42 PM, <bugzilla-daemon@freedesktop.org> wrote: > > https://bugs.freedesktop.org/show_bug.cgi?id=37686 > > --- Comment #67 from Svein Ove Aas <sveina@gmail.com> 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://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
(In reply to comment #68) > Hello, > > I was unable to reproduce the bug on Fedora 17 with Gnome Shell. Take a look https://bugs.freedesktop.org/show_bug.cgi?id=43674
Even with SNA enabled, the only solution that has worked for me is the workaround bord offered: CLUTTER_PAINT=disable-clipped-redraws:disable-culling
(In reply to comment #70) > Even with SNA enabled, the only solution that has worked for me is the > workaround bord offered: > > CLUTTER_PAINT=disable-clipped-redraws:disable-culling 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.
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 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://bugs.freedesktop.org/show_bug.cgi?id=43674 I have tearing on tearing test 720x406 video file both via vaapi and gl without compositing.
(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 reply to comment #74) > I have no tearing on GL in fullscreen. Please test it with tearing test 720x406 from https://bugs.freedesktop.org/show_bug.cgi?id=43674
(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://bugs.freedesktop.org/show_bug.cgi?id=43674 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_INIT_VIDEO); SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1); SDL_SetVideoMode(800, 600, 32, mode); for (i = 0; i < 100; i++) { glClearColor(1, 1, 1, 1); glClear(GL_COLOR_BUFFER_BIT); SDL_GL_SwapBuffers(); glClearColor(0, 0, 0, 1); glClear(GL_COLOR_BUFFER_BIT); SDL_GL_SwapBuffers(); } 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 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_SetVideoMode(800, 600, 32, mode); to SDL_SetVideoMode(1366, 768, 32, mode); and can't see any tearing, but there is tearing in window mode without compositing.
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 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 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->framebuffer blitting routines that do care about pixels, but I'm not using those, and I don't think mplayer is either. 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.
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(SDL_INIT_VIDEO); 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_SetAttribute(SDL_GL_SWAP_CONTROL, 1); SDL_SetVideoMode(w, h, 32, mode); for (i = 0; i < 100; i++) { glClearColor(1, 1, 1, 1); glClear(GL_COLOR_BUFFER_BIT); SDL_GL_SwapBuffers(); glClearColor(0, 0, 0, 1); glClear(GL_COLOR_BUFFER_BIT); SDL_GL_SwapBuffers(); } 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 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 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-3.4+drm-intel-next-2012-05-20. 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 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-3.4+drm-intel-next-2012-05-20. > 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 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.
Using the GL tester, I get tearing in windowed mode when I have my TV hooked up.
(In reply to comment #85) > (In reply to comment #72) > > Just as an update from the past post. > > Thanks for the update! > > > Unfortunately, all my attempts for fixing this properly have failed so far, the > > hardware does not wants to collaborate with the software for inter-ring > > synchronization. > > I have a couple questions if you don't mind. In a previous comment, you > mentioned that a fix would require work in the kernel, in libdrm and in the X > driver. So is a fix really viable within the SNB product cycle? Does it affect > Ivy Bridge as well? I ask because I may consider upgrading early to Ivy Bridge > if this is no longer a issue. > > > So the workaround I used previously still applies - I need to disable > > compositing and use either vaapi or gl rendering, which perform vsync'ed screen > > updates. This way, I see no tearing. > > I can still see tearing with GL rendering. It's much less noticeable, but it's > there. I can see it clearly when I'm watching basketball games in a 1080p TV > (using HDMI), specially during the fastbreak, when the camera pans quickly. But > yea, it's much better than X11, Xv or anything like that. Is this expected? I > tested both with mplayer and VLC (glx output). > You might be seeing the effect as shown in my attachment (https://bugs.freedesktop.org/attachment.cgi?id=47585), which according to daniel vetter is "probably unfixable". I think this is because possibly that is actually an artifact of capturing the screenshot. However something else which happens for me is that in the vertical-bars video the bars don't move smoothly across the screen. I don't know how to really explain it, but it is as if my screen has a really slow switching time, so that the front of the bars (as they move) lights up, while the rear fades out. However this fading is not gradual, but seems to happen with a lot of 'blinking'. I'm not sure what is causing this yet, but I think it might be some artifact of the screen (seems to happen with some bars painted in the gimp, too), it looks quite weird. Anyway make sure it's none of that, take a picture with a (decent) camera. > I can't even test VAAPI. VLC supports it, but when I enable it, I get 100% CPU > usage and less than 1 FPS for some reason. There's the mplayer patches for > VAAPI support, but it seems in very bad shape. Is there a test program for > VAAPI? You can try the mplayer-vaapi branch at git://gitorious.org/vaapi/mplayer.git , which is maintained by Gwenole Beauchesne, who also works on intel's vaapi support. The mplayer version it is based on is quite old, and it is based on the original mplayer (not mplayer2), but it works fine nonetheless. > > For the record, I'm not running a composite manager. > > Thanks for looking into this Eugeni.
(In reply to comment #87) > (In reply to comment #85) > > I can still see tearing with GL rendering. It's much less noticeable, but it's > > there. I can see it clearly when I'm watching basketball games in a 1080p TV > > (using HDMI), specially during the fastbreak, when the camera pans quickly. But > > yea, it's much better than X11, Xv or anything like that. Is this expected? I > > tested both with mplayer and VLC (glx output). > > > You might be seeing the effect as shown in my attachment > (https://bugs.freedesktop.org/attachment.cgi?id=47585), which according to > daniel vetter is "probably unfixable". I think this is because possibly that is > actually an artifact of capturing the screenshot. However something else which > happens for me is that in the vertical-bars video the bars don't move smoothly > across the screen. I don't know how to really explain it, but it is as if my > screen has a really slow switching time, so that the front of the bars (as they > move) lights up, while the rear fades out. However this fading is not gradual, > but seems to happen with a lot of 'blinking'. I'm not sure what is causing this > yet, but I think it might be some artifact of the screen (seems to happen with > some bars painted in the gimp, too), it looks quite weird. > Anyway make sure it's none of that, take a picture with a (decent) camera. Note though that I'm seeing this in video, I'm not trying to take screenshots. Just to be clear. > > I can't even test VAAPI. VLC supports it, but when I enable it, I get 100% CPU > > usage and less than 1 FPS for some reason. There's the mplayer patches for > > VAAPI support, but it seems in very bad shape. Is there a test program for > > VAAPI? > You can try the mplayer-vaapi branch at git://gitorious.org/vaapi/mplayer.git , > which is maintained by Gwenole Beauchesne, who also works on intel's vaapi > support. The mplayer version it is based on is quite old, and it is based on > the original mplayer (not mplayer2), but it works fine nonetheless. I'll check that out, thanks.
I have tearing using Vlc on Intel HD Chipset Intel® Celeron® Processor G530 (Sandy Bridge), xf86-video-intel git version but even with 2.19.0 version, linux kernel 3.4.4, xorg-server-1.12.2, mesa 8.0.3, libdrm-2.4.33. I use openbox desktop manager, and the only workaround to avoid tearing is to use Vlc Opengl video output together with Vlc fullscreen option. I notice tearing especially with 1920x1080 resolution video files.
(In reply to comment #89) > I have tearing using Vlc on Intel HD Chipset Intel® Celeron® Processor G530 > (Sandy Bridge), xf86-video-intel git version but even with 2.19.0 version, > linux kernel 3.4.4, xorg-server-1.12.2, mesa 8.0.3, libdrm-2.4.33. I use > openbox desktop manager, and the only workaround to avoid tearing is to use Vlc > Opengl video output together with Vlc fullscreen option. I notice tearing > especially with 1920x1080 resolution video files. With intel driver GIT Commit ID: 2941a5fe15626730869a48a63bb088e8ae2c0549, I can avoid tearing without vlc Opengl video output, but I need Vlc fullscreen option enabled. Intel driver accel method I use is SNA.
Just wanted to report that I seem to have less problems when using the SNA driver.
Reclaiming ownership, downgrading priority since this is impossible to fix without compromise with the current hardware support. For the foolhardy, you may like to try Option "TearFree" "true". It basically runs another compositor layer between the framebuffer and the scanout, so a major waste of memory if you are indeed using a pageflipping renderer (video player, game, compositor). And it exposes a few bugs in the Damage layer, so not ready for prime time just yet.
It is sad that Other OSes seem to have not problem with this basic functionality. Could you tell us if Ivy Bridge suffers from the same issue? If no, SNB and IVB are pin-compatible, so people affected could just upgrade CPU.
By other OS, I presume you mean the ones that *only* support pageflipping compositors? Which for the reasons highlighted above work just fine. IVB in theory supports vsync'ed writes to the scanout, give or take a few hundred microseconds in signal latency between the display engine and the render pipeline. When I get my hands on an IVB, I'll hook up the required kernel/xf86-video-intel infrastructure and see if the claimed retrofit of vsync works... In the meantime, the only answer is take a leaf out of the other OSes playbook and only use pageflipping.
(In reply to comment #94) > By other OS, I presume you mean the ones that *only* support pageflipping > compositors? Which for the reasons highlighted above work just fine. > > IVB in theory supports vsync'ed writes to the scanout, give or take a few > hundred microseconds in signal latency between the display engine and the > render pipeline. When I get my hands on an IVB, I'll hook up the required > kernel/xf86-video-intel infrastructure and see if the claimed retrofit of vsync > works... > > In the meantime, the only answer is take a leaf out of the other OSes playbook > and only use pageflipping. Sorry i'm about to buy an IVB to replace my GMA950. I've read that since v2.6.38 Linux handles page flipping and it also seems that DRI2 can handle it : am i wrong ? Therefore could it be solved using current stack ? Or is a new compositor like Wayland needed ? Thanks
If you have an unredirected fullscreen DRI2 application, then it will use pageflipping to update the scanout upon a SwapBuffers. So something as simple as 'mplayer -fs -vo gl' should be enough to achieve tear-free playback on most DE (you may have to tweak a few compositor settings if using one though).
(In reply to comment #96) > If you have an unredirected fullscreen DRI2 application, then it will use > pageflipping to update the scanout upon a SwapBuffers. So something as simple > as 'mplayer -fs -vo gl' should be enough to achieve tear-free playback on most > DE (you may have to tweak a few compositor settings if using one though). Is this also true when you use multiple monitors (xrandr output follows)? Because I use mplayer -fs -vo gl with xf86-video-intel 8066bc33d78e78ce7c13833b08a7daaea2f3ed22 (AccelMethod SNA, TearFree not set) and I do notice tearing. Here’s my xrandr output: Screen 0: minimum 320 x 200, current 3520 x 1200, maximum 32767 x 32767 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0*+ 1280x1024 75.0 72.0 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 640x480 72.8 75.0 66.7 60.0 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis) HDMI2 connected 1920x1200+1600+0 (normal left inverted right x axis y axis) 474mm x 296mm 1920x1200 60.0*+ 1600x1200 60.0 1680x1050 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1024x768 75.1 70.1 60.0 800x600 72.2 75.0 60.3 640x480 72.8 75.0 60.0 720x400 70.1 HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis)
(In reply to comment #97) > (In reply to comment #96) > > If you have an unredirected fullscreen DRI2 application, then it will use > > pageflipping to update the scanout upon a SwapBuffers. So something as simple > > as 'mplayer -fs -vo gl' should be enough to achieve tear-free playback on most > > DE (you may have to tweak a few compositor settings if using one though). > Is this also true when you use multiple monitors (xrandr output follows)? > Because I use mplayer -fs -vo gl with xf86-video-intel > 8066bc33d78e78ce7c13833b08a7daaea2f3ed22 (AccelMethod SNA, TearFree not set) > and I do notice tearing. Same with UXA and vlc with glx output. No compositor here. I can clearly see tearing when I connect the laptop to an external monitor to watch movies. I think there's two bugs being discussed here. One is that compositors that don't unredirect fullscreen windows may give you tearing. Another is that even without using a compositor, and even if you render using OpenGL, you can still get tearing.
*** Bug 52470 has been marked as a duplicate of this bug. ***
I was redirected to this bug. In my case i have "tearing" only if i use mplayer with -vo xv. It plays fine with -vo gl2. No composite window manager used. I also can reproduce it with 2.20, but _can't_ reproduce it with 2.17 - it's why i call it regression. Cris, are you sure it is the same bug?
I checked the screenshots and in may case it is not tearing.
(In reply to comment #92) > Reclaiming ownership, downgrading priority since this is impossible to fix > without compromise with the current hardware support. For the foolhardy, you > may like to try Option "TearFree" "true". It basically runs another compositor > layer between the framebuffer and the scanout, so a major waste of memory if > you are indeed using a pageflipping renderer (video player, game, compositor). > And it exposes a few bugs in the Damage layer, so not ready for prime time just > yet. I tried Option "TearFree" "true" with intel driver git version 146959dd5ef28384a3db4fce4bf7840f2b3ec58c or Intel 2.20.2 (with SNA acceleration enabled) + kernel 3.4.7 + vlc 2.0.3 and I did not have tearing anymore even disabling vlc fullscreen option.
The bug still present on the last kernel and Xorg. I have a tearing on the desktop and video players the only workaround to problem (enable Vsync) causes me mouse laggy on moviments of windows and all desktop objets icons, scroll bar, menus, etc... I have a Intel HD 2000 Chipset Intel® Celeron® Processor B800 (Sandy Bridge). Sorry for my bad English I am Spanish.
Forwarding a message from Axel Rohde Hi Chris, I just tested the standalone OpenGL compositor fbcompose from this site https://launchpad.net/~fluxbox-maintainers/+archive/nightly/+packages fluxbox-fbcompose_1.3.2+nightly+120311-1_amd64.deb ... on a i5-3550, Debian wheezy, xf86-video-intel-2.20.7 using SNA, fvwm2. By just starting fbcompose without any arguments I got rid of tearing in non-fullscreen(!) mplayer2, mplayer-vaapi, smplayer2, totem and vlc/rvlc windows. The latter three used to tear in fullscreen mode, too. Since I was too lazy to compile it, I faked the unmet dependency on libGLEW.so.1.6 by symlinks in /usr/lib/x86_64-linux-gnu ln -s libGLEW.so.1.7.0 libGLEW.so.1.6.0 ln -s libGLEW.so.1.7.0 libGLEW.so.1.6 This seems to be the home of the project: http://git.fluxbox.org/fluxbox_gediminas.git/ Before stumbling across fbcompose I tried Cairo-compmgr and dcompmgr, both are unusable as they simply screw up the display. The only side-effect of fbcompose I've spotted so far is upscaling instead of tiling of the background bitmap. This workaround can become a valueable comment to https://bugs.freedesktop.org/show_bug.cgi?id=37686 for all users of "vintage" window managers. -- Please note that this is the equivalent of Option "TearFree", with the extra latency of going through an external process.
I still can see tearing even if driver option "TearFree" is enabled, when I rotate display right or left (xorg monitor Option "Rotate"), so when the axes are reversed.
(In reply to comment #105) > I still can see tearing even if driver option "TearFree" is enabled, when I > rotate display right or left (xorg monitor Option "Rotate"), so when the > axes are reversed. Yup, that's expected at this moment in time. To avoid tearing down will require another indirection which I haven't added just yet.
Note in addition to using pageflipping via the TearFree option, there is a glimmer of light in the form of kernel commit d7d4eeddb8f72342f70621c4b3cb718af9361712 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Oct 17 12:09:54 2012 +0100 drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffers and xf86-video-intel commit 891bae4aa91e85542dcbe38f6ee92141e3efc801 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Oct 17 11:29:10 2012 +0100 sna: Use the secure batches to program scanline waits on gen6+ to try and convince the hardware to do vsync'ed updates. (In terms of power efficiency, using pageflipping is the way forward as that is how the hardware is designed to operate. Also note that only the later steppings of SNB have scanline waits...)
I don't understand the technical details, so please forgive misunderstandings or stupid questions. Do I need SNA for the TearFree option? I get stuttering with SNA and TearFree, and still get tearing with TearFree without SNA. I created a xorg.conf with only the following: Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "sna" Option "TearFree" "true" EndSection Is that the correct way to do it? Is there any chance of a fix in the foreseeable future? Or is buying a graphics card a good idea at this point?
(In reply to comment #108) > I don't understand the technical details, so please forgive > misunderstandings or stupid questions. > > Do I need SNA for the TearFree option? I get stuttering with SNA and > TearFree, and still get tearing with TearFree without SNA. > I created a xorg.conf with only the following: > Section "Device" > Identifier "Intel Graphics" > Driver "intel" > Option "AccelMethod" "sna" > Option "TearFree" "true" > EndSection > Is that the correct way to do it? > > Is there any chance of a fix in the foreseeable future? Or is buying a > graphics card a good idea at this point? The stuttering is more or less expected at this point (mostly depends upon a client stalling due to a readback) as TearFree is just a proof-of-principle, and only possible with SNA. I plan to finish the asynchronous implementation in the near future.
I'm now on Kubuntu 12.10 and I enabled in xorg.conf both the tearfree option and the sna acceleration. It's definitely better: the xv output seems fine so far in mplayer, the gl output is however unusable as the video keep halting during the play (truthfully I don't really care about it as long as the xv output works). Watching youtube gives me less headache but it still isn't perfect: on some videos there's sometimes still tearing. One thing that I also noticed: after watching a youtube video in fullscreen the display gets somehow corrupted at the bottom of the kde screen (the sidebar containing the desktop shortcuts, the clock, the minimized windows). When I pass the mouse pointer on it everything gets fine again (as it is refreshed) but not for long... Should I expect some improvements in a more recent driver that the one provided in Kubuntu 12.10?
I'm on Ubuntu 12.10 using SNA. Tear is still present on video playback (mainly with VLC) with compositor enabled or disabled. (va-api enabled/disabled no changes as well) this is my xorg.conf video options: Option "AccelMethod" "sna" Option "SwapbuffersWait" "false" Option "TearFree" "true" Just want to add that TearFree option is not working as this command shows: :~$ cat /var/log/Xorg.0.log |grep free [ 5336.772] (**) intel(0): "Tear free" disabled
(In reply to comment #111) > I'm on Ubuntu 12.10 using SNA. > > Tear is still present on video playback (mainly with VLC) with compositor > enabled or disabled. (va-api enabled/disabled no changes as well) Which is expected as Ubuntu 12.10 doesn't carry the required kernel patches.
vsync seems to be fully working now on SNB/IVB with 2.21 and kernel 3.8, so the remaining issue is to get TearFree solid and performant for all use cases.
(In reply to comment #113) > vsync seems to be fully working now on SNB/IVB with 2.21 and kernel 3.8, so > the remaining issue is to get TearFree solid and performant for all use > cases. Thanks for working on this. I have upgraded to Linux 3.8-rc7 and xf86-video-intel 2.21.2 on my ThinkPad X200 (Intel GM45) and on my workstation (Sandy Bridge GT2). On my X200, I can use the TearFree option without any side-effects. If I enable it on my workstation though, the result of terminal commands such as ls -hl or ps auxf often lags — the lines appear one after another, just like on a serial connection. Just wanted to let you know in case you were not aware of that yet. Let me know if you need any more details.
The cause is that replies end up being blocked by the synchronous pageflip used for the tear free update of the scanout. The solution is obvious, but just tricky to implement in an efficient manner that also solves the unnecessary readbacks. If I get it right the extra complexity should help for normal rendering as well.
Works great now, no more tearing. Thank you!
running ubuntu 13.04/kde 4.10 on my laptop (kernel 3.8/ ddx 2.21, ivybridge). kwin still tears at the top of the screen even with sna enabled and vsync on in kwin, but I assume thats just this bug: https://bugs.kde.org/show_bug.cgi?id=307965 So I tried disabling vsync in kwin and using the tearfree option which did remove all tearing, and seems to perform reasonably well for desktop usage and video playback (haven't tried anything else)
Since I saw fbcompose mentioned above as a lightweight standalone compositor that can produce tear-free output working around this issue, I'd like to mention I've found another similar compositor that seems to be under more active development: Compton: https://github.com/chjj/compton Its a nice lightweight compositor that doesn't need to replace your window manager or anything, so it can easily be used to work around this issue and get tear-free output. In my testing its been very stable too. Using it with: compton --backend glx --paint-on-overlay --glx-no-stencil --vsync opengl-swc successfully completely removes tearing for me on both my intel machines (including in fullscreen video and with multiple displays), and performs better than using the TearFree xorg option :)
*** Bug 67823 has been marked as a duplicate of this bug. ***
TearFree should be much improved as of: commit fa2687bdd5a4c8bc608dac8bb711035f0752a725 Author: Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk>
I'm happy with TearFree now. Please report any issues you find as separate bugs, thanks everyone.
Will it be made default? Tx
No. (Though there maybe some hardware which may require TearFree by default to function correctly, in which case it will be enabled automatically.) The problem is that it increases memory allocation considerably and reduces performance, giving you the same penalty as using a compositor. If you then use a compositor on top, you use even more memory to achieve the same effect. As such it is optional.
The Arch Linux Wiki says that TearFree is no longer needed when using DRI3: https://wiki.archlinux.org/index.php/intel_graphics#Tear-free_video Is that correct? Does enabling TearFree actually do anything when using DRI3? Or is TearFree=True being ignored when using DRI3?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.