Benchmarks and Limitations

Unlike a Fill-rate limited benchmark, a Geometry limited benchmark is limited by CPU speed, not 3D accelerator speed. (I will use Geometry as a general term encompassing not only geometric transformations, but lighting, etc. as well) Two main conclusions can be drawn from this: (1) Geometry limited benchmarks are poor benchmarks for 3D accelerators, since the CPU (and latencies, drivers) is what sets accelerators apart, not the accelerator's power, which is generally what we want to know in a 3D accelerator round up, for example. The second conclusion is that Geometry Limited Benchmarks generally yield the same FPS even when upping the resolution. The latter conclusion is good to know, as it helps recognize geometry limited benchmarks.

Some Geometry (CPU) Limited Benchmarks

There are not many geometry limited benchmarks. The Unreal timedemo is somewhat geometry limited, but not nearly as geometry limited as a very popular new benchmarks, crusher.dm2. It is somewhat ironic that crusher is gaining popularity, as it is very CPU limited. Even though the DM level used is of relatively low polygon count, all of the people one the screen, and the rocket launcher / BFG explosions account for much of the CPU cycles. (Explosions must be calculated, which takes a lot of extra cycles) The problem with Crusher.dm2 as a CPU limited benchmark is that, since it uses the Quake2 Engine, plus it has a lot of overdraw, due to the excess number of characters on the screen at any one time, it is also very fill-rate limited. @640x480, however, most cards are CPU limited with crusher.dm2. The Unreal benchmark is somewhat CPU limited as well; however, since it is much more fill-rate limited than it is CPU limited, Unreal's geometry limit is probably only evident with Voodoo2 SLI and the likes. (I don't have Voodoo2 SLI yet, so I can't be absolutely sure)

Recognizing a Geometry Limited Benchmark

Recognizing a Geometry Limited Benchmark is relatively easy. Since The 3D accelerator has excess fill-rate, the FPS is directly proportional to the CPU speed.

The ideal Case

What was described above is the ideal case, as usual. In the ideal case, FPS = k * CPUSpeed, where k is some constant which tells us how many frames of data the CPU can pump out in a certain number of time. You can let k * CPUSpeed = FramesDataPerSecond, in which case, FPS = FramesDataPerSecond. Of course, the real world situation is not the same, but it is very similar.

The real world situation

First of all, as mentioned above, crusher.dm2 is also very fill-rate limited, since it uses the Q2 engine, and there is a lot of overdraw (characters generally generate a lot of overdraw). Since crusher.dm2 is very fill-rate limited as well as geometry limited, the fill-rate limit may show on certain cards when running on a fast Pentium II @high resolutions.

It's not exactly a line, but it's close enough. Most geometry limited benchmarks generate straight line graphs. Geometry limited benchmarks which are not fill-rate limited at all (i.e. wireframe, simple flat shaded programs) will generate horizontal line graphs when changing the resolution, since changing the resolution effects the fill-rate, and that's just about it.