Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
Ian Romanick wrote: 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
On Sul, 2004-05-09 at 14:32, Jon Smirl wrote: I would like to see a single device drver always controlling the GPU and VRAM/AGP memory management. Then it is easy to switch graphics contexts on VT swap. VRAM/AGP most of the time can probably be a generic library but yes I agree, and at times the AGP stuff has to deal with at least two or four heads sharing AGP space, which is another argument for it being clearly controlled in one spot. --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
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. I would like to see a single device drver always controlling the GPU and VRAM/AGP memory management. Then it is easy to switch graphics contexts on VT swap. --- Alan Cox [EMAIL PROTECTED] wrote: 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.. --- 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 ___ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
Alan Cox wrote: 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
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. 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
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. 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? --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
On Sun, May 09, 2004 at 08:14:59PM -0700, Ian Romanick wrote: | ... 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? Most aren't, but I hear that because of Longhorn, all the next-generation cards are. As far as this functionality goes, we're right on the cusp, so the software architecture is tricky. Allen --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
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.. --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get It not's the graphics cards that are being hotplugged, it's other cards in the system. If xfree hasn't coordinated with the kernel, the kernel hotplug code could easily map the new hardware right on top of the Xfree HW. This doesn't sound like a huge problem, XFree could simply inform the kernel about what it has done, or use a kernel api to do the mappings for it. It doesn't seem to require moving the driver to kernel space. Keith --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
On Thu, 6 May 2004, Keith Whitwell wrote: Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get It not's the graphics cards that are being hotplugged, it's other cards in the system. If xfree hasn't coordinated with the kernel, the kernel hotplug code could easily map the new hardware right on top of the Xfree HW. This doesn't sound like a huge problem, XFree could simply inform the kernel about what it has done, or use a kernel api to do the mappings for it. It doesn't seem to require moving the driver to kernel space. One problem that I encountered is that DRM driver does not know how to reinitialize video mode in case of a lockup. So it would be real nice to have DRM and FB merged so that a failed WaitForIdle could reinit the hardware and call FB mode setting code to restore video mode. Thus this part of 2d driver *wants* to be inside the kernel. As far as acceleration - either 2d or 3d - it makes sense for it to stay in userspace.. best Vladimir Dergachev Keith --- 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 --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
--- Vladimir Dergachev [EMAIL PROTECTED] wrote: As far as acceleration - either 2d or 3d - it makes sense for it to stay in userspace. X and everything else needs to stop mapping the registers to user space and instead start using an IOCTL interface to a driver. The problem is that X or whatever sets a bunch of register values. Then a VT swap happens and something else writes all over those register values. The kernel driver is needed to track this state and restore it on VT swap. 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. We can tell everyone to implement save/restore functions for VT swap. But the save/restore function for DRM is going to have to save all of the registers, VRAM, AGP space, coprocessor state, etc. This is a huge amount of state to save. It is much better to have a common driver. With a common driver the state save/restore problem goes away. Timesharing device drivers on the graphics hardware at VT swap is a very broken design. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- 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
