Re: [PATCH v6 00/34] GPU scheduler for i915 driver

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Apr 25, 2016 at 10:54:27AM +0100, Chris Wilson wrote:
> > As each batch buffer completes, it raises an interrupt which wakes up
> > the scheduler. Note that it is possible for multiple buffers to
> > complete before the IRQ handler gets to run. Further, the seqno values
> > of the individual buffers are not necessary incrementing as the
> > scheduler may have re-ordered their submission. However, the scheduler
> > keeps the list of executing buffers in order of hardware submission.
> > Thus it can scan through the list until a matching seqno is found and
> > then mark all in flight nodes from that point on as completed.
> 
> No. You haven't built your timelines correctly. The idea behind the
> timeline is that a request can wait upon its seqno and check it against
> its own timeline, which is ordered only with other requests on its
> timeline. Because of this, it is independent of whatever order the
> scheduler executes the timelines in, each timeline is ordered.
> 
> A request can simply wait for its timeline to advance, completely
> ignorant of the scheduler. (Request signaling may be driven by the
> scheduler, but that is a lowlevel, not GEM or dma-buf/fence,
> implementation detail. And only if the scheduler is coupled into the
> user-interupt, but on execlists it will be using the context-switch
> interrupt to driver itself, and for ringbuffer mode we have a choice of
> user-interrupt or using pipe-control/dw-notify to keep the paths
> separate.)

This is rather crucial, since that expectations that other drivers can
rely on fence->seqno being ordered correctly within one timeline. And e.g.
amdgpu does what Chris describes and collapses fences on one timeline to
just one.

We do have to fix this before we can enable the scheduler.

The related issues with using struct fence (request) more is that we need
that also for android integration. On mutli-gpu desktops we already have
different kinds of fences, but real soon we'll also have different kinds
of fences (gem requests and kms vblank/flip complete events) on just one
gpu, and on android.

[more cut]

> At the fundamental level it looks like you have not introduced timelines
> correctly or introduced the scheduler as a separate entity for deciding
> which request to execute next (or if this request should preempt execution).

Reworking the scheduler to take request and in-fences, and correctly use
timelines is definitely the way to go.

/me out

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