[Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption

[Chris Wilson]

Quoting Chris Wilson (2019-09-20 17:03:34)
> Quoting Bloomfield, Jon (2019-09-20 16:50:57)
> > > -----Original Message-----
> > > From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of Tvrtko
> > > Ursulin
> > > Sent: Friday, September 20, 2019 8:12 AM
> > > To: Chris Wilson <chris at chris-wilson.co.uk>; intel-gfx at lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from
> > > overtaking each other on preemption
> > > 
> > > 
> > > On 20/09/2019 15:57, Chris Wilson wrote:
> > > > Quoting Chris Wilson (2019-09-20 09:36:24)
> > > >> Force bonded requests to run on distinct engines so that they cannot be
> > > >> shuffled onto the same engine where timeslicing will reverse the order.
> > > >> A bonded request will often wait on a semaphore signaled by its master,
> > > >> creating an implicit dependency -- if we ignore that implicit dependency
> > > >> and allow the bonded request to run on the same engine and before its
> > > >> master, we will cause a GPU hang.
> > > >
> > > > Thinking more, it should not directly cause a GPU hang, as the stuck request
> > > > should be timesliced away, and each preemption should be enough to keep
> > > > hangcheck at bay (though we have evidence it may not). So at best it runs
> > > > at half-speed, at worst a third (if my model is correct).
> > > 
> > > But I think it is still correct to do since we don't have the coupling
> > > information on re-submit. Hm.. but don't we need to prevent slave from
> > > changing engines as well?
> > 
> > Unless I'm missing something, the proposal here is to set the engines in stone at first submission, and never change them?
> 
> For submission here, think execution (submission to actual HW). (We have
> 2 separate phases that all like to be called submit()!)
s/2/3/
-Chris