DMA scheduling

[Adam Jackson]

On Thursday 16 March 2006 14:03, Felix Kühling wrote:
> Am Donnerstag, den 16.03.2006, 15:52 +0000 schrieb Keith Whitwell:
> > 1) Fairness.  We can currently have situations where one 3d
> >     applications manages to dominate the GPU while a second app in
> >     another window is locked out entirely.
> >
> > 2) Interactivity.  It is quite possible to have one application which
> >     does so little rendering per frame that it can run at 3000fps while
> >     another eg, video-based application does a lot more and can just
> >     about keep up a 30fps framerate.  Consider a situation where both
> >     applications are running at once.  Simple fairness criteria would
> >     have them running at 1500fps and 15fps respectively - but it seems
> >     that fairness isn't what is required here.  It would be preferable
> >     give the slower application a greater percentage of the GPU, so
> >     that it manages eg. 27fps, while the other is scaled down to "only"
> >     300fps or so.
> >
> >     Note that we currently don't even have the "fair" situation...
> >
> > 3) Resource management.  Imagine two applications each of which has a
> >     texture working set of 90% of the available video ram.  Even a
> >     smart replacement algorithm will end up thrashing if the
> >     applications are able to rapidly grab the DRI lock from each other
> >     and enqueue buffer loads and rendering.  A scheduler could
> >     recognize the thrashing and improve matters by giving each app a
> >     longer timeslice on the GPU to minimize texture reloads.
>
> 4) Latency. There are currently frame throttling hacks in place to limit
> the latency, or IOW how far the CPU can be ahead of the GPU. If the
> scheduler were to get involved in this activity it would not only
> schedule queued commands to the hardware but also throttle (block)
> clients whose command stream processing is too far behind.

5) Dispatch optimization.  When multiple buffers are enqueued from different 
clients, their dispatch could be ordered to minimize the cost of state 
emission between context switches.  For hardware with multiple contexts, this 
generalizes to picking the hw context to replace with the smallest switch 
cost vector.

6) Proper support for NV_fence / GL2_async_core / etc.

7) Greatly simplified support for swap groups and swap barriers.

Probably some other stuff I'm forgetting.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060316/c11a4d1a/attachment.pgp>