Advertisement

OpenGL State Change Benchmark Data?

Started by September 26, 2006 08:23 PM
14 comments, last by Steve132 18 years, 2 months ago
Quote: Original post by Steve132
How would such a program be written?

I tried calling 100 - 100000 same functions and using glFinish after loop. But I don't think that glFinish has any effect on glBindTexture. I Only found out that: glBindTexture is 15x - 300x slower than glColor and that opengl optimizes many things for you.
Quote: There is this new extention from nvidia that can mesure time in picoseconds that can preform these tests but it's only for the latest quadro cards.


Thanks for all the help! So far this is all very useful. I may even be able to do what I wanted just based on what you said.... Out of curiosity however, what is this extension called? I have a mobile quadro card in my laptop, and it may be too old, but I would like to look into this, but couldn't find it in the extension registry.
Advertisement
It's called GL_NV_timer_query or GL_EXT_timer_query, it's not in the registry because
1. the GL_NV_timer_query version is sort of a public beta of a sorts, the real one will be called GL_EXT_timer_query
2. the registry is not known for updating often

A link to the spec might perhaps be in order.

O and it's in nanoseconds nothing else i might have mentioned, i think that was from when one of the devs just let it slip that picoseconds will be possible to do in the future and maybe this extension should be able to do that when that day comes.
Wow, cool! I actually have this extension in my card! Cool! Anywho...ok, well, thanks so much...would anyone be interested in a benchmark dataset or an app to try this on their own card? I intend on writing such an app, but it might be nice to have help...perhaps I can start with an open-source graphics test suite or something. Anyone have any thoughts?
If you want to benchmark these things, you need to be aware that practically every major implementaiton attempts to defer state management until the state is actually needed (ie, you actually draw something).

If you just put a whole bunch of glBindTextures in a loop, it will be quite fast, because basically no work is being done. It will actually be glDrawArrays (or glBegin, or whatever) that takes longer to execute.

The following is a rough grouping of state changes from slowest to fastest. Depending on the given implementation, the list may shift around a bit, but this is a reasonable average.

Program binding
FBO binding
Texture binding
Vertex array specification
Buffer binding
glUniform*
Update current vertex state (glColor, glVertexAttrib, etc).
I knew that much, about the rendering sequence, but thanks

As for the other grouping...thank you for that..it is very useful.

This topic is closed to new replies.

Advertisement