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
