[igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting

[Chris Wilson]

Quoting Mika Kuoppala (2019-11-05 11:46:53)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > Quoting Mika Kuoppala (2019-11-05 11:34:23)
> >> Chris Wilson <chris at chris-wilson.co.uk> writes:
> >> 
> >> > As the scratch buf is shared between the two requests on both engines,
> >> > we need to wait for both to finish using the buffer before we reset it.
> >> >
> >> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> >> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >> > ---
> >> >  tests/i915/gem_exec_balancer.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> >> > index e52f5df95..70c4529b4 100644
> >> > --- a/tests/i915/gem_exec_balancer.c
> >> > +++ b/tests/i915/gem_exec_balancer.c
> >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915)
> >> >                       gem_execbuf(i915, &eb);
> >> >                       close(eb.rsvd2);
> >> >  
> >> > -                     gem_sync(i915, obj[2].handle);
> >> > +                     gem_sync(i915, obj[0].handle);
> >> 
> >> Ok, let me try to make sense of it all. First off, the need for
> >> obj[IGT_SPIN_SCRATCH].handle grows.
> >> 
> >> But as the semaphore will wait the spinner to start and then end it.
> >> It is not enough to wait the semaphore batch to sync. That is clear.
> >
> > It should be enough to wait for the spinner completion to be sure that
> > the semaphore batch is past the point of no return (but not necessarily
> > complete as it may be preempted before we mark it as complete). So it
> > would be possible for us to see the context still in flight and reduce
> > the randomness of our selection.
> >  
> >> But on syncing the scratch: the obj[1].handle is causing write
> >> hazard to obj[0] so if we wait obj[0], then it is implied that
> >> obj[1].handle has finished?
> >
> > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle
> > has two fences (from both batches), likewise obj[1].handle. So if you
> > wait on either obj[0].handle or obj[1].handle, you flush both fences.
> 
> We need to get rid of the absolute indexing inside spin handles
> at some point. But not today.

Yeah, right :-p
-Chris