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