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

[Mika Kuoppala]

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.

Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>

> -Chris