Quick Question

Well, two things are that the texture may have to be moved over the bus to the card memory if it's not there already and you may stall the GPU pipeline depending on the architecture and what it was doing at the moment.

Sorry I was quick to respond.

There's not a very straight-forward answer to your question as there are many different approaches to making graphics hardware and at the low level it can be quite different.

At the slightly higher level you have the device driver for the card and OpenGL above that device driver.

Textures are resources and like all resources there's an overhead to managing them. Inside of OpenGl it has to maintain a group of these textures you have given it (which may be 100s or thousands) it has to manage things like keeping them in local (computer) memory and the graphic's card memory. So it has to check things like: is the texture defined? is the new texture in the graphics card memory? if not is there enough space? if not what texture should I eliminate? and things like that.

So as you can see there's potentially alot of overhead to switching a texture and I was describing just one aspect of managing the texture.

That's part of the reason why it's so nice to have an API like OpenGL to take care of stuff like this for us :-)

a texture switch probably requires the chip to do a cache flush (and even if it does the cache will be useless for the new texture anyways) plus any states associated with the texture are required to be set.

Those two reasons alone are good reasons for sorting by texture and minimising state changes

Thanks for the input :)

I was thinking it could be some caching involved, but I have no idea what really goes on down there.

-Trond