Redundant texture switches

[Leadwerks]

I just wanted to make sure of something. If I bind a texture that is already bound, is that just as expensive as switching a texture? Does OpenGL know that the texture is already bound, or does it just re-bind it regardless? My guess is it re-binds it in order to make it so OpenGL does exactly what you tell it to do.

[Brolingstanz]

my guess is that most drivers check for the redundant bind, but it's not specified wither way (implementation dependent thing).

[Brolingstanz]

you could probably devise an elaborate performance test to verify this one way or another... if you've got some extra time to waste. Might be better time wasted simply checking for this yourself. That's waht I do......... and probably most everyone else ;-)

[knackered]

your performance test would show it's cheaper to check first yourself, otherwise you'll be paying for simply calling glBindTexture. Not much maybe, but significant cpu work if you have lots of texture binds. Personally I have a very lightweight inline'd layer between me and GL, and do a redundancy check on every state change. I pay nothing for a function call if it's redundant, but pay twice for a redundancy check if the driver's already doing one, but it will work out cheaper overall. I remember asking an nvidia driver writer years ago if they do a redundancy check, and he told me they don't under the assumption that the app will be doing it's own, so it would be repeating work that should already have been done. Maybe things have changed in recent years.

[Jan]

AFAIK drivers do redundancy checks for very expensive operations like shader and texture switches. Though to be sure, do your own checks, too.

Jan.

[Relic]

It's surely faster to do your own state cache and avoid calling into OpenGL if you don't need to.
A simple comparison is faster than calling any function.

Calling into the OpenGL implementation under Windows involves a function call into OpenGL32.dll, a jump to the ICD, error checks on the user parameters and *finally* it can check if the call was redundant and return.

Also never do something like glIsEnabled or glGet to query the state and then set it if it's different. (The only exception would be in a library which needs to restore an application's OpenGL state.)

[knackered]

Jan, I don't think nvidia drivers would do any redundancy checks in the application thread (their drivers are multithreaded). So you'll be paying the price of queueing up a command with all its parameters at the very least.

[Jan]

True. But IF you do a redundant state-change, it will still not be as bad as it was, if it wasn't rejected, at all.

But i agree completely, that a professional program should do redundancy checks for all states. With textures and shaders that's actually very easy, for all the small states, that OpenGL 2.x exposes it can be a bit annoying to write a complete wrapper for the whole API (though, again, professional software should do it).

With OpenGL 3's new state-blocks etc. it should be very easy to do redundancy checks for absolutely every state-change.

Jan.

[V-man]

I have not benchmarked this recently but a long time ago I just stuck a simple check for the texture ID. The performance went up by 2 or 3x. The code was making a lot of glBindTexture calls.
It's been said on these boards that drivers don't do redundancy check so it must be true. It applies to both NV and ATI.

Calling into the OpenGL implementation under Windows involves a function call into OpenGL32.dll, a jump to the ICD, error checks on the user parameters and *finally* it can check if the call was redundant and return.

Jump to opengl32.dll happens for GL 1.1 functions.