[Intel-gfx] About dealing with CSB.context element switch in execlist mode.

[Wang, Zhi A]

Another question about EXECLIST is: Can a preemption happen between element switch?

I know this is beyond the scope of i915 a little. I'm just curious if it's possible.

Let's say we have context A B C

At first, we submit context A B in one ELSP write.
Then, we submit context C in another ELSP write at some time.

If context A or B is running and gets preempted, then there will be CSB.preempted in CSB buffer. This is the normal behavior.

I'm wondering that if there is any possibility that a preemption can happen between the two elements.

Then the CSB should look like:

[CSB 0 idle-to-active] 
[CSB 1 CTX A element_switch/context_complete] 
[CSB 2 CTX C active-to-idle/context_complete]

Is it possible?

Thanks,
Zhi.

> -----Original Message-----
> From: Thierry, Michel
> Sent: Wednesday, November 25, 2015 8:48 PM
> To: Wang, Zhi A; intel-gfx at lists.freedesktop.org
> Cc: Han, Xu; Li, Weinan Z; He, Min
> Subject: Re: [Intel-gfx] About dealing with CSB.context element switch in
> execlist mode.
> 
> 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