Thanks for the explanation 2). :) I'm thinking about the rough design of preemption in GVT-g since host is moving to support preemption. 1) Global MMIO save/restore, which is covered by context status notifier. 2) Support host preemption. GVT-g request is preempted by host. Since this preemption is not expected by guest, GVT-g workload scheduler should keep it and re-schedule it. * GVT-g has to know if a context is scheduled-out or preempted here, it's better the context notification can explicitly report INTEL_CONTEXT_PREEMPTED. Or we have to get the information from context or request data structure. * Better the re-scheduling of GVT-g request can be controlled by GVT-g not i915, since GVT-g has its own scheduling policies. 3) Guest preemption. Guest requests a preemption by writing vELSP. GVT-g has to find a way to stop the previous GVT-g request if it's active on HW. If it's not active on HW, the request should be cancelled. * If host can expose such a APIs to cancel request in HW(by preemption) or in priotree for GVT-g , that would be nice. :) Thanks, Zhi. -----Original Message----- From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] Sent: Monday, September 25, 2017 9:39 PM To: Wang, Zhi A <zhi.a.wang@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx Cc: Winiarski, Michal <michal.winiarski@xxxxxxxxx>; Ursulin, Tvrtko <tvrtko.ursulin@xxxxxxxxx>; Hiler, Arkadiusz <arkadiusz.hiler@xxxxxxxxx>; Kuoppala, Mika <mika.kuoppala@xxxxxxxxx>; Widawsky, Benjamin <benjamin.widawsky@xxxxxxxxx>; Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx> Subject: RE: [PATCH 6/7] drm/i915/execlists: Preemption! Quoting Wang, Zhi A (2017-09-25 19:31:15) > Two ideas from me. :) > > 1) For GVT-g, can we have an execlist context status notification in lrc irq handler? Then we can switch back those MMIO registers for host in the handler if a GVT-g request is preempted. GVT-g is hosed with this patch if requires matching context-in, context-out notification. We broke that back in commit 221ab9719bf33ad2984928d2afb20988d652a289 Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Date: Sat Sep 16 21:44:14 2017 +0100 drm/i915/execlists: Unwind incomplete requests on resets The simple question is it ok to call context-out for the incomplete request when they are no longer being scheduler? > 2) Might need a flag to indicate if a request can be pre-emptible in GEM request. Flag set by whom? The big problem with flags on requests is that we get to coalesce requests into the context-switch. That makes tracking the individuals more complicated -- before deciding upon preemption you have to walk the list of all executing requests rather than just being able to check one. (execlists_schedule() with its list walking for PI is already one of the prime hotspots :( > It looks not every request can be preempted to me since previously I saw there were some HW WAs to disable preemption for specific drawing topologies by LRI to 0x2244 on some BDW stepping. > > I'm not sure if this kinds of stuff is still existing in SKL and will appear again in future. Also some execlist contexts of OCL workload needs to be patched if they got preempted. So UMD might be the guy which knows if the workload can be preempted. > Pulled in a couple of patches from Michal to setup the contexts for w/a. And Michal's suggestion is that we just skip enabling preemption for bdw/bsw. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
