Quoting Chris Wilson (2020-05-14 17:54:36)
> The virtual timeslicing failed under a series of unfortunate slices.
> Suppose the user submitted a virtual request, over [vcs0, vcs1] and also
> a request that dependent upon the result of the virtal request to vcs0.
>
> submit {veng, vcs0}
> time slice expires: unsubmit vcs0, veng
> submit { vcs0 } # no timeslicing
> virtual tasklet requeues veng
>
> veng saw that it was still in flight on vcs0 and did not queue onto
> vcs1, and on vcs0 it saw no reason to preempt the active request.
>
> Patch "drm/i915/gt: Kick virtual siblings on timeslice out" fixes not
> waking up the siblings after timeslicing, and patch "drm/i915/gt:
> Incorporate the virtual engine into timeslicing" fixes the issue of not
> restarting timeslicing after the replacement of veng.
>
> After applying those patches, we should then expire the timeslice on
> vcs0 and resubmit {veng, vcs0} and reschedule the timeslices. Repeating
> the sequence until the veng finally completes. Our usual strategy to
> recognise the data dependent timeslicing is to notice the resubmission
> of the same pair of requests, and so skip the ELSP write, leaving them
> executing on the HW. (This will also then disable the timeslicing until
> either completes or we see a new request.)
>
> In order for the virtual request to be resubmitted immediately after
> expiring the timeslice, we need to ensure that we make the virtual
> engine immediately available again for submission in this execlists
> tasklet.
Of course Tvrtko has examples where mixing load-balanced with explicit
engine requests requires us to migrate on timeslice expiry. I hear the
death nails being driven into the
> - while (rb) { /* XXX virtual is always taking precedence */
> - struct virtual_engine *ve =
> - rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
> + /* XXX virtual is always taking precedence */
> + while ((ve = first_virtual_engine(engine))) {
coffin.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
