Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > 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. We need to get rid of the absolute indexing inside spin handles at some point. But not today. Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
