On ti, 2017-02-14 at 11:44 +0000, 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). > > v2: Drop hack status - though iirc there is still a lockdep inversion > between fence and engine->timeline->lock (which is impossible as the > nesting only occurs on different fences - hopefully just requires some > judicious lockdep annotation) > v3: Apply lockdep nesting to enabling signaling on the request, using > the pattern we already have in __i915_gem_request_submit(); > v4: Replaying requests after a hang also now needs the timeline > spinlock, to disable the interrupts at least > v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal > v6: Reorder interrupt checking for a happier gcc. > v7: Only signal the tasklet after a user-interrupt if using guc scheduling > v8: Restore lost update of rq through the i915_guc_irq_handler (Tvrtko) > v9: Avoid re-initialising the engine->irq_tasklet from inside a reset > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
I already did, but here goes again; Acked-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx