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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
