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 - $B<V7/(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
