Re: DGA - the future?
On Tue, 09 Mar 2004 09:40:07 -0800 Tim Roberts [EMAIL PROTECTED] wrote: James Wright wrote: It doesn't seem all that long ago that DGA V2 was added, why was it ever introduced if it causes grief for the driver writers? What where the original intentions of including the DGA extension into Xfree86? Same as DirectDraw in Windows. Some app writers want to own the desktop and draw directly onto the bits of the frame buffer. Both DirectDraw and DGA provide that access, and both of them are a pain for driver writers. It doesn't make them evil. Exactly, DGA is about the closest to DirectDraw we can get. I understand it must be a pain for the driver writers, but I wouldn't like to see DGA dropped for that reason alone. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
On Wed, 10 Mar 2004 17:48:24 +0900 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: no - i haven't measured it... BUT it isn't great. memory bandwidth isn't a big positive of these devices. i'm almost certain it is the memcpy and context switch as that really is the ONLY difference in the rendering code i have as all things are cpu rendered in rgba32 then down converted to screen depth - this is the point where it either gets converted direct to framebuffer (which incidentally lives within system memory like the i810 - stealing a little system ram and having the ramdac scan that), or if running in x, will get converted to an shm buffer, then context switch and have shm buffer copied to real fb. this copy is the only real difference :/ it's even worse with a shadow fb and portrait rotation! thus u prefer using my own code that can do the rotation while converting 32bpp to 16bpp and dithering :) I agree... Using our own code to write diirect to the framebuffer is by far the fastest method for our application. shmputimage is no replacement for that.. Its like saying a double decker bus is an adequate replacement for a Ferrari... but the point is - dga has valid uses. if the drivers simply flushed and disabled all hardware accel pipelines when going int dga mode, then re-enabled coming out, that'd be a nice simple way of handling it. it is a pain - but it does have legitimate uses. Sounds simple enough... can it be done? then again i have issues with dga as it stands. firstly needing to be root is one :/ secondly - last time (a LONG time ago now - so long i dont remember when) going in and out of dga meant a screen reset by the driver and so it was practically infeasible to combine dga rendering with normal rendering by other clients. i seriously think maybe dga should be moved over to be part of DRI. if DRI HAS to (for sanity) run a shadowfb system to make this work - (when DGA is in use) so be it, but it would make it sane to use. The root issue is unfortunate, but people seem less worried than they used to be about this if the software is from a trusted company. that said i do agree - the games or software should ALSO use shmputimage and have a method to use that - on todays boxes it should be fast enough. there still are things opengl can't do... :) though that keeps being decreased in number... :) We could add a shmputimage for compatibility, but how do you sync frames to the vblank to ensure glitch free drawing, or does X take care of that? anyway.. back to lurking! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'*(B - $BV7/(B ($B?tED(B) [EMAIL PROTECTED] Tokyo, Japan ($BEl5~(B $BF|K\(B) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
On Mon, 15 Mar 2004 18:50:18 + James Wright [EMAIL PROTECTED] (B (BI agree... Using our own code to write diirect to the framebuffer is by far (B the fastest method for our application. "shmputimage" is no replacement for (B that.. Its like saying a double decker bus is an adequate replacement for a (B Ferrari... (B (Byup true - but then if that's your only choice... (B (B but the point is - dga has valid uses. if the drivers simply flushed and (B disabled all hardware accel pipelines when going int dga mode, then (B re-enabled coming out, that'd be a nice simple way of handling it. it is a (B pain - but it does have legitimate uses. (B (BSounds simple enough... can it be done? (B (Bi would say so - this needs to be done for vt switching... (the flush pipelines, (Bsync then put all rendering on hold) (B (B then again i have issues with dga as it stands. firstly needing to be root (B is one :/ secondly - last time (a LONG time ago now - so long i dont (B remember when) going in and out of dga meant a screen reset by the driver (B and so it was practically infeasible to combine dga rendering with normal (B rendering by other clients. i seriously think maybe dga should be moved over (B to be part of DRI. if DRI HAS to (for sanity) run a shadowfb system to make (B this work - (when DGA is in use) so be it, but it would make it sane to use. (B (B The "root" issue is unfortunate, but people seem less worried than they used (B to be about this if the software is from a trusted company. (B (Btrue - but still, it would be nicer... :) (B (B that said i do agree - the games or software should ALSO use shmputimage and (B have a method to use that - on todays boxes it should be fast enough. there (B still are things opengl can't do... :) though that keeps being decreased in (B number... :) (B (BWe could add a shmputimage for compatibility, but how do you sync frames (B to the vblank to ensure glitch free drawing, or does X take care of that? (B (Berrr - you don't. your best bet is the doublebuffer extension here and hope x (Bdoes the copy for you with the vsync in mind - otherwise its just a "best try" (Bif its got glitches - you've done your best. you've tried dga and it doesn't (Bwork. u've tried double buffer and its not there - you don't have a lot of (Bchoice left! :( better that it works and have tears etc. than doesn't run at (Ball! :) (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
CH we are missing a point here. you do know Xfree is used on handheld CH devices like pda's etc. ? i have measured a full 20% speedup in CH rendering with direct fb access compared to going via a CH shmputimage pipeline on my ipaq, Good point. The same will be true of older machines (a 68K mac makes a great X terminal). Have you measured memcpy speed on those machines, so we can know whether it's actually the extra copy that bites you, or whether we're doing something wrong? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
On 10 Mar 2004 09:32:46 +0100 Juliusz Chroboczek [EMAIL PROTECTED] babbled: (B (B CH we are missing a point here. you do know Xfree is used on handheld (B CH devices like pda's etc. ? i have measured a full 20% speedup in (B CH rendering with direct fb access compared to going via a (B CH shmputimage pipeline on my ipaq, (B (B Good point. The same will be true of older machines (a 68K mac makes (B a great X terminal). (B (B Have you measured memcpy speed on those machines, so we can know (B whether it's actually the extra copy that bites you, or whether we're (B doing something wrong? (B (Bno - i haven't measured it... BUT it isn't great. memory bandwidth isn't a big (Bpositive of these devices. i'm almost certain it is the memcpy and context (Bswitch as that really is the ONLY difference in the rendering code i have as all (Bthings are cpu rendered in rgba32 then down converted to screen depth - this is (Bthe point where it either gets converted direct to framebuffer (which (Bincidentally lives within system memory like the i810 - stealing a little system (Bram and having the ramdac scan that), or if running in x, will get converted to (Ban shm buffer, then context switch and have shm buffer copied to real fb. this (Bcopy is the only real difference :/ it's even worse with a shadow fb and (Bportrait rotation! thus u prefer using my own code that can do the rotation (Bwhile converting 32bpp to 16bpp and dithering :) (B (Bbut the point is - dga has valid uses. if the drivers simply flushed and (Bdisabled all hardware accel pipelines when going int dga mode, then re-enabled (Bcoming out, that'd be a nice simple way of handling it. it is a pain - but it (Bdoes have legitimate uses. (B (Bthen again i have issues with dga as it stands. firstly needing to be root is (Bone :/ secondly - last time (a LONG time ago now - so long i dont remember when) (Bgoing in and out of dga meant a screen reset by the driver and so it was (Bpractically infeasible to combine dga rendering with normal rendering by other (Bclients. i seriously think maybe dga should be moved over to be part of DRI. if (BDRI HAS to (for sanity) run a shadowfb system to make this work - (when DGA is (Bin use) so be it, but it would make it sane to use. (B (Bthat said i do agree - the games or software should ALSO use shmputimage and (Bhave a method to use that - on todays boxes it should be fast enough. there (Bstill are things opengl can't do... :) though that keeps being decreased in (Bnumber... :) (B (Banyway.. back to lurking! :) (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
James Wright wrote: It doesn't seem all that long ago that DGA V2 was added, why was it ever introduced if it causes grief for the driver writers? What where the original intentions of including the DGA extension into Xfree86? Same as DirectDraw in Windows. Some app writers want to own the desktop and draw directly onto the bits of the frame buffer. Both DirectDraw and DGA provide that access, and both of them are a pain for driver writers. It doesn't make them evil. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
On Mon, 8 Mar 2004, James Wright wrote: It doesn't seem all that long ago that DGA V2 was added, why was it ever introduced if it causes grief for the driver writers? What where the original intentions of including the DGA extension into Xfree86? DGA2 was added five years ago, and I regret it. Even then, I had the feeling that it was a bad idea. We should have encouraged more forwardlooking APIs like OpenGL. At the time, the transition from SW rendered games to HW rendered games was just happening. DGA was originally added by Jon Tombs back in 1995 so that Dave Taylor could implement xf86quake. I believe Dave Taylor found card support in SVGALib to be lacking. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
JWI'm just concerned that the DGA extension will be removed with JW no adequete replacement. The main issue with DGA seems to be the JW way it requires root privs and can write to other parts of JW memory. Can we not have some sort of /dev/dga device or is this JW not the place to ask ;) is this not feasible? James, I'm rather sympathetic to what you're trying to achieve (and I do know other legitimate applications for DGA), but unfortunately it can't be done. What Mark is speaking about is the added complexity to drivers to allow direct access to the framebuffer and synchronise with the client. Doing that through a device won't simplify matters. If you're working with small updates, you should be going through a shared mem pixmap and using ShmPutImage. Yes, this will cost you one extra copy (from your app to the shmem segment, and then from the shmem to the framebuffer), but that should not be noticable on modern hardware (which can typically push half a gig per second). If you do things right, you should be able to render directly to the shared mem segment, which will avoid the first copy. As an additional data point, I'd like to refer you to the shadowfb code, which basically introduces an additional buffer in the server and pushes all screen updated through that, basically what you'll be doing with a shmem segment. Experience shows that the shadowfb code is sufficiently fast in all cases, and actually faster than any form of direct unaccelerated rendering (except for filling areas). Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
On Sun, 7 Mar 2004, James Wright wrote: We are concentrating on developing games which utilise polished 2d graphics engines, rather than 3d. I know it sounds crazy but its what we want to do... With most 2d engines the number of pixels drawn is usually kept to a minimum, unless there is a huge amount of overdraw going on, then its nearly always faster to draw direct to the framebuffer. If we do need to scroll the whole screen, then we would try to alter start of viewport address rather than transferring the entire screen. I'm just concerned that the DGA extension will be removed with no adequete replacement. The main issue with DGA seems to be the way it requires root privs and can write to other parts of memory. Can we not have some sort of /dev/dga device or is this not the place to ask ;) is this not feasible? James I think the biggest problem with DGA is that driver writers don't want to support it. I don't even test it anymore. If it didn't work, I wouldn't know about it until somebody complained. The DGA mode complicates what the driver has to do. We're trying to focus on how we use the offscreen memory for graphics command buffers, pixmaps, textures and video overlays, and don't like to have to deal with a mode where we have to make concessions for some app that wants to scribble on the framebuffer itself. As far as I'm concerned, there are alternatives. You can render to an XImage and use ShmPutImage, or if you need vblank syncing you can use OpenGL. Apps having direct framebuffer access is something that I would consider to be a legacy feature. The natural tendency is to drop support for that sort of thing eventually. Besides, I'm not sure we can guarantee that future hardware is going to be very amenable to direct framebuffer access. I've seen some evidence suggesting that it's not. Mark. On Sat, 6 Mar 2004 19:02:00 -0800 (PST) Mark Vojkovich [EMAIL PROTECTED] wrote: I expect it will go away eventually. It's still the case for most access patterns that rendering in system memory and then copying the result to the framebuffer is faster than CPU rendering directly to the framebuffer. Only the most simple game engines (write- only SW scanline renderers) can benefit from direct framebuffer access. Why aren't you using OpenGL? Mark. On Sun, 7 Mar 2004, James Wright wrote: Hello, Apologies if this is the incorrect list to post to but i couldn't decide between the general forum list or this one. My question concerns the DGA extension in XFree86, whether it will be removed from future versions, and the alternatives. We are currently in the process of developing games for the Linux OS. We require direct access to the video framebuffer, the ability to change resolution, refresh rate, indexed palettes, and the ability to alter the start screen position pointer (for hardware scrolling). At first we wrote our 2D drawing libs to use SVGALib, but after numerous problems with memory leaks and bad support for many gfx cards we switched to X11-DGAv2. We are reasonably happy with DGA as it stands, with the only annoyance being that it requires root privs. I have seen it mentioned that DGA could be removed in future XFree86 releases, is this true? If so, what are the alternatives for us to use? It is obvious that there are alot of apps out there that really can't justify the use of DGA, but I feel that this application (games) really can benefit from using it. Any extra layers between our drawing and the framebuffer is just extra overhead and latency for us... Any sugestions or comments appreciated... Thanks, James ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
DGA - the future?
Hello, Apologies if this is the incorrect list to post to but i couldn't decide between the general forum list or this one. My question concerns the DGA extension in XFree86, whether it will be removed from future versions, and the alternatives. We are currently in the process of developing games for the Linux OS. We require direct access to the video framebuffer, the ability to change resolution, refresh rate, indexed palettes, and the ability to alter the start screen position pointer (for hardware scrolling). At first we wrote our 2D drawing libs to use SVGALib, but after numerous problems with memory leaks and bad support for many gfx cards we switched to X11-DGAv2. We are reasonably happy with DGA as it stands, with the only annoyance being that it requires root privs. I have seen it mentioned that DGA could be removed in future XFree86 releases, is this true? If so, what are the alternatives for us to use? It is obvious that there are alot of apps out there that really can't justify the use of DGA, but I feel that this application (games) really can benefit from using it. Any extra layers between our drawing and the framebuffer is just extra overhead and latency for us... Any sugestions or comments appreciated... Thanks, James ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
I expect it will go away eventually. It's still the case for most access patterns that rendering in system memory and then copying the result to the framebuffer is faster than CPU rendering directly to the framebuffer. Only the most simple game engines (write- only SW scanline renderers) can benefit from direct framebuffer access. Why aren't you using OpenGL? Mark. On Sun, 7 Mar 2004, James Wright wrote: Hello, Apologies if this is the incorrect list to post to but i couldn't decide between the general forum list or this one. My question concerns the DGA extension in XFree86, whether it will be removed from future versions, and the alternatives. We are currently in the process of developing games for the Linux OS. We require direct access to the video framebuffer, the ability to change resolution, refresh rate, indexed palettes, and the ability to alter the start screen position pointer (for hardware scrolling). At first we wrote our 2D drawing libs to use SVGALib, but after numerous problems with memory leaks and bad support for many gfx cards we switched to X11-DGAv2. We are reasonably happy with DGA as it stands, with the only annoyance being that it requires root privs. I have seen it mentioned that DGA could be removed in future XFree86 releases, is this true? If so, what are the alternatives for us to use? It is obvious that there are alot of apps out there that really can't justify the use of DGA, but I feel that this application (games) really can benefit from using it. Any extra layers between our drawing and the framebuffer is just extra overhead and latency for us... Any sugestions or comments appreciated... Thanks, James ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
