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).

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).

Created attachment 124946 [details]
Xorg.0.log

(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

(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.

(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

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.

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

Any update?

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

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.

(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?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/119.