http://www.fl-tw.com/opengl/GeomBench/setup2.jpg
I decided to make a new (hopefully improved) version) of my benchmark, with a lot more options. I’m looking for opinions on what else could be interesting to benchmark, before i start working on the code. So far, i have just finished the layer of the dialog box, as seen in the screenshot.
(Remember it’s a pure T&L benchmark, i’m not interested in testing pixel shaders or stuff like blending).
Geometry transfer methods: no change
- Immediate mode (glBegin…glEnd)
- Vertex arrays
- Compiled vertex arrays
- Display lists, using glBegin…glEnd
- Display lists, created with vertex arrays
- Vertex array Object in video memory,
- VAO in AGP memory,
- Vertex array range in video memory,
- VAR in AGP memory
A new feature is the ability to specify if the geometry is static or purely dynamic. When dynamic, it means the vertex array is updated each frame.
Vertex components: lots of change. I have added texture coordinates support, but you can also use the color array, and specify the format of each component. I’d be interested to hear what kind of components i should support ? Like shorts for positions or tex coords, is that really usefull ? In addition you can use an automatic tex gen mode if you want.
Vertex format: interleaved or flattened, no change;
Index format: short or long indices, no change;
Triangle format: lists or strips, no change. Would fans really be interesting? or quads lists?
Lights: 0, 1 or 3 lights, due to lots of requests…
Vertex alignment: you can specify the min. vertex alignment, so far i planned values such as 0 (vertices are packed in the VA), or aligned to 16, 24, 32, 48, 64 or 128 bytes. For instance, if the components of your vertices are interleaved and sum up to 28 bytes, the vertices will be aligned to 32 bytes if you have selected at least 0, 16, 24 or 32 bytes.
Vertex array size: another new feature. You can now select the size of a single vertex array, values like 512, 4096, 16384 and 65536 vertices (small or large arrays, basically) are allowed.
Triangles per call: 16, 64, 256, 1024, 4096, 16384 or as many triangles as possible per glDrawElements (or similar) call. This is to see the influence of the number of calls on the framerate.
Scene complexity: 65k or 384k. I have reduced the max scene complexity from 768k to 384k, because it was a bit overkill, and ran terribly in slowest modes. Not that 384k will be a lot faster, anyway…
Caching: an option to see how the vertex cache is influencing the framerate. The indices can be cache-friendly, or completely randomized…
Most of the options can be OR’ed… that means you can test multiple combinations, like in the first version of the benchmark. But hum, it will no longer be exhaustive, because given the number of combinations, it would be impossible to test them all now. I calculated that, given 1 second per test, all options OR’ed, it would take billions of hours to test everything… 
That’s the reason why i’m willing to add a “maximize FPS” button, that will try, by changing a few options each time, to maximize the framerate. The idea being, if on a given number of tests, the same feature makes everything slow down, there’s no need to test further tests with that option on
Finally, discriminating factors will display the list of features that influence the framerate the most… for example: “average 85% speed increase from triangle lists to triangle strips”, or something like that…
Feedback…?
Y.
