On 01/12/15 15:58, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 03:47:34PM +0000, Dave Gordon wrote:
On 30/11/15 10:06, Tvrtko Ursulin wrote:
On 29/11/15 08:48, Chris Wilson wrote:
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
spin timeout and so we will just be wasting CPU cycles.
v2: Check for logical inversion when rebasing - we were incorrectly
checking for this request being active, and instead busywaiting for
when the GPU was not yet processing the request of interest.
v3: Try another colour for the seqno names.
v4: Another colour for the function names.
Adding a field in the request to track the sequence number of the
previous request isn't ideal when considering the scheduler and
preemption. But we've got a separate batch-in-progress sequence
number in the hardware status page (also for use by TDR to check
which batch is currently running), so you could use that. Then the
check is simply
As demonstrated TDR doesn't need it, and the GPU scheduler has to fix up
the seqno anyway to maintain retirement order of the request list.
-Chris
If the request list is in retirement order, then the previous-seqno of a
request is simply the seqno of the previous request in the request list.
If there isn't a previous request, then the request under consideration
is at the head of the list and must be the currently-active request
anyway (of course, the converse does not hold, due to lazy retirement
and such).
The scheduler will reassign seqnos as batches are submitted to the
backend submission mechanism (ringbuffer, execlist, or GuC), so they
will start out in order. But that doesn't guarantee in-order completion
once we add preemption, so we will in any case be tracking both the
start and finish of each batch.
The (Android) TDR previously worked on by Tomas Elf did make use of the
batch-started seqno; at least some of the enhancements in that version
of TDR are expected to be ported into the upstream Linux soon.
BTW I would find it easier to test & review these patches if they were
in a different order, specifically I'd prefer to see the infrastructure
updates (patches 9-12: lazy coherency, get rid of get_seqno(), etc)
before the features that they help simplify (spin-wait optimisation,
thundering herd suppression, etc).
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
