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.
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.
Fwiw, it should try to re-enable TearFree after a modeset (or VT switch) iirc.
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.
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.
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).
Created attachment 143376 [details] DRM max debug dmesg Here's a dmesg with 0xff.
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.
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.
(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.
There hasn't been any update here for a while. This issue still exists; could someone take a look at it?
(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?
(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.
@Martin, Any help to make some progress with this bug would be appreciated.
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!
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.
(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.
-- 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/drm/intel/issues/229.
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.