I'm consistently seeing heavy tearing in Firefox and mpv on Intel HD Graphics 3000 (i7 2640M), even with _any combination_ of the following xorg.conf settings. Tested on linux 4.1.15 and 4.3.3. Option "DRI" "3"/"2" Option "TearFree" "true"/"false" Option "SwapbuffersWait" "true"/"false" Option "AccelMethod" "glamor"/"sna" It happens with all video-out modes in mpv (x11, xv, vaapi, opengl, opengl-hq), with or without vaapi decoding. The only way to avoid this is by running 'compton --backend xr_glx_hybrid --vsync opengl-swc. But this is a workaround that forces vsync unconditionally for everything, anytime, with its disadvantages. Aren't TearFree and SwapbuffersWait supposed to prevent this? On 945GM, with no custom Xorg configuration, I see minimal tearing in Firefox and sometimes mpv, which also can be worked around with forced vsync. Tested on linux 4.1.15. Distro: Arch Linux Kernel: 4.1.15 and 4.3.3 Driver: xf86-video-intel 1:2.99.917+519+g8229390 Xorg: xorg-server 1.18.0-4 mpv: 0.14.0 There are no warnings or errors in any of the logs.
TearFree should eliminate the tearing, modulo any bugs. SwapbuffersWait only disables the vsync, it doesn't enforce it (so still up to the application to request vsync). Do you mind attaching a sample Xorg.log? I don't mind what settings.
Created attachment 121000 [details] HD3000 Xorg.log
Created attachment 121001 [details] HD3000 Xorg.log
So I should not set SwapbuffersWait to "true" if I want it to vsync when needed. Is that right?
(In reply to Carsten Mattner from comment #4) > So I should not set SwapbuffersWait to "true" if I want it to vsync when > needed. Is that right? SwapbuffersWait "true" is the default behaviour, which is for SwapBuffers to be synchronised to refresh (and ideally does not tear, but that also depends upon the swap parameters sent by the client). SwapbuffersWait "false" disables the sync to vrefresh. Hmm, I could actually use that as unset / false / true and if set to true always force swap buffers to wait.
If I don't force vsync via compton, then vaapi's decoder also causes random black pixels/rectangles to appear (corrupt) in the video. That seems to start after a while of use and not right after a fresh boot and viewing the first video stream. Same machine.
(In reply to Carsten Mattner from comment #6) > If I don't force vsync via compton, then vaapi's decoder also causes random > black pixels/rectangles to appear (corrupt) in the video. That seems to > start after a while of use and not right after a fresh boot and viewing the > first video stream. Same machine. That's more than likely the libva/intel bug where they forgot to declare they were writing into the buffers.
> That's more than likely the libva/intel bug where they forgot > to declare they were writing into the buffers. Good thing it's not related to general tearing issues. Do you have a pointer to a bug report or preliminary patch I can apply in libva?
I am also suffering tearing issues but I commented at bug 72290 (this looks to me like a dupe of that bug :/)
(In reply to Carsten Mattner from comment #8) > > That's more than likely the libva/intel bug where they forgot > > to declare they were writing into the buffers. > > Good thing it's not related to general tearing issues. Do you have a pointer > to a bug report or preliminary patch I can apply in libva? We seem to have neglected the bug a bit, apologies. Carsten Mattner, since There were improvements pushed in kernel & libva that will benefit to your system, so please re-test with latest kernel & libva and mark as REOPENED if you can reproduce (and attach fresh gpu error dump & kernel log) and RESOLVED/* if you cannot reproduce. note: libva => https://github.com/01org/libva see also https://01.org/linuxmedia/
To avoid tearing in videos, xterms and browsers on anything newer than Sandybridge one has to turn on TearFree and also make use of vsync via a compositor like compton if they're not already using Wayland. What's more surprising is that DRI3 was advertised as tear free but it tears like fbcon and there's no TearFree option in DRI3 and compton's vsync isn't sufficient. This is a widespread issue and documented in distro wikis like Arch Linux extensively since those have users who don't run Kwin or Mutter with automatic compositing+vsync already enabled. To answer your question, yes the regression persists and it got worse with DRI3 and I have to stay with DRI2 until the general issue is fixed regardless of the specific GPU revision in the machine from the original bug post. On older GPU 945GM this doesn't happen. Same tearing happens with generic modesetting ddx and it behaves exactly like DRI3 in video-intel, all the way down to including different window maximing behavior in mpv. My gut feeling is that I'll be able to migrate to Xwayland sooner than this will be resolved since it exists in the new generic modesetting driver and the intel driver's dri3 mode, which are both new code (no SNA etc). I'm really sorry to report this.
*** Bug 72290 has been marked as a duplicate of this bug. ***
(In reply to Carsten Mattner from comment #11) > one has to turn on TearFree and also make use of vsync via a > compositor like compton if they're not already using Wayland After testing xf86-video-intel, generic modesetting driver and several Wayland compositors, I can say that a compositor to force vsync is not required to fix tearing. In fact, the only sure way to avoid tearing with Intel GPUs is xf86-video-intel's exclusive (not available in generic modesetting driver, or video-intel's glamor or dri3 mode) DRI2 TearFree feature. No compositor needed at all. FWIW, fbcon tears as well.
Starting compton as a compositor under generic modesetting or video-intel glamor/dri3 mode will actually cause more frequent tearing. So I can only suggest TearFree as a solution and advise against compton in either setup.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
xf86-video-intel's TearFree is the only reliable way right now. Also, if you use Weston long and hard enough, you can observe tearing with a Wayland compositor when tearing was one of the problems Wayland was supposed to fix once and for all. Related bugs include https://bugs.freedesktop.org/show_bug.cgi?id=98876 and https://bugs.freedesktop.org/show_bug.cgi?id=101827. I can imagine that tearing is less obvious to some users who consider it normal, especially given major distros moving to the modesetting ddx by default for a while now.
Martin, Chris, what are options here?
Closing this bug as works for me. TearFree works as intended/designed.
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.