Does the cost of the glBindTexture call depend on the size of the texture, or does it only change some internal pointer in the video card?

Hello there...

I had tried to calculate the time spent in some OpenGL functions a while ago, using a custom made spy program of mine. If i assume it worked correct (and it should ), then what i have found is that, glBindTexture() time is depended on the texture itself. Not exactly its size. If i remember correct, the time spent for a specific texture on a specific run of the application was constant over the whole run, but different between textures, despite they had the same dimensions.

Don''t worry about the time on glBindTexture. Its something nead 0.005 - 0.01 msec for textures up to 512x512 (the biggest textures i use). I don''t know if, for bigger textures the time will be greater, but i don''t think so.

In other words, the time wanted to execute glBindTexture() is depended on texture''s dimensions, data, and its OpenGL id (the place in memory it reserves). Hope this is correct

HellRaiZer

thats interesting, as everybody says that texture changes are something to avoid. out of curiosity: did you measure the time the function call took or found a way to measure how much time it really takes "on the card"? rendering 100 million triangles looks fast too if i only measure the time for the call to drawelements ,-)

Of course a naive timing of glBindTexture() might make it look like being free - all it does is to place a texture change command sequence into the GPU FIFO. In the best case (driver dependent), it just sets an internal flag. The real impact of the bind comes later. Don't forget that the GPU runs in parallel.

The exact moment when the texture is changed depends on hardware and drivers. A driver will rarely trigger the texture change when a glBindTexture() command is issued. Most will do it on first use of that newly bound texture (by glVertex(), glDrawElements(), etc). So the overhead is actually carried over to a different command.

That said, yes, state changes are generally very expensive. Although everything is relative, and it depends on what you consider as being "expensive". Binding 20 textures per frame is no problem. Binding 2000 per frame definitely is. Keep in mind that a texture state change is not simply changing a pointer. It's invalidating the cache, changing the entire state set associated with that texture (clamping mode, filters, shadowmap params, mipmap generation, env combining modes, etc, everything associated with the binding state - consult the OpenGL specs for details). Even worse, what if the texture is currently not in VRAM ? Well, the driver has to upload an internal copy over the AGP bus. Depending on texture size, that can take a long time.

Basically, if you only use the binding to actually bind the texture visible per frame once, you should be fine. But, for example, having a non-state sorted triangle set will kill your performance. Never change states, if not needed.


[edited by - Yann L on October 17, 2003 11:00:04 AM]

quote:Original post by citizen3019
Since OGL is a state machine, then if clamp modes filters, etc. are the same for two different textures, will it change all of those params to the same thing again? Or maybe the cost is still incurred due to the envelope change check? Or maybe , if you try to keep your texture envelopes somewhat similar than you can reduce even that overhead...?

This is extremely chipset dependent. The detailed behaviour of texture sampler substates will vary from one chipset to the next. It might even change from one driver revision to the next. The internal details are often classified, and require an NDA with the chipset manufacturer.

Don''t optimize on those automatically set substates, because the result will be unreliable. Your optimizations might even make your code run slower on some other hardware. Optimize on the states you set manually, because those are the ones you can actively control. Typically, a sort by texture is more than enough. Just make sure to not bind the same texture multiple times per frame, unless it is unavoidable (multipass approaches come to mind).

quote:
thats interesting, as everybody says that texture changes are something to avoid. out of curiosity: did you measure the time the function call took or found a way to measure how much time it really takes "on the card"? rendering 100 million triangles looks fast too if i only measure the time for the call to drawelements ,-)

Of course i meant the function call! I''m not nVidia.

Ok sorry for the misunderstanding. From his question, i thought he wanted the function call time. Some times i tend to forget valuable and important details when posting an answer, only because my answer was the first thing that came to my mind It''s weird, isn''t it?

HellRaiZer

*lol* if i had known that yann will give such a detailed explanation i might not even have asked. but then, i really would have been interested in a way to measure the time when the command is really executed.