Bug 109618 - TearFree stops working at random with DRI3, works fine with DRI2
Summary: TearFree stops working at random with DRI3, works fine with DRI2
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: lowest normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-13 01:19 UTC by Sultan Alsawaf
Modified: 2019-07-07 07:43 UTC (History)
3 users (show)

See Also:
i915 platform: BSW/CHT, CFL, KBL
i915 features: display/Other


Attachments
Xorg config info (33.20 KB, text/x-log)
2019-02-13 01:19 UTC, Sultan Alsawaf
no flags Details
Dmesg with TearFree broken (113.66 KB, text/plain)
2019-02-13 17:16 UTC, Sultan Alsawaf
no flags Details
DRM max debug dmesg (2.49 MB, text/plain)
2019-02-14 10:11 UTC, Sultan Alsawaf
no flags Details
xf86-video-intel max debug log (22.27 MB, text/x-log)
2019-02-14 10:32 UTC, Sultan Alsawaf
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sultan Alsawaf 2019-02-13 01:19:29 UTC
Created attachment 143369 [details]
Xorg config info

On multiple different Intel machines running Arch Linux, the TearFree option works great but it randomly stops working completely and requires a xorg restart to make it work again. I haven't observed any log messages produced when TearFree stops working. Running an application in full-screen mode (such as watching a YouTube video in full-screen mode) seems to be the most frequent way to reproduce the issue.

When TearFree stops working, it is graceful and the only indication that it has stopped working is that vsync tearing is suddenly present. I have experienced this issue intermittently for several months, so it's likely not a (recent) regression. This issue is noticeable to me because I don't use a window manager to smooth out vsync tearing, and instead rely on the TearFree feature to do so.

Any suggestions on how to go about collecting debugging information for this? I've attached a xorg log that contains information about my system/configuration but nothing remarkable about this bug itself.
Comment 1 Chris Wilson 2019-02-13 08:41:11 UTC
Your Xorg log will be complaining about a pageflip/modeset failing, but you will need to enable drm.debug=0xe to find out what -- in all likelihood the problem stems from the kernel.
Comment 2 Chris Wilson 2019-02-13 13:53:29 UTC
Fwiw, it should try to re-enable TearFree after a modeset (or VT switch) iirc.
Comment 3 Sultan Alsawaf 2019-02-13 17:16:29 UTC
Created attachment 143372 [details]
Dmesg with TearFree broken

Here's what appeared in dmesg at the time TearFree stopped working:
[   40.623699] [drm:drm_mode_addfb2 [drm]] [FB:99]
[   47.605365] [drm:drm_mode_addfb2 [drm]] [FB:102]
[   59.111051] [drm:drm_mode_addfb2 [drm]] [FB:102]
[   62.602841] [drm:intel_power_well_disable [i915]] disabling DC off
[   62.602893] [drm:gen9_dc_off_power_well_disable [i915]] Enabling DC6
[   62.602942] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
[   63.545157] [drm:intel_power_well_enable [i915]] enabling DC off
[   63.545224] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00
[   66.937268] [drm:drm_mode_addfb2 [drm]] [FB:98]
[   78.235814] [drm:drm_mode_addfb2 [drm]] [FB:99]
[   80.167855] [drm:drm_mode_addfb2 [drm]] [FB:103]
[   80.186272] [drm:drm_mode_addfb2 [drm]] [FB:105]
[   80.205084] [drm:drm_mode_addfb2 [drm]] [FB:106]
[   83.387359] [drm:drm_mode_addfb2 [drm]] [FB:103]
[   83.405156] [drm:drm_mode_addfb2 [drm]] [FB:105]
[   83.421814] [drm:drm_mode_addfb2 [drm]] [FB:106]

I've attached the full dmesg. Also, it turns out it is extremely easy to reproduce this by just toggling full-screen mode on/off on a YouTube video in Chromium.
Comment 4 Sultan Alsawaf 2019-02-13 17:20:14 UTC
In fact, simply full-screening any YouTube video in Chromium once is enough to break TearFree. This doesn't seem to be the case with Firefox though.
Comment 5 Chris Wilson 2019-02-14 10:04:09 UTC
Oh well, drm.debug=0xe wasn't enough; try drm.debug=0xfe (and if you are quick or have a long log buffer, drm.debug=0xff).
Comment 6 Sultan Alsawaf 2019-02-14 10:11:33 UTC
Created attachment 143376 [details]
DRM max debug dmesg

