The first test I ran was a cube (12 triangles) on the 16384 track. It ran at 39 FPS. This is essentially no triangles so this is roughly a measurement of draw call overhead, which comes out to 39*16384 = 638976 draw calls per second.
Related to the first test is how fast you can switch between textures. I ran the first test but alternated between two different textures. This ran at 28 FPS which comes out to 458752 texture changes / second. This one surprised me. I was expecting it to be much worse.
Here's the main test. I threw out tests under 8 FPS and over 128 since they won't be right since the game will either run in slow motion or sleep at those rates. Each row is the triangles/second and FPS counts for the different models on one track.
Code: Select all
monkey0 monkey1 monkey2 monkey3
64 (>128) (>128) (>128) 181370880 (45)
256 (>128) (>128) 181370880 (45) 177340416 (11)
1024 (>128) 241827840 (60) 193462272 (12) (<8)
4096 198246400 (50) 290193408 (18) (<8) (<8)
16384 303155336 (19) (<8) (<8) (<8)
Surprisingly, the smaller models get higher triangle throughput despite using more draw calls. This is probably because at 968 and 3936 triangles the monkey0/1 models fit in the GPU's cache memory.
Finally, if you're a modeler and wondering when reducing triangle count is pointless since it's overwhelmed by draw call overhead, a draw call takes about the same time as 280 triangles on this GPU. So if you imagine your object starts out with 280 triangles that'll give you an idea of how you save as a percentage for each triangle you remove. (E.g. if you have 10,000 triangles and remove 1000, the model will take about 90.3% (9280/10280) of the time to draw, so you removed 10% and saved almost 10%. But if it was 1,000 triangles and you remove 100, it'll draw in 92.2% (1180/1280) of the time, so you only gain ~8% for removing 10%. For 10% off of 100, it'd be 97.3% (370/380) only saving ~3%.) So basically, once it's down in the low hundreds it's getting pointless.
