Holger Waechtler wrote:
Jon Smirl wrote:
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.
There's still a crap-ton more state than just which vertex/fragment programs are running. Even the vp/fp state is more than the traditional register file, stack pointer, IP, etc.
Shader program and shader program state variables are located in (graphics card) memory, you only need to save the GPU register set at context switch.
I'm not even convinced that current GPUs allow the kind of "happy" task swapping that's being discussed. I very seriously doubt that you can halt and restart an in-progress shader. That would require extra logic, reduce performance, and wouldn't help games. What makes you think any of the current cards are designed to do this?
:) Think of high-end processors like the SGI Reality Engine 2, this one allows to upload compiled C microcode, the current high-end ATI and nVidia processor families follow roughly the same path, their shader instruction sets contain loop and jump flow control instructions. As soon you have a processor that can get misprogrammed so that it runs into an infinite loop you need a way to interrupt it from the host and to upload new code or switch to another shader task.
It's kind of hard to distinguish a long-running complicated shader program from a hanging buggy one in a general way - at the end that decision is up to the client application that generated the code, but a single misbehaving application that is allowed to hang the graphics subsystem entirely is probably not really considered a good thing...
Considering papers like [1] and [2] it seems not unlikely that vendors will continue to develop in this direction and make their processors even more general so that the uploaded GPU programs can also generate geometry topology on the fly and tesselate geometry patches on the GPU - the high-end processors can do it right now, so the consumer products will probably follow soonish.
Holger
[1] "Fast Rendering of Subdivision Surfaces", Pulli, Segal, http://graphics.stanford.edu/~kapu/sd/subdegwr.pdf
[2] "Mesh Mutation in Programmable Graphics Hardware", Shiue, Goel, Peters, http://www.cise.ufl.edu/research/SurfLab/MiPGH.pdf
-------------------------------------------------------
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
