Re: [PATCH v3 12/14] drm/i915/guc: Preemption! With GuC

[Chris Wilson <chris@chris-wilson.co.uk>]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx