Re: About dealing with CSB.context element switch in execlist mode.

[Michel Thierry <michel.thierry@intel.com>]

On 11/24/2015 1:33 PM, Wang, Zhi A wrote:
> Hi Gurus:
>
> I’m wondering what’s the right approach to deal with the context switch
> reason: element_switch? According to b-spec, one ELSP submission may
> include two elements, when one element is finished, HW will move to
> process next element, the previous context will be scheduled out with a
> “element_switch” context switch reason.

Correct, in fact you get 2 flags, element_switch & context_complete.

>
> I saw that i915 would try to start a new ELSP write which may contain
> two new elements when it found a “element_switch” CSB in the context
> switch handler. I’m a bit confused here, as HW may be still running a
> context at this time, I’m not sure if two new elements can be submitted
> at this time. So I think maybe my understanding about this context
> switch reason might be wrong.

The driver is trying to speed up the execution when there are +3 
contexts queued. The first _new_ element you mention is in fact the 
running context.

>
> Anyone can educate me how to deal with the “element_switch” CSB?
>

Let's say you have contexts A, B, C and D already in queue, so A & B are 
sent to the ELSP.

After element_switch (A completed) B starts automatically, at this point 
the driver will send a new execlist with B and C, effectively 
lite-restoring B (note it cannot be a different context since that will 
cause a preemption).

And when B completes, the driver sends C & D. Lite-restoring the 2nd ctx 
of each execlist allows us to send these 4 contexts with only 3 ELSP writes.

> Thanks,
>
> Zhi.
>
-Michel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx