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.