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] Memory management of AGP and VRAM
Can you run grub or lilo on these machines? Also, these is no rule saying a device driver can't have several tables of _init register values that can be used to set the mode on a primary monitor at boot. I would just like to see all of the code that does DDC decoding and modeline computations moved to user space. When you add up that code there is about 40K of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers start probing for multiple heads, TV support, etc that code is going to get even larger. Since the code is used only rarely (in kernel terms) this code should be in user space instead of the driver. I've also proposed that if you really, really want to you could do the DDC probing the in driver at boot and mark all of the code _init. Then the user space code would take over after that. Note that I'm talking about early userspace (initrd) timeframe, not normal user space. --- Ian Romanick [EMAIL PROTECTED] wrote: Egbert Eich wrote: However chipset probing/display device probing and mode setting isn't required to live in kernel space. Portability and system stability arguments speak against it. In fact only Apple MAC users seem to advocate this idea to be able to an initial video mode on their systems. Allow me to speak up for users of IBM pSeries hardware or Sun SPARC hardware. Users of those systems face exactly the same issues as Mac users. I imagine most embedded systems will be in the same boat. Being forced to use a serial console for early boot messages is so 1980's. ;) The kernel doesn't need to have support for everything, but I think it's important to have at least minimal support. --- 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] Memory management of AGP and VRAM
Holger Waechtler wrote: Jon Smirl wrote: Can you run grub or lilo on these machines? The equivalent loader is called MILO for SPARC and Yaboot for PowerPC. oops -- the SPARC image loader was called SILO. MILO was the mini image loader for Alpha. sorry for confusion, 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] Memory management of AGP and VRAM
Jon Smirl wrote: Can you run grub or lilo on these machines? The equivalent loader is called MILO for SPARC and Yaboot for PowerPC. The BIOS equivalent is called OpenFirmware and provides a helper API for mode setting and graphics card initialisation. There are comments in the drivers which mark other than the default modes as TODO (e.g. 'these are somewhat sane defaults for Mac boards, we will need to find a good way of getting these from OpenFirmware'), I don't know whether they are rooted in missing docs or in technical troubles communicating with the OpenFirmware. 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: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
1) Keep mode switching in the kernel. Merge DRI and fb together via sysfs interface. 2) Ben suggestion that we mount userland inside the kernel during early boot and use a userland library. If we would use a library then it MUST be OpenGL. This would be the forced standard on all platforms. This would mean Mesa would be needed to build the kernel. We could move over Mesa into the kernel like zlib is in the tree right now. You are mixing things. Mode setting has nothing to do with rendering. OpenGL is a rendering client. It produces commands sent to the low level kernel driver and provides a 3D API, but it's not the only one. In this regard, fbcon is a client too and XFree 2D accel is another one. What I was proposing was a library that managed the desktop environment, not involved in any rendering activities. The main reason why I halted my work on this (except for lack of time) is that I figured out that there were big issues to solve first about memory management of the framebuffer, dealing with ownership of fb regions, ability to ask client to evict their data (when a new mode requires a larger space) etc... Ben. --- 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
