[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