I've been thinking a little bit about DMA scheduling for the graphics
hardware.
Currently we have a situation where any 3d app which happens to be
able to grab the DRI lock can enqueue as many commands on the hardware
dma queue as it sees fit. The Linux scheduler is the only arbiter
between
On Thu, 2006-03-16 at 16:52, Keith Whitwell wrote:
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
Xavier Bestel wrote:
On Thu, 2006-03-16 at 16:52, Keith Whitwell wrote:
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
Am Donnerstag, den 16.03.2006, 15:52 + schrieb Keith Whitwell:
I've been thinking a little bit about DMA scheduling for the graphics
hardware.
Currently we have a situation where any 3d app which happens to be
able to grab the DRI lock can enqueue as many commands on the hardware
dma
On Thursday 16 March 2006 14:03, Felix Kühling wrote:
Am Donnerstag, den 16.03.2006, 15:52 + 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.
to one unified
memory manager that is (hopefully) going to be used by all drivers?
Regards,
Felix
Am Donnerstag, den 16.03.2006, 15:52 + schrieb Keith Whitwell:
I've been thinking a little bit about DMA scheduling for the graphics
hardware.
Currently we have a situation where any 3d
