> 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.
You need to agree that current hardware does implement the sheme where some percentage of pixels is drawn multiple times. Its a straigforward hardware design that nicely opens ways for getting the performance with an affordable amount of ASIC design engineering power. I dont assume the current market leaders did choose that way if they did expect to get more performance from the approaches. In the end i am pretty sure that this approach does provide more ways for interesing features and effects than the mentioned one pass rendering would provide. Anyways, the current memory interfaces for the framebuffer memory arent the performance break at all today. Its the features that the applications do demand e.g. n-times texturing. If these one-pass algorithms would be so resource saving, why is there only a single hardware implementation and the respective software solutions are of not much attention? The only reason i can see is, that it does not work as effective and performance increasing. To be honest you must substract the preprocessing time from the rendering gain. And you must expect the adapters not rendering at full speed because its running idle for some time due to CPU reasons. > 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. Pixel caches and tiled framebuffers/textures are state of the art for most (if not all) of current engines. Only looking at the Kyro would draw a fals view of the market. Kryo has it too, so its sort of a "me too product". But a vendors marketing department will never tell you that it is this way. > 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. For this there are caches (most often generic for nearly any render unit). And reading is not that different from writing on current RAM designs. Some reading is always working without any noticeable impact on performance, (and its done for a good bunch of applications and features) but if you need much data from framebuffer, than you might notice it. That closer the pixel consuming circuit is to the RAM that better it will work. A CPU is one of the not so good consumers for pixels. > I still maintain that immediate mode renderering is an > inefficient algorithm designed to favor the use of memory > over computations. Hmm, current state of the art is called display list based rendering and its up to date and nicely optimizde despite the concept is an older one. It takes the goods of both worlds. Fast overdrawing rendering into memory and a higher level of primitive preprocessing. With only a single comparision on a preprocessed displaylist you can quickly decide if that display list is in need to be sent to the grafics adapter. Just belive that the performance is only at an optimum level if you are able to take the best of the two worlds - extreme overdraw rendering is neither good for performance, nor is intense geometrical preprocessing on a per frame base a viable way to performance. The hardware industry has found nice ways for combining both of these technologies to provide you the best of both worlds and thus the highes performance. And they are further developing in both of that areas and a few others more. Regards, Alex. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
