I agree with Adrian, a texture option (single and dual texture) should be nice, and one light option too
Arath
If you do add texture, make sure it is a tiny one, because you do not want memory bandwidth to interfere with the benchmark.
Remember, there is no such thing as the number two. It makes no sense to have 3 lights. In programming 0, 1, and Infinity are the only numbers 
If you have 3 then you should allow selection of up to as many lights as the implementation supports.
Same with textures coordinates, support up to the implementation maximum for sending texture coordinates. But, again, keep the actual textures small because this app measures the cost of sending those coordinates, not the cost of actual texturing.
Also, why not add support for texgen as well? Instead of flat texture coordinates it might be cool to test the speed of different texgen modes. Hmm, although you may consider that a little less focused. The current app seems to only be concerned with transfering geometry, not what happens when it gets there. The choice of 0 or 3 lights is the only exception.
Eventually it would be cool if you could load an arbitrary vertex program and pass it to the program to benchmark.
I think you’ve all got good points, thank you !
ATI_map_object_buffer is pointless, since it’s used to dynamically update a video vertex array. I fill the array during its creation, not when rendering with it, so it’s not interesting. Maybe in the future, if i add support for a rendering backend that streams data from system memory…
I’ll see if it’s not possible to group similar results in a same category. It’s true that browsing the results is a real pain now…
I will also probably add support for 1 light and texture coordinates, since it’s an important information. Texgen modes too, quite probably. Also on my plan, rendering 768k different tris and not the same array many times, plus an index randomizer to test the cache performance. Give me a few days
Y.
i got a few crashes as well i think in the displaylists + VAR, i havent looked at the code but perhasps youre asking for too much memory.
texturing is nice (but of course u have to let the user decide what textures 
)
also tex env mode, colors, blending blah blah (btw lighting lighting ranks way down the list)
FWIW i tried to start something similar about a year ago (though much larger/exaustive eg like glspec) but noone was interested
Originally posted by zed:
FWIW i tried to start something similar about a year ago (though much larger/exaustive eg like glspec) but noone was interested
Well, maybe today it’s a little bit more important bcoz there are a few T&L boards available. Nvidia,ATI,Matrox,Sis and Trident are all back!
Thus 10 years after we’re coming back in the era of dedicated co-processors! (muahaha it’s so funny) BUT… i really think that some implementations have missed the point! But anyway, what i think is not important then a good bench app is much much more relevant here!
[This message has been edited by Ozzy (edited 09-25-2002).]
I don’t think i’m asking for too much memory, but i admit i’m not doing a lot of error handling, and everything is uninitialized/reinitialized between each test (display lists are compiled, VAR is reallocated, etc… ). Maybe some drivers don’t like that…
Y.
It crash on my SGI !!!
Is your coding really clean ?
Gaby
zed,
Letting the user decide textures and blending have nothing to do with benchmarking triangles per second. If the program wanted to benchmark fillrate and/or memory bandwidth it would want to render only a few hundred really big overlapping triangles, and it would not even matter if it used immediate mode or VAR.
It would be neat to have such a benchmark. I can imagine it allowing you to test all the fancy Z buffer optimizations by allowing you to render front to back and back to front. Memory bandwidth would be tested with blending and big-textures. It would be a much more complicated benchmark because there are many more options that effect fill-rate and memory bandwidth use.
If you combined geometry throughput and fill-rate/memory-bandwidth into a single test however, you will end up with a very difficult to analyse dataset.
I bet that your choice of texture (big or small) would have absolutely no effect on the speed of this benchmark, because it is the texture coordinate being in the datastream that will slow it down, not the memory bandwidth usage.
yes Nakoruru i was talking about a more general app (like glspec)
about the textures
i posted this a couple of months ago http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/006595.html