> > The games perform overdraw, sure. But I am talking about at the pixel > > level. A scene-capture algorithm performs 0 overdraw, regardless of what > > the game sends it. > > That's not true. I've designed and built machines like this and I know. > > You still need overdraw when: > > * you are antialiasing a polygon edge. > * you are rendering translucent surfaces. > * you need more textures on a polygon than your > hardware can render in a single pass. > * you have to read pixels back from the frame buffer and then > continue rendering polygons. > * polygons get smaller than a pixel in width or height. > * you need to draw more polygons than your hardware has > room to store.
I agree with the "you have to read pixels back from the frame buffer and then continue rendering polygons." For a hardware implementation I might agree with the "you need to draw more polygons than your hardware has room to store", but only if the hardware implementation decides to perform overdraw rather than fetching the triangles on the fly from AGP memory. With the rest I disagree. The Kyro, for example, has some high-speed local memory (cache) it uses to hold the pixels for a tile. It can antialias and render translucent scenes without ever blitting the cache to the framebuffer more than once. This is the advantage to tile-based rendering. Since you only need to hold a tile's worth of pixels, you can use smaller high-speed cache. As far as the reading of pixels from the framebuffer, this is a highly inefficient thing to do, no matter the hardware. If you want a fast application you will not attempt to read from the video card's memory. These operations are always extremely slow. I still maintain that immediate mode renderering is an inefficient algorithm designed to favor the use of memory over computations. A better algorithm will always win out given enough time to overtake the optimized versions of the more inefficient algorithms. -Raystonn Sponsored by http://www.ThinkGeek.com/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
