PDA

View Full Version : OpenGL benchmark 2 opinions..



Ysaneya
10-14-2002, 08:16 AM
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.. http://www.opengl.org/discussion_boards/ubb/smile.gif 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 http://www.opengl.org/discussion_boards/ubb/smile.gif

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.

Ysaneya
10-14-2002, 08:17 AM
Btw, one of the major changes, as seen in the screenshot, is that you will be able to change all the options on-the-fly..

Y.

martin_marinov
10-14-2002, 10:50 AM
Hi,
the screenshot is very nice http://www.opengl.org/discussion_boards/ubb/smile.gif, but the supplied .exe is still ver 1. So the question is where to download the new version - it's not written in your posts http://www.opengl.org/discussion_boards/ubb/smile.gif

Regards
Martin

fenris
10-14-2002, 10:55 AM
You aren't very good at reading, are you martin? Come on man, it's in the first friggn' paragraph! RTFP! http://www.opengl.org/discussion_boards/ubb/smile.gif

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.

martin_marinov
10-14-2002, 11:31 AM
Originally posted by fenris:
You aren't very good at reading, are you martin? Come on man, it's in the first friggn' paragraph! RTFP! http://www.opengl.org/discussion_boards/ubb/smile.gif

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.

hahaha http://www.opengl.org/discussion_boards/ubb/smile.gif
you are completely right - I skipped the introduction and after I saw the schreenshot
I decided to download it.... - http://www.opengl.org/discussion_boards/ubb/smile.gif

Regards
Martin

jwatte
10-14-2002, 01:58 PM
Make sure you jitter the modelview matrix a little bit between each frame. Some drivers (*cough*TNT2*cough*) save post-transform data for a display list and re-uses it if the modelview matrix hasn't changed. Makes for impressive triangle throughput rates :-)

Moving the camera 0.00001 alternately to the right and to the left each frame should be sufficient to "work around" this feature.

I'd actually also be interested in fill rate numbers. How about running with double-sided geometry, single-sided geometry, and glCullFace(GL_FRONT_AND_BACK) as options? How about drawing near-to-far vs far-to-near? How about drawing with and without basic modulate blending?

Other things to measure:

GL_NORMAL_MAP and GL_REFLECTION_MAP reflection mapping modes.

GL_EYE_LINEAR and GL_OBJECT_LINEAR texgen modes.

Texturing out of small/large/cubemap/3d textures.

16 vs 32 bit frame buffer modes, with and without depth buffers?

knackered
10-14-2002, 02:01 PM
I assume the checkboxes in the "Transfer Method" groupbox should be radio buttons instead? http://www.opengl.org/discussion_boards/ubb/wink.gif

josip
10-14-2002, 02:20 PM
Originally posted by knackered:
I assume the checkboxes in the "Transfer Method" groupbox should be radio buttons instead? http://www.opengl.org/discussion_boards/ubb/wink.gif


He'll run through each method selected so that you can see how well each performed in relation to each other, so the checkboxes are intentional. I think.

Ysaneya
10-15-2002, 12:10 AM
Yes, they are :) The idea is that you can select multiple transfer methods, and test them to compare the results.

Jwatte: are you sure about that modelview matrix stuff ? Now that sounds really weird.. compiling a display list is a slow operation anyway, so how could they do it between frames ? And how to define a frame ? How do you determine which operations will be put into the display list ? I won't believe it until i see it myself :)

About the fillrate stuff: it'd be interesting to have a fillrate test, but i think there's already a few ones around, and the two tests would interfer if ran at the same time. I think i'll just keep it simple (err: as simple as possible) and focus on T&L.

To some extents, some things you are proposing will be present: the rendering mode (none <=> cull front & back; wireframe; flat color; modulated colors + textures), and the texgen modes, because this can have an impact on the performance, since you're not submitting the tex coords data yourself..

Y.

Ysaneya
10-15-2002, 07:09 AM
Had a suggestion to add a selector for the number of pass to draw the geometry.. might be interesting for CVA.

Still no comment on the vertex formats ? Aka shorts vs floats for position or tex coords, is that interesting or should i drop support for it ?

Y.

GeLeTo
10-15-2002, 08:42 AM
Originally posted by Ysaneya:

<SNIP> Caching: an option to see how the vertex cache is influencing the framerate. The indices can be cache-friendly, or completely randomized.. <SNIP>


An option for optimizing the geometry for a specified vertex cache size would be very nice. Using a real model and optimizing it with the NvTriStrip library (for a specified cache size) would be great. The "maximize FPS" button should report the most optimal cache size.

[This message has been edited by GeLeTo (edited 10-15-2002).]

GeLeTo
10-15-2002, 09:06 AM
Also an option for double-sided lighting and wireframe drawing would realy please the CAD folks around here. These make hell of a difference on a GF vs GF Quadro.

V-man
10-15-2002, 04:40 PM
Software transform and lighting vs hardware transform and lighting. (SSE, SSE2, 3D Now! and all that)
Loading custom scenes would be a plus.

That's it!

V-man