[Intel-gfx] [PATCH i-g-t 5/7] tests/perf_pmu: Tests for i915 PMU API

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-10-09 11:32:21)
> 
> On 26/09/2017 12:42, Chris Wilson wrote:
> 
> [snip]
> 
> >>> I'm still at a loss as to why this test is interesting. You want to say
> >>> that given an idle engine with a single batch there is no time spent
> >>> waiting for an MI event, nor waiting on a semaphore. Where is that
> >>> guaranteed? What happens if we do need to do such a pre-batch + sync in
> >>> the future. If you wanted to say that whilst the batch is executing that
> >>> no time is spent processing requests the batch isn't making, then maybe.
> >>> But without a test to demonstrate the opposite, we still have no idea if
> >>> the counters work.
> >>
> >> Yeah, I am still at a stage of punting off the semaphore work to after
> >> the rest is polished. Need to nose around some tests and see if I can
> >> lift some code involving semaphores.
> > 
> > Bug 54226, it's a classic :) Not a test, but the overlay showed the
> > breakage quite clearly.
> > 
> > Hmm, we should be able to do WAIT on any platform, since it's just MI
> > instructions - but the setup may differ between platform. I would use
> > wait-for-event, rather than scanline.
> 
> I cannot get this to work. Looking at the docs the wait for vblank 
> looked like a good candidate to me.
> 
> So I am creating a batch with MI_WAIT_FOR_EVENT | 
> MI_WAIT_FOR_PIPE_A_VBLANK. Pipe A is confirmed active and with a mode. 
> But the command seems to hang there. :(
> 
> Ironically PMU does report the correct time spent in wait once the GPU 
> reset kicks the client off.
> 
> Any ideas?

Did you queue a vblank (drmWaitVblank)? We don't enable the vblank irq
until we need it, either for a modeset or vblank-wait. drmWaitVblank()
is more explicit in that regard.

You also will need to unmask the event in DERRMR and acquire fw.
Something like:

	MI_LOAD_REGISTER_IMM | 3;
	0x44050; /* DERRMR */
	~event;
	0xa188; /* FORCEWAKE_MT */
	2 << 16 | 2; /* BIT(1) == userspace */

and undo afterwards.

> > Hmm, I wonder if MI_SEMAPHORE_WAIT | POLL asserts the RING_CTL
> > semaphore bit. I hope it does, then not only do we have a simple test,
> > but the counter is useful for VkEvent.
> 
> This seems to work. I am waiting on a value in a shared bo, and then 
> update the value via a WC mmap. Engine proceeds and I check the PMU. All 
> good.

That's good news! Since learning about VkEvent using MI_SEMAPHORE_WAIT
form userspace, it's been on my worrylist. Now we should be able to
measure if it becomes a problem.
-Chris