Here's a dmesg with 0xff.
Comment 7 Chris Wilson 2019-02-14 10:19:20 UTC
The last flip wasn't reported as a failure -- just to check that corresponds with maximising Chromium and tearing? There is a fun bit, in the presence of DRI3, it is allowed to take over control of the frontbuffer (because it's meant to be flipping) but that does allow clients to render into scanout and that might just be the case.

If you recompile xf86-video-intel with --enable-debug=full, there will be a lot of information (largely noise) about what the clients are doing and what TearFree is up to.
Comment 8 Sultan Alsawaf 2019-02-14 10:32:44 UTC
Created attachment 143377 [details]
xf86-video-intel max debug log

That sequence of events in that dmesg are as follows:
dmesg -c
maximize video in Chromium
minimize video in Chromium
dmesg > log.txt

I've attached a log with xf86-video-intel with full debugging.
Comment 9 Sultan Alsawaf 2019-02-16 20:10:04 UTC
(In reply to Chris Wilson from comment #7)
> The last flip wasn't reported as a failure -- just to check that corresponds
> with maximising Chromium and tearing? There is a fun bit, in the presence of
> DRI3, it is allowed to take over control of the frontbuffer (because it's
> meant to be flipping) but that does allow clients to render into scanout and
> that might just be the case.
> 
> If you recompile xf86-video-intel with --enable-debug=full, there will be a
> lot of information (largely noise) about what the clients are doing and what
> TearFree is up to.

As you suspected, the issue is not present with DRI2; it only occurs with DRI3.
Comment 10 Sultan Alsawaf 2019-03-20 19:02:16 UTC
There hasn't been any update here for a while. This issue still exists; could someone take a look at it?
Comment 11 Lakshmi 2019-03-21 08:28:24 UTC
(In reply to Sultan Alsawaf from comment #10)
> There hasn't been any update here for a while. This issue still exists;
> could someone take a look at it?

Which particular platform is this?
Comment 12 Sultan Alsawaf 2019-03-21 15:46:49 UTC
(In reply to Lakshmi from comment #11)
> Which particular platform is this?

I have reproduced this on an i7-8750H, i7-8550U, and an N3160. I can reliably reproduce the issue by opening a YouTube video in fullscreen in Chromium.
Comment 13 Lakshmi 2019-06-26 10:36:19 UTC
@Martin, Any help to make some progress with this bug would be appreciated.
Comment 14 Martin Peres 2019-07-02 07:33:27 UTC
Hi Sultan,

What is the mean time before failure of this? Are you seeing the failure minutes after starting the X server, or days?

Unfortunately, the xf86-video-intel driver is considered legacy, and the xf86-video-modesetting driver does not yet have tearfree support (although I am trying to get this fixed). Since you are not using any composited windowing manager (which are tear free thanks to the pageflip support), using DRI2 should not cause any regression in functionality and would be a valid workaround until I get around to landing the tearfree support in xf86-video-modesetting.

Please tell me if I missed anything!
Comment 15 Sultan Alsawaf 2019-07-02 08:06:32 UTC
Hi Martin,

This issue occurs immediately when I maximize a video in Chromium, and it doesn't disappear until I restart X.

I am indeed using DRI2 for the meantime, and I'm on the xf86-video-intel driver because the modesetting driver wasn't so stable for me last I tried it :-)

It's nice having tear-free graphics without the overhead of a composited window manager; I've found even the "lightest" of composited window managers to be more resource-heavy (and buggy!) than I'm willing to bear, so I am a huge fan of the TearFree feature.
Comment 16 Martin Peres 2019-07-07 07:43:43 UTC
(In reply to Sultan Alsawaf from comment #15)
> Hi Martin,
> 
> This issue occurs immediately when I maximize a video in Chromium, and it
> doesn't disappear until I restart X.

Thanks for the information!

> 
> I am indeed using DRI2 for the meantime, and I'm on the xf86-video-intel
> driver because the modesetting driver wasn't so stable for me last I tried
> it :-)

Interesting, when was that?

> 
> It's nice having tear-free graphics without the overhead of a composited
> window manager; I've found even the "lightest" of composited window managers
> to be more resource-heavy (and buggy!) than I'm willing to bear, so I am a
> huge fan of the TearFree feature.

I get your point. This is why I have invested some time to implement TearFree on modesetting (not done yet). However, for me, one of the most important advantage of not running with a compositor is the lower latency... but the tearfree feature goes against that. X11 is just not meant for provide a low-latency tear-free environment.

Have you considered using sway by the way? This should be extremely light, tearfree and stable.


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.