On Thu, 2007-05-31 at 10:36 +0200, NoiseEHC wrote: > I have meant displaying with scaling. Filling 1200x900 in 30fps is > impossible I think. > IMHO there is no feature in the Geode DC which could be used by the > rasterizer so I think it is not a problem to concentrate on this one > feature (scaling) it can do quite well. > As I see in the DCON documentation, it simply scraps 2/3 of the frame > buffer data when deswizzling so it seems that not generating that data > would be a win either way.
You could certainly attempt to optimize fragment generation for the swizzle layout to only emit the relevant color, but I suspect you're going to be saving only CPU time there, not memory bandwidth. Your pixels are still going to be 4 bytes wide on the path from the CPU to the framebuffer, and I strongly doubt the cacheline flush can write anything less than dwords at a time. Strictly speaking, the display is always throwing away 2/3 of your pixel data, but the pixels coming out of the Geode GPU are always fully loaded. The storage optimization is just in the DCON's internal RAM, not the GPU framebuffer, and it's purely optimizing for component cost. 1M is 8388608 bits, but 1200x900 of packed 6-bit words is 6480000 bits. The antialiasing, when enabled, happens on input to the DCON (math done over rgb676), but the ouput from the antialiasing stage is back down to 6-bit. We could also use the LX's output scaler [1], so that the panel would always be driven natively at 1200x900 but you'd render to, say, 800x600. Of course if you do this you can't optimize fragment emission by subpixel channels. 800x600 would effectively give you pixels with a 2x2 geometry, the top left being: R G G B and then swizzled in the usual fashion along both axes. Weirdly, 800x900 would work (R+G for first pixel, B+R for second pixel, etc), but the math for your view frustum would get more complex. So you probably can't do the fragment color optimization, but you would likely save enough in memory bandwidth to make it worthwhile. I recommend 400x300 if we go this route, just to make your pixels a uniform color. The problem with doing so is the interaction with Sugar. Even if it were smart enough to catch the root window resize and reposition the frame, it'd have to also scale all the icons down, and do a mode switch on activity switch, and etc. [1] - I think. I'm reasonably sure this is effectively free as it's happening in the DAC not the GPU, but I'm not sure. Also, I don't remember if this exists on both GX and LX. Even if it does, this is RANDR code in the geode driver that just isn't there yet. - ajax _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
