Quoting John Harrison (2019-01-22 22:18:46)
> On 1/21/2019 14:20, Chris Wilson wrote:
> > In order to avoid preempting ourselves, we currently refuse to schedule
> > the tasklet if we reschedule an inflight context. However, this glosses
> > over a few issues such as what happens after a CS completion event and
> > we then preempt the newly executing context with itself, or if something
> > else causes a tasklet_schedule triggering the same evaluation to
> > preempt the active context with itself.
> >
> > To avoid the extra complications, after deciding that we have
> > potentially queued a request with higher priority than the currently
> > executing request, inspect the head of the queue to see if it is indeed
> > higher priority from another context.
> >
> > References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current context")
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
>
> Can you explain what was wrong with the previous version of this patch
> (drm/i915/execlists: Store the highest priority context)? It seemed simpler.
The goal here is to be a more general suppression mechanism than the
first version. queue_priority is a hint and can't be trusted as we may
have set it for an inflight request since completed. Given that it tells
us that a preemption point _was_ required, but we don't want to forcibly
inject an idle barrier, we inspect the queue instead and not take the
hint at face value. In that light, queue_context is superfluous as we
ignore the ELSP[0] context anyway.
The patch is slightly bigger than it needed to be because I was
refactoring out some changes for later, and a bit of paranoid asserts
from debugging that didn't really belong in the bugfix.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
