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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
