Sharing graphics contexts is not the same thing as allowing two completely different device drivers access to the hardware on VT swap. Two different device drivers may have completely different contents in all of the registers, CP running or not, VRAM and AGP space. With two device drivers you have to completely save state of the GPU, VRAM and AGP at VT swap in order to be safe.
don't know whether the imagination of a register-controlled graphics peripheral with hundrets of control registers is still valid for a fully programmable modern GPU.
I'd rather think of it like you think of a conventional SIMD-processor, a context switch between different shader programs looks probably more like a process context switch of a classic CPU than a VT switch of older graphics cards.
Since you can express all classic 2D and fixed-pipeline 3D operations in vertex and pixel shader programs there is no real need anymore for those huge register files controlling the graphics accelerator, instead you jump between the shader programs that replace your old fixed-function logic.
Maybe the GPU BIOSes already emulate VESA functions by special GPU programs in the graphics card's ROM, but this pure guessing. On the long term they'll probably do -- every fixed-function logic just costs chip area and is basically redundant with the functionality provided by the GPU.
I would like to see a single device drver always controlling the GPU and VRAM/AGP memory management.
It's maybe the only way to implement real scheduling.
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
