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