Archived

This topic is now archived and is closed to further replies.

Raloth

glBindTexture cost

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
yep, glBindTexture is quite free.

If you are timing texture-loading - when uploading a texture each frame (real-time) use glTexSubImage2D instead of glTexImage2D - i found it to be MUCH MUCH faster. sometimes glTexImage2D took ~10ms and glTexSubImage2D took 0.1ms.

Oh noes! GameDev just went down !!
EDIT: back online again

[ My Site ]
'I wish life was not so short,' he thought. 'Languages take such a time, and so do all the things one wants to know about.' - J.R.R Tolkien
/*ilici*/


[edited by - Ilici on October 17, 2003 9:21:37 AM]

Share this post


Link to post
Share on other sites
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 ,-)

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
quote:
Original post by Yann L
...yes, state changes are generally very expensive...Keep in mind that a texture state change is not simply changing a pointer. It's...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....



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...?

If someone with more knowledge could clear this up?


[edited by - citizen3019 on October 17, 2003 11:05:25 AM]

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
*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.

Share this post


Link to post
Share on other sites