On 28/06/16 10:17, Chris Wilson wrote:
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).
Super clear now;
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
