On Wed, 23 Dec 2020 at 11:12, Chris Wilson <ch...@chris-wilson.co.uk> 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 <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Reviewed-by: Matthew Auld <matthew.a...@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
