Hello
Please check the two scenarios below,
I just would like to know which order of commands is faster and advised:
Within one frame:
Calling glUseProgramObjectARB(…) only once
then calling 100 glBindTexture(GL_TEXTURE_2D,…)
– OR –
Within one frame:
Calling glBindTexture(GL_TEXTURE_2D,…) only once
then calling 100 glUseProgramObjectARB(…)
I need to design the dataset only, but no opportunity to test their performance myself 
Let me know if i should describe the scenario more.
Thank You
The texture changes should be much faster, but to be honest a lot of your performance is going to hinge on what you do in your shaders too.
Can I just add…it really depends upon the uniforms and vertex attributes you are throwing at those shaders.
I would have to agree with what’s already been said…the tetxure binding operation is a lot simpler for GL than switching shaders and therefore faster.
Perhaps, if the textures are all the same size, you could organise the 100 textures into a 2D Array texture. That way you wont be switching anything and just selecting the slice via a uniform change.
Thank You for answer Mhagain
So You think the first approach is the fastest one ?
Each shader will have different complexity.
From a basic multi-texturing up to a per-pixel lighted bumpmapping.
To be more exact on my case:
within one frame, i will have about 10 different shader program change and each one of them is used to draw primitives with different-different 2D textures applied.
Cheers
Hello BionicBytes
Regarding the uniform and vertex attributes:
Actually a lot of such values are passed to the shaders:
Per Vertex: TBN values, Heightmap coverage values, etc…
Uniform: Current time, FPS interval, etc …
So in one word: a lot of data passed to the shaders.
Good idea the texture size trick 
unfortunately the texture sizes are so different.
Thank You
Correct, yes. A shader change is actually one of the slowest operations you can do, but to be honest arranging your data sensibly and batching stuff which has common states together properly is far more important than either.
Correct, yes. A shader change is actually one of the slowest operations you can do, but to be honest arranging your data sensibly and batching stuff which has common states together properly is far more important than either. [/QUOTE]
Thank You, its a shame :o but may I expand the question a bit more with the same pattern:
Within one frame:
Calling glBindTexture(GL_TEXTURE_2D,…) only once
then calling 100 glTranslatef(…)
– OR –
Within one frame:
Calling glTranslatef(…) only once
then calling 100 glBindTexture(GL_TEXTURE_2D,…)
I have already read the FAQ of OpenGL about “overusing” glTranslatef …
Consider using a texture atlas to handle this. See this gamedev.net post for lots of resources. You may be able to bind just one shader and one texture.
For the relative cost of various state changes, see Tom Forsyth’s Renderstate change costs:
http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Renderstate%20change%20costs]]]
Regards,
Patrick
Thank You all for the answer and help !
[i would put this thread to resolved status but no idea how :o ]
I’d like to piggyback on this thread and ask: What is faster:
100 glUseProgramObjectARB()
or just
1 glUseProgramObjectARB() and
100 glUniform*()
I’ve read a paper encouraging shader writers to implement more than 1 materials in 1 shader. This, however, means conditionals, which are a no-no in a shader.
Yes, it is recommended for several years now.
This is not true, as actually conditionals are very fast as long as branch selection is somewhat coherent.