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

[Chris Wilson]

On Tue, Jun 17, 2014 at 11:54:16AM +0200, Daniel Vetter wrote:
> 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.

But that would be a discard, a different type of beastie.

> 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.

Exactly, I'm trying to make the frontbuffer rendering tracker clean,
but I think you are conflating hw details with the tracking layer.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre