On Wed, 23 Dec 2020 at 11:12, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Having recognised that we do not change the sibling until we schedule > out, we can then defer the decision to resubmit the virtual engine from > the unwind of the active queue to scheduling out of the virtual context. > This improves our resilence in virtual engine scheduling, and should > eliminate the rare cases of gem_exec_balance failing. > > By keeping the unwind order intact on the local engine, we can preserve > data dependency ordering while doing a preempt-to-busy pass until we > have determined the new ELSP. This means that if we try to timeslice > between a virtual engine and a data-dependent ordinary request, the pair > will maintain their relative ordering and we will avoid the > resubmission, cancelling the timeslicing until further change. > > The dilemma though is that we then may end up in a situation where the > 'demotion' of the virtual request to an ordinary request in the engine > queue results in filling the ELSP[] with virtual requests instead of > spreading the load across the engines. To compensate for this, we mark > each virtual request and refuse to resubmit a virtual request in the > secondary ELSP slots, thus forcing subsequent virtual requests to be > scheduled out after timeslicing. By delaying the decision until we > schedule out, we will avoid unnecessary resubmission. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2079 > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2098 > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
