Bug 93679 - [SNB] Heavy tearing with xf86-video-intel
Summary: [SNB] Heavy tearing with xf86-video-intel
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 72290 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-01-12 16:19 UTC by Carsten Mattner
Modified: 2018-09-07 12:31 UTC (History)
4 users (show)

See Also:
i915 platform: SNB
i915 features: display/watermark


Attachments
HD3000 Xorg.log (5.04 KB, text/plain)
2016-01-13 14:33 UTC, Carsten Mattner
no flags Details
HD3000 Xorg.log (5.04 KB, application/octet-stream)
2016-01-13 14:34 UTC, Carsten Mattner
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carsten Mattner 2016-01-12 16:19:38 UTC
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.
Comment 1 Chris Wilson 2016-01-12 16:57:15 UTC
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.
Comment 2 Carsten Mattner 2016-01-13 14:33:24 UTC
Created attachment 121000 [details]
HD3000 Xorg.log
Comment 3 Carsten Mattner 2016-01-13 14:34:20 UTC
Created attachment 121001 [details]
HD3000 Xorg.log
Comment 4 Carsten Mattner 2016-01-13 14:38:44 UTC
So I should not set SwapbuffersWait to "true" if I want it to vsync when needed. Is that right?
Comment 5 Chris Wilson 2016-01-13 15:20:56 UTC
(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.
Comment 6 Carsten Mattner 2016-01-20 15:48:38 UTC
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.
Comment 7 Chris Wilson 2016-01-24 12:02:19 UTC
(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.
Comment 8 Carsten Mattner 2016-01-25 11:17:45 UTC
> 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?
Comment 9 Pacho Ramos 2016-03-13 16:18:53 UTC
I am also suffering tearing issues but I commented at bug 72290 (this looks to me like a dupe of that bug :/)
Comment 10 yann 2017-03-16 15:59:03 UTC
(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/
Comment 11 Carsten Mattner 2017-03-17 22:10:25 UTC
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.
Comment 12 Elizabeth 2017-07-28 20:24:27 UTC
*** Bug 72290 has been marked as a duplicate of this bug. ***
Comment 13 Carsten Mattner 2017-10-12 19:06:55 UTC
(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.
Comment 14 Carsten Mattner 2017-10-12 19:08:18 UTC
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.
Comment 15 Jani Saarinen 2018-03-29 07:12:00 UTC
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.
Comment 16 Carsten Mattner 2018-03-29 17:16:53 UTC
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.
Comment 17 Jani Saarinen 2018-04-22 15:46:14 UTC
Martin, Chris, what are options here?
Comment 18 Lakshmi 2018-09-07 12:31:11 UTC
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.