
|


|
SE: How does this technology compare to tile-based rendering solutions, such as the PowerVR architecture?
Nalasco: The T&L stage of a tile-based pipeline work basically as described above. The engine then divides the screen up into blocks of pixels or "tiles". For each tile, the engine looks at the vertex co-ordinates of every polygon to determine which are partially or entirely inside the tile, then applies a sorting algorithm so that they are placed in order of depth. When the sorting is complete, the engine walks through each pixel in the tile, determines which polygon it belongs to, and renders it. When every pixel in the tile is rendered, it writes the tile out to the frame buffer and repeats the process for the next tile. Like Hierarchical Z, this method improves rendering efficiency by performing the Z-test prior to rendering each pixel, thus eliminating overdraw. The other advantage of this method is that as long as the tiles are kept fairly small, all Z-buffer data can be stored on-chip in a cache, which avoids the need to read and write to video memory and reduces memory bandwidth requirements even more.
There is one important reason why tile-based rendering is at a disadvantage relative to traditional rendering. It has to do with the sorting step that has to be performed prior to rendering. While this can be done fairly quickly in scenes with large triangles, the required sorting time grows exponentially as the triangles get smaller and more numerous. You may have noticed that the two major graphics companies working on tile-based architectures (Imagination/STMicroelectronics and Gigapixel/3dfx) are playing down the significance of T&L, while everyone else is hyping it up. The fact is, nearly all the major games coming out later this year will support T&L and much higher polygon counts than today's games, and in these situations tile-based renderers will fall well behind in terms of performance. Since we targeted the RADEON architecture squarely at these upcoming games, a tile-based architecture didn't really make sense. Instead, we designed HyperZ to give us much of the benefit of tile-based rendering, while avoiding its key weakness.
|
|

|