Re: [PATCH 03/15] drm/i915: Only spin whilst waiting on the current request

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Dec 01, 2015 at 04:44:53PM +0000, Dave Gordon wrote:
> 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.

If the scheduler stops reassigning seqnos and instead hands out seqnos
per-ctx all these problems go away. And a metric pile more problems too
...

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx