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