Fix tearing due to bastardized OpenGL in Intel Sandy Bridge
The OpenGL GLX video backend produces tearing: To reproduce the bug, it suffices to download the teartest video [1], set the video backend to OpenGL GLX, and play the video. Every few seconds, a tearing line is clearly visible for ~0.5 seconds. Compositing is disabled and I am using full-screen mode.
I am using Debian testing. The graphics hard is the HD3000 built into my Core i5-2450M. Mesa is at version 8.0.1, the Intel Xorg driver at 2.19, the kernel at 3.6.4.
Some guessing: If I enable KWin compositing and enable the "Paint Draw" debug plugin, I can see that VLC does not issue a full-screen redraw: My screen has an aspect ratio of 16:10, while the video is 16:9, and only the 16:9 area is redrawn. I conclude that VLC does not use glXSwapBuffers on the whole full-screen window. However, on modern Intel hardware and with the proprietary NVidia drivers, that seems to be the only way to produce a tear-free playback: glXWaitVideoSync is broken[2]. mplayer2 with the OpenGL backend plays the same file completely tear-free in full-screen mode with compositing disabled. The "Paint Draw" debug plugin shows that the full screen is re-drawn for each video frame, so I assume it is doing a full-screen glXSwapBuffers.
[1] http://ompldr.org/iYXBldg-hide or https://bugs.launchpad.net/ubuntu-release-notes/+bug/600178/comments/38
[2] https://bugs.freedesktop.org/show_bug.cgi?id=37686 and https://bugs.kde.org/show_bug.cgi?id=307965
- #184343.0.12
Activity
VLC does not use glXWaitVideoSync() and never did. It has always used glXSwapBuffers() and it always redraws an entire picture. In fact, I can't really conceive how a media player could draw partial pictures: video codecs are all based on entire frames (or entire fields for interlaced videos).
So I don't understand your problem description => not me => patch welcome.
That last paragraph was just guessing - I am quite new to GLX and OpenGL. The actual bug is, as described previously: There's tearing. I am unsure what else there is to add to the problem description ;-)
Now, for the possible problem causes: I don't know for sure why or how there's tearing, but I know it can be avoided as mplayer2 is perfectly tear-free, and a simple GLX-based application displaying a full-screen tear test also shows no tearing at all. And finally, the KWin debug output says that VLC does not do a full-screen repaint. Could it be that VLC uses glXSwapBuffers on a non-fullscreen window, i.e. the X Window associated with the GLX context is not the fullscreen window (including the black bars) but a window with the precise aspect ratio of the video, put on top of a fullscreen black background? Using glXSwapBuffers on that window would not trigger a pageflip as that can (naturally) only be done for full-screen buffer swaps.
-
Of course, VLC won't repaint the entire screen unless the aspect ratio and size are adequate. That is very much by design. It ensures the black bars get redrawn and mouse events only come from the rendering area.
It seems to me your video display drivers are buggy. glXSwapBuffers() is not supposed to require full screen.
Replying to [comment:3 courmisch]:
Of course, VLC won't repaint the entire screen unless the aspect ratio and size are adequate. That is very much by design. That's the problem then: Since not the entire screen is affected, the driver can not to a page flip, so it has to copy things around.
It seems to me your video display drivers are buggy. glXSwapBuffers() is not supposed to require full screen. There is bug https://bugs.freedesktop.org/show_bug.cgi?id=37686 , as mentioned above. The Sandy Bridge (and newer) hardware is designed to assume that screen updates are done using a page flip. Naturally, glXSwapBuffers can only do a page flip if it affects the full-screen - otherwise, something (the GLX implementation in X?) has to copy the swapped buffer to the buffer on which the scanout is performed. To avoid tearing, that copy has to be synchronized with the v-blank, and that's no longer supported in Sandy Bridge.
According to what the Intel devs say in that bugreport, that manual synchronization also costs much more power than a page flip, so "optimizing" the updated region not to cover the full screen will usually be more costy than drawing a bit more and doing a page flip.
changed milestone to %Features paradize
At the very least, page flips are preferable not only because they (guarantee to) avoid tearing, but also because the GPU has to do less copying. As far as I know, when VLC does a glXSwapBuffer and the video aspect ratio does not match the one of the screen, the GPU has to copy VLC's buffer to where the GPU scans from.
-
Replying to [comment:7 ralf]:
At the very least, page flips are preferable not only because they (guarantee to) avoid tearing, but also because the GPU has to do less copying.
Still, the driver has to deal with windowed playback. Therefore this is a driver bug in my opinion - or is there another secret magic work-around for windowed playback? Also, did Intel dare to impose tearing onto Windows and MacOS as well, or are the prototype-grade display drivers only for Linux?
As far as I know, when VLC does a glXSwapBuffer and the video aspect ratio does not match the one of the screen, the GPU has to copy VLC's buffer to where the GPU scans from.
It may be suboptimal but it needs to work for windowed playback and for backward compatibility.
Oh, it should be fixed in VLC too. This change will be required to render subtitles on the "black bars". But for the time being it looks like it would only be a work-around for unfinished Intel display drivers. Thus I would not expect the over-worked and volunteer VLC developpers to fix it anytime soon (at least not me). Patch welcome.
Replying to [comment:8 courmisch]:
Still, the driver has to deal with windowed playback. Therefore this is a driver bug in my opinion - or is there another secret magic work-around for windowed playback? Well, the driver can deal with it, it just can't avoid tearing. According to what the Intel guys wrote in the bugreport I referenced [1], the hardware just can't do that anymore. The latest Intel driver has a "TearFree" option which adds an in-driver compositor which in turn always performs a pageflip, and therefore avoids tearing. Which however again means many additional copies...
Also, did Intel dare to impose tearing onto Windows and MacOS as well, or are the prototype-grade display drivers only for Linux? The Windows Vista+ compositor always performs a pageflip, so there's no need for any other synchronization means. Don't know about MacOS.
It may be suboptimal but it needs to work for windowed playback and for backward compatibility. Sure, windowed mode will still have tearing on non-composited desktops, and VLC can do nothing about it. If using a compositor which does things right (TM), there'll be no tearing in windowed mode as the compositor makes sure page-flips are performed. In full-screen mode however, most compositors unredirect the window to avoid unnecessary copies, so VLC is in charge of making sure page-flips can be done.
Patch welcome. Yeah, I got that part ;-) . I'm currently trying to get KWin to perform page-flips properly, for all or at least "large" repaints. Maybe I can look at VLC once that works, but considering the size of the codebase and my limited experience in that area, I wouldn't expect much ;-)
If using a compositor which does things right (TM), there'll be no tearing in windowed mode as the compositor makes sure page-flips are performed.
I'm currently trying to get KWin to perform page-flips properly, for all or at least "large" repaints.
Did you check KWin with your page-flips patches and VLC? There is still tearing?
You also may be interested in another issue that related to video playback and tearing on Intel hardware: #7405 (closed)
Replying to [comment:10 RussianNeuroMancer]:
Did you check KWin with your page-flips patches and VLC? There is still tearing? If I apply the patch and disable unredirecting for full-screen apps, then no application can possibly produce any tearing, no matter what it does. I confirmed this using VLC and mplayer with various backends in full-screen and windowed mode.
You also may be interested in another issue that related to video playback and tearing on Intel hardware: #7405 (closed) I only tired VAAPI once and, as described there, it was so unusably slow that I did not even look for tearing. There was a commit in KWin recently which maybe related [1] which I can test once KDE 4.9.3 is released. It says VDPAU in the comment but may VAAPI is affected as well.
I am using ubuntu 12.10 with compiz/unity, with intel HD4000. Out of the box I do not see this issue at all, because compiz properly uses glxswapbuffers and everything is dandy. however if "unredirect fullscreen windows" in compiz is enabled so VLC bypasses compositing completely I do see this problem in VLC with openGL output, tearing across the top of the video.
Ubuntu plans to release a compiz update with this option enabled by default too, so a lot of people may start experiencing this issue.
Original author: bwat47
-
See #18434 (closed)
added Status::fixed label
changed milestone to %3.0.x maintenance
