[Bug 105720] screen corruption using SNA and TearFree on Intel GeminiLake

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105720

--- Comment #12 from Chris Wilson <chris at chris-wilson.co.uk> ---
Created attachment 138363
  --> https://bugs.freedesktop.org/attachment.cgi?id=138363&action=edit
Ratelimit per-CRTC updates without TearFree

So looking at the code, the easiest way to buffer output onto the CRTC is via
Option "PerCRTCPixmap". We can replace Option "TearFree" (or force Option
"NoTearFree") with the attached as a rough approximation to scheduling the
screen update via vblank (v.rough, it definitely does not prevent tearing!),
and it definitely feels heavier than TearFree (presumably due to the
synchronisation on the extra forced copy).

Testing on bdw/skl showed no sign of the "blank screen", but there's a fishy
!rr_active() in the middle of initialising the crtc pixmap that needs double
checking (I suspect that actually should be if !(flags & TEAR_FREE)) and may be
the cause of the delayed init.

Option "PerCRTCPixmap" + Option "TearFree" should work together, that's akin to
triple buffering, as the CRTC flips are double buffered with the ScreenPixmap
being the third copy as rendered to by the clients. Without the feedback loop,
it should be impervious to the accumulation of dirt, but it may still exhibit
the wrong buffer syndrome (if the event accounting is completely skewiff), e.g.
glxgears going backwards.

The drawback is that at best it should instill an extra frame of input-output
latency, and at worst that latency may jitter.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180326/df661c41/attachment.html>