Quoting Mika Kuoppala (2019-11-05 11:46:53) > 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. Yeah, right :-p -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
