Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > --- > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
