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

Daniel Vetter
2014-06-17T09:17:44Z

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