[Intel-gfx] [PATCH 3/3] drm/i915: add fences to the request struct

Chris Wilson chris at chris-wilson.co.uk
Thu Dec 4 03:29:23 PST 2014


On Thu, Dec 04, 2014 at 12:05:34PM +0100, Daniel Vetter wrote:
> On Thu, Dec 04, 2014 at 09:13:21AM +0000, Chris Wilson wrote:
> > On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote:
> > > This simplifies the sync code quite a bit.  I don't think we'll be able
> > > to get away with using the core fence code's seqno support, since we'll
> > > be moving away from simple seqno comparisions with the scheduler and
> > > preemption, but the additional code is pretty minimal anyway, and lets
> > > us add additional debugging as needed, so it's probably fine to keep
> > > either way.
> > > 
> > > We still need to add support for other rings here; we ought to be able
> > > to do that with the timeline field of the ioctl (which will include
> > > other "rings" like the display flip queue for example).
> > 
> > I am ambivalent about this. I don't think migrating i915_request over to
> > use the heavyweight fence primitives is a good idea, so see little value
> > in embedding the struct fence inside i915_request vs a small bookkeeping
> > struct referencing i915_request.
> 
> Which part of struct fence is too heavyweight? And I guess we could always
> add a slab or some cache if the allocation overhead is too much. I really
> like this conceptually so if there's a concern with overhead I want solid
> data for it.

It uses locked atomic operations, which are unnecessary for the very
frequent is-complete checks (due to the nice ordering constraints of x86).

You have me confused. You keep applying patches without solid data to
back up your claims.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list