glActiveTexture VS glBindTexture efficiency

Assuming the general case (could be IOS / Android, and any GPU that supports OpenGL ES 2.0),
is there an obvious driver overhead difference between glActiveTexture and glBindTexture?

My guess is that glActiveTexture would be the lighter of the two, but I can’t find any proof to support that.

The application I’m looking at uses a texture atlas often, but there are also dynamic textures that are created or manipulated every now and then (and therefore cannot be added to the atlas efficiently).
I’m trying to optimize by keeping the texture atlas at the same texture unit for the lifetime of the program (let us say, unit 0).
The other textures can be used by switching to unit 1 and binding a new texture every time.
Since the atlas is used very often, we don’t have to call glBindTexture every time we want to use it, we simply have to use glActiveTexture (unit 0) and save up on the state change.

Would it make sense to work like that?

(please note this question refers ES 2.0, so no texture arrays are available)

glActiveTexture changes state that is important to the API, but is entirely irrelevant to rendering. glBindTexture changes the bindings of the currently active texture unit. Obviously this state is very relevant to rendering, and therefore such textures must be validated against the current state at render time (such as checking to see if the program’s sampler type for that texture unit matches the texture’s type).

So yes, glBindTexture is the one to minimize as much as possible.

[QUOTE=Alfonse Reinheart;38428]glActiveTexture changes state that is important to the API, but is entirely irrelevant to rendering. glBindTexture changes the bindings of the currently active texture unit. Obviously this state is very relevant to rendering, and therefore such textures must be validated against the current state at render time (such as checking to see if the program’s sampler type for that texture unit matches the texture’s type).

So yes, glBindTexture is the one to minimize as much as possible.[/QUOTE]

Thank you very much, Alfonse.
Do you have any sources for further reading?
I’d love to know more about the internal functionality of the driver for these calls (the only thing that comes into my mind is digging in the MESA source code, but I’m not sure how well it represents real GPUs out there).

Do you have any sources for further reading?

Everything I said is based purely on the OpenGL specification.

The process of rendering, as defined by the spec, does not in any way rely on the active texture unit. That value is used purely as an additional parameter to glBindTexture (as well as the various texture get functions). This is also why newer binding APIs like glBindTextures and glBindTextureUnit don’t use the active texture unit at all.

Whereas the process of rendering does depend on the textures bound to those texture units, which is caused by glBindTexture.

I see, thanks for the comment!

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.