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

[Chris Wilson]

On Tue, Jun 17, 2014 at 09:45:00AM +0200, Daniel Vetter wrote:
> On Tue, Jun 17, 2014 at 07:54:38AM +0100, Chris Wilson wrote:
> > On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> > > +/**
> > > + * intel_frontbuffer_flush - flush frontbuffer
> > > + * @dev: DRM device
> > > + * @frontbuffer_bits: frontbuffer plane tracking bits
> > > + *
> > > + * This function gets called every time rendering on the given planes has
> > > + * completed and frontbuffer caching can be started again. Flushes will get
> > > + * delayed if they're blocked by some oustanding asynchronous rendering.
> > > + *
> > > + * Can be called without any locks held.
> > > + */
> > > +void intel_frontbuffer_flush(struct drm_device *dev,
> > > +			     unsigned frontbuffer_bits)
> > 
> > intel_fb_complete.
> 
> My naming convetion was:
> - intel_frontbuffer: Deals in raw frontbuffer tracking bits.
> - intel_fb: Takes a gem object, assumes dev->struct_mutex is held. I've
>   stolen these from the intel_mark_fb_busy function.
> 
> The main functions are flush/invalidate, all the others just add a bit of
> magic (which delays) around them. Imo invalidate is definitely the right
> pick if you look at fbc/psr as fancy caches, not sure about flush. Maybe
> finish given our sw_finish ioctl, but not sure that's better than flush.
> My thinking is:
> 
> - invalidate the cache fully (i.e. disable it)
> - flush data into the cache again (i.e. enable it again)

That's also how I named it, so we agree here.

I am not fond of intermixing intel_frontbuffer and intel_fb though.
Certainly not having the function definitions intertwined.

Maybe intel_frontbuffer and intel_frontbuffer_obj?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre