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

[Tvrtko Ursulin]

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?

> 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.

Regards,

Tvrtko