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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
