[Intel-gfx] [PATCH] drm/i915: Do not add an interrupt for a context switch

[Chris Wilson]

On Thu, Aug 08, 2013 at 08:43:30AM +0200, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 1:25 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Thu, Aug 08, 2013 at 01:18:18AM +0200, Daniel Vetter wrote:
> >> Afaict the request holds a ref on the context, and that a ref on the hw
> >> context bo. But the active list itself (thanks to the move_to_active)
> >> should also hold a ref to the hw context bo, so I don't think we really
> >> need full request here. The old context might disappear, but no one really
> >> cares if it disappears a notch too early since the backing storage will
> >> survive long enough.
> >
> > The next request holds a ref to the new context. We care about holding a
> > ref to the old context until the hw has finished writing to it. That is
> > the purpose of taking a request here, to bump the old_ctx->bo->active
> > for the context save. Otherwise the backing storage is liable to disappear
> > too early (and the hw write to a random location).
> 
> Hm, I might be especially dense, but doesn't the
> i915_gem_object_move_to_active(from->obj, ring) call right above the
> add_request take care of exactly that, whether we have the request
> added or not? And anyone waiting for that object (e.g. the eviction
> code) will notice in check_olr that the request is missing, add it and
> then wait for it?

Yeah, I win this battle for being the most thick headed. The
move-to-active will indeed hold the active reference until the next
request which by definition will be after MI_SET_CONTEXT is executed. So
this here dummy request purely holds a context reference, which I agree
can disappear as soon as the user visible ref is dropped. In which case,
we do not even need the context reference in the request per-se, except
for error handling.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre