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: [Dri-devel] new API/DRM/fb discsusion..
On Iau, 2004-05-06 at 18:57, Jens Owen wrote: If mmapping is okay, then we're still able to touch hardware from user space drivers. I'm fine with that. Basically the kernel needs to know you are working with the frame buffer, and it needs to be able to revoke that from under you on a hot unplug (so you don't scribble onto a new device). Alternatively it can not reuse the space until you close it, but again it needs to know when you close use of it. --- 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
[Dri-devel] new API/DRM/fb discsusion..
why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: [Dri-devel] new API/DRM/fb discsusion..
Another request is that this work be compared to the kgi work so that we don't repeat the same mistakes. I wasn't around for that debate, can someone explain what was learned from attempt? I'll start reworking the proposal to include the feedback I have so far and get it ready for the next round. I suspect the next round on the DRI/FB lists will generate a lot more flames. The graphic driver issue is heating up because MS Longhorn is focusing on accelerated graphics as a major feature. --- Dave Airlie [EMAIL PROTECTED] wrote: why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 = 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: [Dri-devel] new API/DRM/fb discsusion..
Jon, This issue of whether or not to use kgi goes all the way back to design decisions we made in 1998. Based on my recollection, I believe these were the top issues: 1) kgi was Linux specific. We needed a kernel level module that was more portable. 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. These are the issues I remember from 1998. I'm sure our requirements have evolved since then, but hopefully this short list will give a little insight into our thinking at that time. Jon Smirl wrote: Another request is that this work be compared to the kgi work so that we don't repeat the same mistakes. I wasn't around for that debate, can someone explain what was learned from attempt? I'll start reworking the proposal to include the feedback I have so far and get it ready for the next round. I suspect the next round on the DRI/FB lists will generate a lot more flames. The graphic driver issue is heating up because MS Longhorn is focusing on accelerated graphics as a major feature. --- Dave Airlie [EMAIL PROTECTED] wrote: why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 = 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 -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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: [Dri-devel] new API/DRM/fb discsusion..
On Thu, 6 May 2004, Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. Linux kernel people are strongly in favor of changing Xfree to never touch the hardware except through device drivers. I have to agree with that, Xfree is doing a lot of things that are never going to work in a hotplug system. The only way to make hotplug work is for Xfree to tell the kernel what it is doing. Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. Top proposal right now is to merge FB and DRM. FB has the GPL license with too many developers so it probably can't be converted to BSD. I would imagine that parts of fb and drm would need to be rewritten to accomodate new requirements. What about making new interfaces LGPL - this should work fine with both GPL and non-GPL software ? There are many advatanges to merging FB/DRM. Top ones include SAK, secure attention key, kdbg support, OOPS while X is running, mode support for mesa-solo, etc I would be delighted to have km functionality (GATOS capture module) merged into DRM/FB combination. best Vladimir Dergachev What is the state of the FB equivalent on BSD? = 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 --- 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: [Dri-devel] new API/DRM/fb discsusion..
John, You can think of me as Old School, and take my feedback in that context. My main reason for participating in this discussion is to give some historical perspective. Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. Linux kernel people are strongly in favor of changing Xfree to never touch the hardware except through device drivers. I have to agree with that, Xfree is doing a lot of things that are never going to work in a hotplug system. The only way to make hotplug work is for Xfree to tell the kernel what it is doing. 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 a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. Top proposal right now is to merge FB and DRM. FB has the GPL license with too many developers so it probably can't be converted to BSD. There are many advatanges to merging FB/DRM. Top ones include SAK, secure attention key, kdbg support, OOPS while X is running, mode support for mesa-solo, etc I guess it really just depends on who your target user base is for your architecture. I'm a strong supporter of open source, especially at the infrastructure level; but I have a pragmatic view of IHV's and their need (or perceived need) to withold sources at the module level. If you're not targetting an all inclusive base of IHV's and kernels, then life is much easier for you, and you don't have to worry about the licensing issue. What is the state of the FB equivalent on BSD? It's certainly further along than it was in 1998, but I'm not the right person to ask. If you don't make any progress on their kernel lists, contact me directly, and I can put you in touch with my BSD contacts. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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: [Dri-devel] new API/DRM/fb discsusion..
Around 9 o'clock on May 6, Jens Owen wrote: If you would like to get a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. I had the impression that this architecture would continue to permit the frame buffer to be mapped into user space. -keith pgp0.pgp Description: PGP signature
Re: [Dri-devel] new API/DRM/fb discsusion..
--- 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. a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. Framebuffer access follows the rules; kernel calls are used to map it into user space. The major violations in X are in PCI bus and graphics chip probing. BTW, the mesa-solo radeon driver does not map the framebuffer from the driver or user space. = 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: [Dri-devel] new API/DRM/fb discsusion..
Jon Smirl wrote: Framebuffer access follows the rules; kernel calls are used to map it into user space. The major violations in X are in PCI bus and graphics chip probing. If mmapping is okay, then we're still able to touch hardware from user space drivers. I'm fine with that. I don't see any problem with requiring probing to be handled by a kernel space driver, especially since this isn't done a performance critical times. BTW, the mesa-solo radeon driver does not map the framebuffer from the driver or user space. The original radeon Mesa Subset driver that Keith W. wrote didn't have any software fallbacks. If you re-enable a full Mesa driver, I think you'll find it very challenging to support all the necessary software fallbacks without a memory map of the framebuffer...but luckly it doesn't sound like memory mapping the device is a problem. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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: [Dri-devel] new API/DRM/fb discsusion..
Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: [Dri-devel] new API/DRM/fb discsusion..
Martin Spott wrote: Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? I doubt it. Even if it was, this isn't the list for making that decision. 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: [Dri-devel] new API/DRM/fb discsusion..
On Thu, 6 May 2004, Martin Spott wrote: Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? No, no, I was simply speaking from personal perspective. For example, a couple of years ago I was making a specific effort to make my code as much user-space as possible, just for portability sake, but I decided to stop doing it. Writing drivers for Linux is involving enough and if no stupid architecture decisions are made the port to Hurd or BSD should not be too difficult. best Vladimir Dergachev Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
