Bug 92018 - DPMS blanking breaks Intel TearFree
Summary: DPMS blanking breaks Intel TearFree
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2015-09-16 07:25 UTC by Das
Modified: 2015-10-26 12:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Xorg.0.log (27.64 KB, text/plain)
2015-09-17 08:14 UTC, Das
no flags Details
Always progess the shadow buffer after redisplay (1.91 KB, patch)
2015-10-25 15:45 UTC, Chris Wilson
no flags Details | Splinter Review
Always flag the shadow buffer after resetting it fr DPMS on (2.64 KB, patch)
2015-10-26 11:47 UTC, Chris Wilson
no flags Details | Splinter Review

Description Das 2015-09-16 07:25:25 UTC
Hey guys

When recovering from DPMS screen blanking, TearFree in my xorg configuration doesn't seem to have any effect anymore. 

xf86-video-intel = 2.99.917+381+g5772556-1 on Haswell refresh
mesa = 10.6.7

How to reproduce

1. Enable TearFree: https://wiki.archlinux.org/index.php/Intel_graphics#Tear-free_video
2. Restart X and enjoy no tearing
3. Run: xset dpms force off
4. Resume from blanking
5. Enjoy your broken TearFree/tearing
Comment 1 Chris Wilson 2015-09-16 12:17:33 UTC
Please attach your Xorg.0.log.
Comment 2 Das 2015-09-17 08:14:43 UTC
Created attachment 118323 [details]

Added the Xorg log. This happens with both UXA and SNA
Comment 3 Das 2015-09-17 08:27:11 UTC
If it helps: If I disable TearFree and enable compton with the glx backend, I get no tearing after unblanking

Also, the tearing seems to be most noticeable in firefox, with smooth scrolling on
Comment 4 Chris Wilson 2015-09-17 12:16:30 UTC
It should be that the only way TearFree fails is when it is disabled by some allocation failure, or a failure whilst flipping. The latter is permanent (since the kernel is upset and we have no reason to expect it to recover) and logged (notable by its absence in the attached!). The former should be transient, and only noted in the debug logs. If you have the patience, recompiling with ./autogen.sh --enable-debug=full and attaching the massive Xorg.0.log following the failure would be very useful.
Comment 5 dimon 2015-10-25 11:35:30 UTC
I'm having the same issue, see xorg.log with debugging enabled.
Comment 6 Chris Wilson 2015-10-25 15:45:41 UTC
Created attachment 119186 [details] [review]
Always progess the shadow buffer after redisplay

Thanks, I can see what the problem is, just need to think carefully about the ramifications. The attached should help, but at the very least it is treating the symptom rather than the cause.
Comment 7 Chris Wilson 2015-10-26 11:47:54 UTC
Created attachment 119198 [details] [review]
Always flag the shadow buffer after resetting it fr DPMS on

This should be the real fix!
Comment 8 dimon 2015-10-26 12:28:32 UTC
Thanks Chris, it works.
Comment 9 Chris Wilson 2015-10-26 12:48:35 UTC
And thanks for the bug report and feedback.

commit be3748802398a741208715233d36935378ceff58
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Oct 25 15:41:10 2015 +0000

    sna: Always flag the shadow buffer after resetting it fr DPMS on
    When switching the outputs back on, we show the current front buffer and
    so for TearFree we always then need to flag the front buffer as active.
    Failing to do so left us rendering straight onto the scanout, defeating
    the notion of TearFree.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92018
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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.