On 15 Nov, Keith Packard wrote: > > Around 11 o'clock on Nov 15, Branden Robinson wrote: > > While saving memory was one reason, a far more interesting one is > performance. Packing pixels together like this means that you get an > automatic 25% savings in memory bandwidth needed to shuffle pixels around > the frame buffer. Of course, it sucks for the CPU, but we're pretty much > used to dealing with brain damaged graphics hardware in the PC world. >
It will continue to suck for CPUs for the forseeable future too. The video controller must do its job once per frame refresh, forever. The CPU deals with this crud only once per update. I've dealt with the design instructions: a) keep cost down but b) you have 5 nanoseconds to handle all lookup processing and c) we need an accurate glitch free DAC. Dropping bandwidth really helps. The extra cost on the CPU side is small in comparison. I would also add that current video ram is not excessive for 2D work. When you start doing substantial image manipulation work there are many advantages to having 32-64MB of ram for image storage. There is no gain for the fancy image processing algorithms that belong in the CPU. The gain is from having fast response to pan, window raise/lower, and similar operations. On my system each image consumes 4-12 MB of pixrect storage. 32MB is gone in no time. Now if only more people would demand 10 or 12-bits per color. The affordable RAMDACs are still only 8-bit per color. R Horn _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
