[Intel-gfx] [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing

[Daniel Vetter]

On Tue, Jun 17, 2014 at 11:42 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Yes, having s/flip/flush/ is preferrable from a consistency pov. I am
> just not yet sold on that setplane is a intel_fb_flush. I think the busy
> state tracking on the new fb is distinct from the state tracking on the
> old fb, and we are marking the transition from one fb to the other. I
> would rather keep the invalidate/flush as boundaries on the current fb,
> with the distinction made for change of fb.

Well my idea is that on every flip all old frontbuffer rendering can
be ignored and so we should have an unconditional flush of any
invalidations. And at least on modern hw (pre-g4x fbc is different)
the hw works for purely flip based screen updates already. Well,
except for sprites on hsw with psr.

So currently I don't see a need for a distinct flip type of event.
This might chance once we have single-shot upload for psr/dsi cmd
mode. But then I think that's better done as part of the magic and
all-encompassing nuclear pageflip. We have a bunch of opens in that
area still which are all similar, e.g. enabling ips with a 1 vblank
delay, or disabling fbc 1 vblank before disabling the primary plane.
Getting that all correct and async will be work, and my gut says most
of it won't fit into this fb tracking scheme which is centered around
catching frontbuffer rendering.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch