[Intel-gfx] [PATCH v3 12/14] drm/i915/guc: Preemption! With GuC

Chris Wilson chris at chris-wilson.co.uk
Wed Oct 25 18:15:16 UTC 2017


Quoting MichaƂ Winiarski (2017-10-19 19:36:17)
> Pretty similar to what we have on execlists.
> We're reusing most of the GEM code, however, due to GuC quirks we need a
> couple of extra bits.
> Preemption is implemented as GuC action, and actions can be pretty slow.
> Because of that, we're using a mutex to serialize them. Since we're
> requesting preemption from the tasklet, the task of creating a workitem
> and wrapping it in GuC action is delegated to a worker.
> 
> To distinguish that preemption has finished, we're using additional
> piece of HWSP, and since we're not getting context switch interrupts,
> we're also adding a user interrupt.
> 
> The fact that our special preempt context has completed unfortunately
> doesn't mean that we're ready to submit new work. We also need to wait
> for GuC to finish its own processing.

Should we be concerned about the latency of a preemption switch here?
For execlists the impact on a stress test like whisper/contexts-priority
it is barely noticeable, the same cannot be said here.

Hmm, I guess I need to amend gem_exec_latency to include a measurement.
And benchmarks/ needs some TLC. Not that I really expect it to show up
at e.g. the GL client level, but one day someone may care enough to
complain; better to be prepared.
-Chris


More information about the Intel-gfx mailing list