OpenGL geometry benchmark released..

[Ysaneya]

Ok thanks, i'll try yo debug it tomorrow. I've been working on this program for 2 days now, and i'm starting to get a bad headache

Y.

[Nakoruru]

You should use the swap_interval extension to override the users vsync selection in drivers. Anyway, all my results seem to make sense so far. Nice program.

EDIT: (deleted a couple of statements about the driver settings for vsync which I realized were incorrect once I though about them)

[This message has been edited by Nakoruru (edited 09-23-2002).]

[Funes]

Nice and useful app! Good work!

I tried some times ago to understand in the same way how the geometry (T&L) performance can change when varying the various transfer, format vertex parameters.

I did a post on this subject but got no answer (http://www.opengl.org/discussion_boa...ML/007347.html ) Probably i should have added something to download and test :-)

Just to add my 5 cent. to the discussion, i noticed some things that probably could be useful:

1) when speaking about rendering high triangle-count scenes, the fact that we are rendering a real big scene and not rendering ten times the same array, affects a lot the performance. (and not only when your scene does not fit al in agp or video mem

2) The size of the vertex arrays blocks matters (best is from 1k to 7k vertices).

3) the length of the strips little changes the speed. (its important above 30M/sec).

4) i could degrade performance to 30M/sec by avoiding the vertex caching. (100vertex/turn)

3) if i reorder vertices in the block and performance drops considerably, depending on how much (and expecially how locally) i permutate.


thanks

funes

[Ysaneya]

Nakoruru: that makes sense, i'll disable vsync for the tests.

Funes: didn't know your 5th cent was worthing your 3th Anyway, you've got excellent ideas, but i'm hesitating to add too many options. For every option i add, it multiplies by 2 the full-test time (since it tries all the possible combinations).. by implementing everything, the full test will take many hours! Ideally i should try to restrict the tests to the important combinations, but how to make sure no important one is missed ? Any ideas are welcome..

Y.

[kehziah]

When I implemented this kind of benchmark a while ago, I made an 'interactive' program. It was a dialog box where the user could switch options on and off on the fly. For example, you had a slider for tesselation level, radio buttons to choose between immediate / VA / CVA ... This way the user can test only things that interest him and get the results immediately (by displaying FPS and MTris/sec info). Problem is it's not well suited to generate nice reports like your program does.

Another feature for your wishlist : it would be nice to have ATI_map_object_buffer support (this extension has been around for months but specs are still not publicly available. Maybe some ATI registered developers out there could send you these specs (or maybe this extension could be documented ^^)).

[Funes]

Ysaneya: i know, the number of test is exponential, but in my humble opinion, the main problem is not running the tests (the night is long... :-) ), but browsing the whole mess of results. I think that just looking at the fastest combination is not very useful. What i would like to know is what is the most discriminating factors when rendering. In other words, let assume that you have 2^n timings each one corresponding to the enabling/disabling of one of <n> different "things" (strip, cva, short/long indexes, chache aware primitives, video/agp... etc) the most discriminating factor should be the one that minimizes the ratio between the sum of timings with that feature enabled and the sum of all timings with that feature disabled.
Probably this should be a good hint for everyone on what path you should choose when starting to optimize your code...


funes.

[Humus]

Originally posted by kehziah:
Another feature for your wishlist : it would be nice to have ATI_map_object_buffer support (this extension has been around for months but specs are still not publicly available. Maybe some ATI registered developers out there could send you these specs (or maybe this extension could be documented ^^)).

If you look in ATi's glATi.h file it's pretty much obviuos what the extension does and how to use it. It exports these functions:
void *glMapObjectBufferATI(GLuint buffer);
void glUnmapObjectBufferATI(GLuint buffer);

It's like Lock()/Unlock() on D3D vertex buffers.

[harsman]

Usually not all combinations are interesting. If I have found out from testing that display lists are faster than immediate mode I might not care if immediate mode is faster with strips, or with short indices etc. Instead of ranking all possible combinations you might rank each group separately and then combine the results. I.e Video mem VAR is fastest, shorts are faster than longs, strips are faster than lists. Then you can guess what the fastest mode is and do more exhaustive testing on that.

[Adrian]

Nice app, thanks.

I would like to see options to benchmark with texturing and also only using 1 light not 3. I know this could make for a lot more combinations but I think most apps have texture mapping and either 0 or 1 gl light.

[vshader]

i agree, great app.

Display Lists actually just pip Video VAR on my machine (although the difference is tiny...).. both about 22MTris (GF3, athlon 1800+)