[Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch

[Chris Wilson]

Quoting Antonio Argenziano (2018-08-16 18:42:17)
> 
> 
> On 16/08/18 00:08, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-16 00:59:30)
> >>
> >>
> >> On 15/08/18 10:24, Chris Wilson wrote:
> >>> Quoting Antonio Argenziano (2018-08-15 18:20:10)
> >>>>
> >>>>
> >>>> On 15/08/18 03:26, Chris Wilson wrote:
> >>>>> Quoting Antonio Argenziano (2018-08-15 00:50:43)
> >>>>>>
> >>>>>>
> >>>>>> On 10/08/18 04:01, Chris Wilson wrote:
> >>>>>>> This exercises a special case that may be of interest, waiting for a
> >>>>>>> context that may be preempted in order to reduce the wait.
> >>>>>>>
> >>>>>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>>>>>> ---
> >>>>>>> +             cycles = 0;
> >>>>>>> +             elapsed = 0;
> >>>>>>> +             start = gettime();
> >>>>>>> +             do {
> >>>>>>> +                     do {
> >>>>>>> +                             double this;
> >>>>>>> +
> >>>>>>> +                             gem_execbuf(fd, &contexts[0].execbuf);
> >>>>>>> +                             gem_execbuf(fd, &contexts[1].execbuf);
> >>>>>>
> >>>>>> I'm not sure where the preemption, mentioned in the commit message, is
> >>>>>> coming in.
> >>>>>
> >>>>> Internally. I've suggested that we reorder equivalent contexts in order
> >>>>> to satisfy client waits earlier. So having created two independent
> >>>>> request queues, userspace should be oblivious to the execution order.
> >>>>
> >>>> But there isn't an assert because you don't want that to be part of the
> >>>> contract between the driver and userspace, is that correct?
> >>>
> >>> Correct. Userspace hasn't specified an order between the two contexts so
> >>> can't actually assert it happens in a particular order. We are free then
> >>> to do whatever we like, but that also means no assertion. Just the
> >>> figures look pretty and ofc we have to check that nothing actually
> >>> breaks.
> >>
> >> The last question I have is about the batches, why not choosing a spin
> >> batch so to make sure that context[0] (and [1]) hasn't completed by the
> >> time it starts waiting.
> > 
> > It would be exercising fewer possibilities. Not that it would be any
> > less valid. (If I can't do a pair of trivial execbuf faster than the gpu
> > can execute a no-op from idle, shoot me. Each execbuf will take ~500ns,
> > the gpu will take 20-50us [bdw-kbl] to execute the first batch from idle.)
> 
> It would generate some odd looking numbers anyways.

It would give an indirect measure of preemption latency. I think we have
a slightly better measure via gem_exec_latency, but it's an interesting
variation at least. Certainly deserves to be in the magic cookbook of
the ultimate microbenchmarks.

Too much magic, not enough casting, alas.
-Chris