Quoting Tvrtko Ursulin (2017-12-20 12:35:31) > > On 20/12/2017 10:49, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-12-20 09:45:41) > >> > >> On 19/12/2017 21:45, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2017-12-19 15:45:42) > >>>> From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>>> > >>>> Rather than calibrate and emit nop batches, use a manually signalled chain > >>>> of spinners to generate the desired interrupts. > >>>> > >>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>>> --- > >>>> - /* Unplug the calibrated queue and wait for all the fences */ > >>>> - igt_spin_batch_free(gem_fd, spin); > >>>> - igt_assert_eq(poll(&pfd, 1, 2 * test_duration_ms), 1); > >>>> - close(pfd.fd); > >>>> + pfd.fd = spin[i]->out_fence; > >>>> + igt_spin_batch_set_timeout(spin[i], timeout_ms * 1e6); > >>>> + igt_assert_eq(poll(&pfd, 1, 2 * timeout_ms), 1); > >>> > >>> Oh, still with the synchronous behaviour, bleurgh. > >> > >> I was attracted by the simplicity of this approach, but I can change to > >> set incremental timeouts and keep the merged fence if you think that's > >> better? > > > > It was mostly surprise as I just have a preference for setting up > > everything and then letting it go; fire-and-forget style. So that was > > what I was expecting to see. It should basically be the difference of > > adding a single function to merge the fences (albeit you have to write > > that function). Shall we say both patterns have merit / analogues to the > > real world? > > It is using fence merging approach so it won't be a problem to keep > that, just with the spin batches. I mostly wanted to remove calibration > since you were nudging me in that direction. Don't mind really of the > specific mechanics of emitting interrupts so I am happy to go back a step. I was thinking how difficult would it be to run twice; once batched and once sync? We're more likely to catch discrepancies in our interrupt generation that way, which may or may not help improve the test in future. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
