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

Chris Wilson chris at chris-wilson.co.uk
Tue Nov 5 11:39:03 UTC 2019


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.
-Chris


More information about the igt-dev mailing list