[Intel-gfx] [PATCH i-g-t 2/3] tests/perf_pmu: Simplify interrupt testing

[Chris Wilson]

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 at intel.com>
> >>>>
> >>>> 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 at intel.com>
> >>>> ---
> >>>> -       /* 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