On Mon, Nov 14, 2016 at 11:31:11AM +0000, Tvrtko Ursulin wrote: > > On 14/11/2016 08:57, Chris Wilson wrote: > >This emulates execlists on top of the GuC in order to defer submission of > >requests to the hardware. This deferral allows time for high priority > >requests to gazump their way to the head of the queue, however it nerfs > >the GuC by converting it back into a simple execlist (where the CPU has > >to wake up after every request to feed new commands into the GuC). > > Don't know what to do with this one. It feels like it should be a > separate patch so it can be performance evaluated properly? Yes. It is not clear if this is the right approach for the guc, since the firmware may have other ideas on how to do scheduling. It is an interesting thought experiment into how easy it would be to add scheduling on top! > It is also not clear to me why we don't need any similar limiting > for the execlists request merging? This uses exactly the same merging strategy as execlists (with the exception of not supporting gvt's single request dispatch), so we should be merging a ringfill of requests from one context if available. Which of course has it's downsides wrt to scheduling latency without preemption, and I'm not if there is even a right answer without preemption + timeslicing - the choice is more or less merge everything, or merge nothing, so we stick with the status quo of merge everything until proven otherwise. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
