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

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Chris Wilson <chris@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@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@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.

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?

-Mika

>  		}
>  
>  		*stop = 1;
> -- 
> 2.24.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev