On Thu, Apr 28, 2016 at 07:15:23PM +0100, Dave Gordon wrote: > On 28/04/16 09:56, Chris Wilson wrote: > >As the contexts are accessed by the hardware until the switch is completed > >to a new context, the hardware may still be writing to the context object > >after the breadcrumb is visible. We must not unpin/unbind/prune that > >object whilst still active and so we keep the previous context pinned until > >the following request. We can generalise the tracking we already do via > >the engine->last_context and move it to the request so that it works > >equally for execlists and GuC. > > > >v2: Drop the execlists double pin as that exposes a race inside the lrc > >irq handler as it tries to access the context after it may be retired. > > > >Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> > >Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > >--- > > Hmmm .. not sure this is going to play well with request reordering > in the scheduler, or with preemption! I think it makes it a bit more > difficult; perhaps we will just have to clear it for all preempted > requests. This field is maintained by whoever queues the requests to hardware. It simplifies greatly the issue of tracking when the context is no longer being written to by hardware. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
