|
CPU Vs. Fill-Rate? Question submitted by (18 February 2000)  |
Return to The Archives |
 |
 |
|
|
I've been do a lot of thinking lately about rendering engines that
dynamically adapt rendering quality to achieve a target frame-rate. There
are, basically, two different factors the impact the rendering time for a
particular scene: fill-rate and CPU speed. Either one (or both) could be
the barrier to achieving the desired frame-rate. Depending on which is the
barrier, different strategies will need to be used to improve the frame-rate.
However, with an API such as OpenGL, is there anyway to tell which is the
barrier? In the old days, when you had to program the hardware directly, it was easy to tell. You just put a counter in the loop that waited for the hardware to finish filling (or whatever). If the counter got quite large, then the blitter was the bottle neck. How can this be done with a modern API like OpenGL? |
||
 |
 |
 |
|
|
|
There's no effective way to get this information in real time. This is why
you see Geometry Detail and Texture Detail sliders in most games. For what
its worth there are more possible bottlenecks than just fill-rate and
transform speed. To name a few off the top of my head: 1. Texture thrashing - Occurs when you upload more textures than can fit on the card. This causes the driver to page textures on and off the card as they're used. Dropping texture resolution or bit depth can help this. Reducing resolution will also free up more texture memory on cards other than the Voodoo1, 2, and Rush. 2. Fill Rate - This is how many pixels actually get written out to the screen. Reducing resolution (bits per pixel as well as size) will reduce fill rate requirements. As fill rate increases, so does the bandwidth required to fetch the texels (see #3). 3. TMU Bandwidth - This is bound by texture memory speed and the width of the bus from card memory to the TMU. Reducing bit depth can help this tremendously. This also gets hit very hard when tri-linear mip-mapping or anisotropic filtering so turning those off can help a lot. 4. Geometry Complexity - Amount of time it takes to transform, light, etc the geometry. Reduce the number of vertices sent. Response provided by Tom Hubina |
||
|
|
|
This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists. |