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
