[Intel-gfx] [PATCH 07/62] drm/i915/gt: Resubmit the virtual engine on schedule-out
Matthew Auld
matthew.william.auld at gmail.com
Thu Dec 24 13:49:46 UTC 2020
On Wed, 23 Dec 2020 at 11:12, Chris Wilson <chris at 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 <chris at chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
Reviewed-by: Matthew Auld <matthew.auld at intel.com>
More information about the Intel-gfx
mailing list