On Iau, 2004-05-06 at 20:57, Jon Smirl wrote:
Simple example, DRM starts GPU coprocessor running. VT swap happens. New user stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor running but that's not true now. DRM and FB conflict when FB is using the coprocessor for accelerated text.
FB already has mode switch context waits, so does DRM. And you don't want to break direct access to registers for most things because its a performance consideration of high importance.
Timesharing device drivers on the graphics hardware at VT swap is a very broken design.
Read Mark Kilgards SGI papers - they were doing context management at scheduling level..
fine-grained GPU timesharing is required in any case for fully programmable GPUs - especially for the ones which allow infinite looping and thus can lock up if not programmed correctly.
A scheduler either needs to run on the GPU or you need a way to interrupt the GPU and switch contexts between GPU programs at any time from the host processor OS to allow concurrent access to the GPU by different on- and offscreen rendering processes.
If done properly you can even use your GPU for more general numerics as described e.g. by the gpgpu folks: http://www.gpgpu.org/ using the offscreen memory while your GL applications render into their windows and the windowing system repaints it's window stack at the same time.
Holger
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
