[Intel-gfx] [PATCH] drm/i915: s/seqno/request/ tracking inside objects

Chris Wilson chris at chris-wilson.co.uk
Tue Jul 29 08:53:05 CEST 2014


On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
> > +static void
> > +i915_gem_object_retire(struct drm_i915_gem_object *obj)
> > +{
> > +	struct i915_gem_request *rq;
> > +	int i;
> > +
> > +	if (!obj->active)
> > +		return;
> > +
> > +	rq = obj->last_write.request;
> > +	if (rq && i915_request_complete(rq, true))
> > +		i915_gem_object_retire__write(obj);
> > +
> > +	rq = obj->last_fence.request;
> > +	if (rq && i915_request_complete(rq, true))
> > +		i915_gem_object_retire__fence(obj);
> > +
> > +	for (i = 0; i < I915_NUM_RINGS; i++) {
> > +		rq = obj->last_read[i].request;
> > +		if (rq && i915_request_complete(rq, true))
> > +			i915_gem_object_retire__read(obj, rq->ring);
> > +	}
> > +}
> 
> Unrelated comment on GEM in general: it seems like the callers of this
> all use it after they've waited on the object; maybe it should just
> be called from wait_rendering() to avoid any potential trouble?  The
> name is a bit ambiguous; it could be taken to mean that it does the
> idling.

No. There be dragons. Quite a few of the (indirect) callers of
wait_rendering() cannot handle the recursive freeing of requests/objects
and so we must carefully inspect each caller.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list