Bug 96847 - TearFree breaks when playing back videos in Firefox with GPU accelerated windows enabled in Firefox
Summary: TearFree breaks when playing back videos in Firefox with GPU accelerated wind...
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-07 14:25 UTC by N. W.
Modified: 2017-09-01 01:58 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (18.27 KB, text/plain)
2016-07-07 16:14 UTC, N. W.
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description N. W. 2016-07-07 14:25:18 UTC
Hi,

running Xubuntu 16.04 on a Core i7-6700K here.

There's a lot of tearing by default. But when setting up the following xorg conf file:

/etc/X11/xorg.conf.d/20-intel.conf

with the following contents:

Section "Device"
 Identifier "Intel Graphics"
 Driver     "intel"
 Option     "AccelMethod" "sna"
 Option     "DRI" "3"
 Option     "SwapbuffersWait" "true"
 Option     "TripleBuffer" "true"
 Option     "TearFree" "true"
EndSection

the tearing is gone.

TearFree is working fine.

But when enabling GPU accelerated windows in Firefox 47 via setting "layers.acceleration.force-enabled" to "true" in about:config (https://bugzilla.mozilla.org/show_bug.cgi?id=594876), and then watching a video on YouTube for example, TearFree suddenly seems to break after a short amount of time.

There suddenly is tearing again when moving windows around for example.

The tearing also does not go away when closing Firefox.

After rebooting, TearFree is working again (until playing back a video in Firefox again).

Any chance you could fix that?

Regards
Comment 1 Chris Wilson 2016-07-07 15:37:14 UTC
Please note that DRI3 overrides TearFree, since the client is given direct access to the scanout there is nothing the driver can do (until the client relinquishes control of the scanout).
Comment 2 Chris Wilson 2016-07-07 15:39:27 UTC
As regards to any particular problem, first attach Xorg.0.log and double check with xf86-video-intel.git. If you can compile with ./configure --enable-debug that should help catch the easiest problems (in particular losing tracking of DRI3/TearFree switch-over).
Comment 3 N. W. 2016-07-07 16:14:39 UTC
Created attachment 124946 [details]
Xorg.0.log
Comment 4 N. W. 2016-07-07 16:15:49 UTC
(In reply to Chris Wilson from comment #1)
> Please note that DRI3 overrides TearFree

Funny, I had already asked about this before but nobody replied, see: https://bugs.freedesktop.org/show_bug.cgi?id=37686#c124.

Also, are you absolutely sure about that?

Because even with:

Option "DRI" "3"

Xorg.0.log says:

[    16.253] (**) intel(0): TearFree enabled

So it seems like TearFree can be enabled even when DRI3 is enabled.

Also, when enabling DRI3 and leaving TearFree disabled, there's still tearing. So why should DRI3 override TearFree when DRI3 itself does not provide a tear free experience?

(In reply to Chris Wilson from comment #1)
> since the client is given direct
> access to the scanout there is nothing the driver can do (until the client
> relinquishes control of the scanout).

Well, I've also tried it with DRI2 via:

Option "DRI" "2"

but the issue is the same.

(In reply to Chris Wilson from comment #2)
> first attach Xorg.0.log

Attached:

https://bugs.freedesktop.org/attachment.cgi?id=124946

(In reply to Chris Wilson from comment #2)
> double
> check with xf86-video-intel.git. If you can compile with ./configure
> --enable-debug that should help catch the easiest problems (in particular
> losing tracking of DRI3/TearFree switch-over).

Is it really necessary to compile xf86-video-intel with a custom build option to be able to get a verbose (debug) log? Or what does --enable-debug do?

By the way, if you want to reproduce the issue:

As far as I can tell, the issue is triggered by switching the YouTube video player to fullscreen.

Regards
Comment 5 Chris Wilson 2016-07-07 19:52:57 UTC
(In reply to nw9165-3201 from comment #4)
> (In reply to Chris Wilson from comment #1)
> > Please note that DRI3 overrides TearFree
> 
> Funny, I had already asked about this before but nobody replied, see:
> https://bugs.freedesktop.org/show_bug.cgi?id=37686#c124.
> 
> Also, are you absolutely sure about that?

Absolutely, since I wrote the code, I had to explicitly disable TearFree when PresentPixmap is called because a client calling PresentPixmap can then treat that Pixmap as a front buffer and directly render into it bypassing X.

> Because even with:
> 
> Option "DRI" "3"
> 
> Xorg.0.log says:
> 
> [    16.253] (**) intel(0): TearFree enabled
> 
> So it seems like TearFree can be enabled even when DRI3 is enabled.
> 
> Also, when enabling DRI3 and leaving TearFree disabled, there's still
> tearing. So why should DRI3 override TearFree when DRI3 itself does not
> provide a tear free experience?

Who said that DRI3 was meant to provide a TearFree experience? That's not what we put together in the specification or the code. Also note that DRI3 *cannot* provide TearFree updates in a variety of configurations and due to many limitations in the current implementation is often inferior to DRI2 (such as multi-monitor rendering).

> (In reply to Chris Wilson from comment #1)
> > since the client is given direct
> > access to the scanout there is nothing the driver can do (until the client
> > relinquishes control of the scanout).
> 
> Well, I've also tried it with DRI2 via:
> 
> Option "DRI" "2"
> 
> but the issue is the same.
> 
> (In reply to Chris Wilson from comment #2)
> > first attach Xorg.0.log
> 
> Attached:
> 
> https://bugs.freedesktop.org/attachment.cgi?id=124946
> 
> (In reply to Chris Wilson from comment #2)
> > double
> > check with xf86-video-intel.git. If you can compile with ./configure
> > --enable-debug that should help catch the easiest problems (in particular
> > losing tracking of DRI3/TearFree switch-over).
> 
> Is it really necessary to compile xf86-video-intel with a custom build
> option to be able to get a verbose (debug) log? Or what does --enable-debug
> do?

Yes. Doing so does 2 things; verify that you know how to build and apply patches; and secondly it enables extra assertions and many runtime checks that could be handled without crashing and instead causes X to crash instead.

> By the way, if you want to reproduce the issue:
> 
> As far as I can tell, the issue is triggered by switching the YouTube video
> player to fullscreen.

Worksforme.
Comment 6 N. W. 2016-07-07 21:25:22 UTC
(In reply to Chris Wilson from comment #5)
> Absolutely, since I wrote the code, I had to explicitly disable TearFree
> when PresentPixmap is called because a client calling PresentPixmap can then
> treat that Pixmap as a front buffer and directly render into it bypassing X.

Maybe it should be noted in the man page then?

> > By the way, if you want to reproduce the issue:
> > 
> > As far as I can tell, the issue is triggered by switching the YouTube video
> > player to fullscreen.
> 
> Worksforme.

Have you set "layers.acceleration.force-enabled" to "true" in about:config (https://bugzilla.mozilla.org/show_bug.cgi?id=594876) in Firefox?

You need to enable it to trigger the issue. I just recently came across this setting ("layers.acceleration.force-enabled"), and when I enabled it, I noticed that TearFree breakup. Setting "layers.acceleration.force-enabled" to "true" results in a much better Firefox performance, especially on videos.

By the way, when the issue occurs, the video doesn't tear. But when moving windows around on the screen, you can notice some tearing on the windows, which usually is not there.

> Who said that DRI3 was meant to provide a TearFree experience? That's not
> what we put together in the specification or the code. Also note that DRI3
> *cannot* provide TearFree updates in a variety of configurations

But could you please explain to me why DRI=3 + TearFree=False is resulting in tearing, whereas DRI=3 + TearFree=True is resulting in no tearing? Surely TearFree must be doing something in that case?

> and due to
> many limitations in the current implementation is often inferior to DRI2
> (such as multi-monitor rendering).

Hm, yet even Intel has DRI3 enabled by default in Clear Linux and it also appears to provide better performance:

http://www.phoronix.com/scan.php?page=article&item=clear-ubuntu-fedxf&num=1
http://www.phoronix.com/scan.php?page=article&item=intel-skylake-dri3&num=1
http://www.phoronix.com/scan.php?page=news_item&px=DRI3-Xubuntu-16.04-Extra

Regards
Comment 7 N. W. 2016-07-08 16:16:25 UTC
Update:

Actually, when using DRI=2 + TearFree=True, TearFree does not break upon playing back a video in fullscreen.

However, with DRI2, there are strange artifacts covering half of the screen when having the YouTube video player in fullscreen. Those artifacts are covering half of the screen. But not the top or bottom half of the screen. It's actually the lower right corner of the screen, pretty much diagonally separated from the upper left corner of the screen.

The artifacts are only there when the YouTube video player is in fullscreen. When it's not in fullscreen, they are not there.

Already updated from Firefox 47 to Firefox Nightly, but that did not solve the issue.

And when using DRI=3 + TearFree=True, those artifacts do not appear, but TearFree actually breaks when playing back a video in fullscreen.

I know you've said DRI=3 + TearFree=True is not possible, but that seems like such a conflicting information, because TearFree=True actually removes the tearing that is otherwise happening with DRI3. And unless you play back a video in YouTube in fullscreen, TearFree seems to be working just fine with DRI3.
Comment 8 N. W. 2016-07-09 11:59:18 UTC
I've updated to xf86-video-intel 2.99.917+git1607041932.26f8ab (which seems to be the latest git version) via the Oibaf PPA now, which has also updated Mesa and so on, see:

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers?field.series_filter=xenial

And I have also updated to Kernel 4.6.3 now via the Ubuntu Mainline Kernel PPA, see:

https://wiki.ubuntu.com/Kernel/MainlineBuilds

Also updated to latest Firefox nightly via:

https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa

But everyting is still the same:

DRI=3 + TearFree=True results in breakup of TearFree when playing back video in fullscreen on YouTube for example.

DRI=2 + TearFree=True does not break up TearFree, but results in visible artifacts when playing back video in fullscreen on YouTube for example.

How can I check if xf86-video-intel from Oibaf PPA was built with ./configure --enable-debug?

Regards
Comment 9 N. W. 2016-11-12 22:49:19 UTC
Any update?
Comment 10 Dimitris 2016-12-09 17:04:16 UTC
Hi, I had a similar problem with 6700k in i3wm after enabling the TearFree option. The artifacts appeared in fullscreen youtube videos as well as any window that went into full screen mode.

By adding the option 

Option      "AccelMethod"  "uxa"

now i have no tearing and no artifacts.

Hope this helps even a bit pinpoint the problem and help other people with this problem.

cheers
Comment 11 N. W. 2016-12-09 19:05:01 UTC
Since none of the Intel employees are responding to this issue, I have now uninstalled xf86-video-intel and have switched to xf86-video-modesetting + Compton (compton --paint-on-overlay --backend=glx --glx-swap-method=buffer-age, as suggested by https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/911776-amdgpu-radeon-ddx-updated-better-2d-performance-tear-free-dri3-default?p=914343#post914343 ).

With this setup, tearing is gone, it's much smoother than with xf86-video-intel + TearFree.

xf86-video-intel has been abandoned by various distros anyway now (in favor of xf86-video-modesetting, which is included in xorg-server):

http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX

The only thing which is not so nice about the xf86-video-modesetting + Compton setup is the fact that there is some input lag.

When left clicking on a window title bar and holding down the left mouse button and moving the mouse to move the window, the mouse cursor is moving faster than the window, which makes the window movement (and with it the input) feel laggy. The moving window is lagging behind the moving mouse cursor. But that's more an issue of Compton rather than xf86-video-modesetting. And at least there's no more tearing.
Comment 12 N. W. 2017-02-28 19:02:08 UTC
(In reply to Chris Wilson from comment #1)
> Please note that DRI3 overrides TearFree, since the client is given direct
> access to the scanout there is nothing the driver can do (until the client
> relinquishes control of the scanout).

Apparently an AMD dev disagrees with you, see:

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/933036-tearfree-dri3

Are you sill sure about what you've said?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.