Jump to content
  • Advertisement
Sign in to follow this  
WhatEver

OpenGL glBindTexture - what is the technical reason that it is slow?

This topic is 1227 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been looking all over the place for an answer to this question and I'm only getting bits and pieces of the answer. I learned the hard way a long time ago that calling glBindTexture is relatively slow; I found out from a friend of mine that it was because I was binding the texture every time I drew a triangle lol! The simple fact is that calling glBindTexture comes at a price, and minimizing calls is always the best choice!

 

Anyway, there's a reason it's slower than most other function calls that change the opengl states, and I'm looking for the technical answer.

 

So far, with my limited understanding of hardware in general, the main reason I think it's slow is because every time you call glBindTexture, the hardware copies the texture from Texture RAM into the Texture Cache because the Cache is faster to read from. Although the copy is fast in it's own right, copying larger textures should take longer than smaller textures, and if done enough times no matter the size of the texture, will become a performance bottleneck.

 

Yes/No? Is there more to it than that?

Share this post


Link to post
Share on other sites
Advertisement
There's no copying going on, generally, unless your GPU is very memory constrained.

It's mostly a driver issue and more to do with flushing states out to the execution cores, how shaders are scheduled, how the resource binding tables are configured, flipping read/write states on textures automagically for you, swapping out sampler states (since those are embedded into the texture in older OpenGL versions), and so on.

In other words, it can be super super fast. The driver - and the specific call you're referring to, glBindTexture - is slow. Switch to bindless approaches and you'll see it get much faster.

Share this post


Link to post
Share on other sites

I'm a little confused. Is glBindTexture still slow, but not for the reason I thought, and it's been replaced by a different function: a bindless function?

Share this post


Link to post
Share on other sites

Never mind, it just sunk in. It doesn't seem like that would be the reasons for being so slow, but I don't really understand the hardware.

 

What's the bind-less function thing you're talking about?

Share this post


Link to post
Share on other sites

Never mind, it just sunk in. It doesn't seem like that would be the reasons for being so slow, but I don't really understand the hardware.
 
What's the bind-less function thing you're talking about?


Modern hardware doesn't bind texture slots. It has a huge giant array of resources. Some hardware uses separate arrays for different kinds of resources while some hardware mixes a certain subset of resources into one array.

Bindless is a feature of very recent OpenGL and Direct3D versions. All that "bindless" means in this case is that you don't have to call the various 'glBind*' functions to swap resources; instead, your shader indexes into these arrays to get at the resources. It's slightly more complicated than that, but not too much.

You may have to use texture arrays to simulate bindless textures for compatibility reasons. If you just google "opengl bindless textures" you'll find plenty of materials on the subject. Google "AZDO OpenGL" (AZDO is an acronym that derives from the name of a presentation from a few years back titled "Approaching Zero Driver Overhead") you'll find materials on both bindless resources and some other modern GPU programming primitives.

Share this post


Link to post
Share on other sites

Ha, so much has changed since I last wrote an OpenGL program! Thanks for the clarification and insight into the latest generation of graphics acceleration.

Share this post


Link to post
Share on other sites

You can have a look at what a typical texture bind involve here :

http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/texobj.c

As you can see looking at _mesa_test_texobj_completeness it's far from being trivial.

 

There are also state revalidation involved when a call to glDraw* is issued : texture type must match the one expected by the shader, the driver must add a barrier or a cache flush if the texture was previously used as a result of a draw call or a dma transfer, for instance.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!