Quoting Mika Kuoppala (2019-11-05 11:34:23) > 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. 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
