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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
