Re: [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Jun 17, 2014 at 08:53:47AM +0100, Chris Wilson wrote:
> 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?

intel_fb_obj would be good for me since frontbuffer is awfully long and
leads to ugly code. But I agree that sprinkling obj in would be good, and
we have precedence for fb_obj with pin_and_fence.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch