On Tue, Jun 28, 2016 at 09:55:17AM +0100, Chris Wilson wrote: > On Mon, Jun 27, 2016 at 11:32:10AM +0100, Tvrtko Ursulin wrote: > > > > On 25/06/16 11:12, Chris Wilson wrote: > > >When waiting for an interrupt (waiting for the GPU to complete some > > >work), we know we are the single waiter for the GPU. We also know when > > > > You mean we know we were the first waiter, if we have been woken up? > > Or perhaps the single waiter for this request? (more or less, maybe > > close enough) Or also s/", we know we are/, and we know we are" ? > > Single waiter for the engine. s/and//; it follows from and is not > conditional. To be here we know we are the only piece of code performing > this check. There may be threads entering i915_wait_request that also > get to spin before adding themselves to the waitqueue, but of all waiters, > we are the only one allowed to spin on this engine. Changed to: When waiting for an interrupt (waiting for the engine to complete some work), we know we are the only waiter to be woken on this engine. We also know when the GPU has nearly completed our request (or at least started processing it), so after being woken and we detect that the GPU is active and working on our request, allow us the bottom-half (the first waiter who wakes up to handle checking the seqno after the interrupt) to spin for a very short while to reduce client latencies. The impact is minimal, there was an improvement to the realtime-vs-many clients case, but exporting the function proves useful later. However, it is tempting to adjust irq_seqno_barrier to include the spin. The problem is first ensuring that the "start-of-request" seqno is coherent as we use that as our basis for judging when it is ok to spin. If we could, spinning there could dramatically shorten some sleeps, and allow us to make the barriers more conservative to handle missed seqno writes on more platforms (all gen7+ are known to have the occasional issue, at least). -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
