Texture Management

So, now we know that texture objects are the way to go for managing our textures. We load each texture into a texture object, and then bind to the appropriate texture whenever needed. Piece of cake, right? Well, there are still a few things that we need to keep in mind. In our example program, once we loaded and bound all seven textures, we switched textures thirteen times during the rendering of the two cubes and marble floor.

Some consumer OpenGL hardware (such as the i740) handle this texture switching very quickly and efficiently. Deep down in the driver, texture switching amounts to little more than changing a single pointer value. Unfortunately, we can't make this assumption for most hardware. One of the reasons that the i740 is so good at this is because it textures directly from AGP memory. An i740-based AGP graphics card has no local texture memory, so all textures are accessed at roughly equivalent efficiency.

The example program REFLECT_SORTED.EXE rearranges the cube drawing code to draw faces of the two cubes with the same texture together. I won't reprint the code here, but it is horrid to look at. The code performs a great number of transformations and pops them off of the transformation stack as we swap back and forth between the upper cube and the reflected and scaled down cube below the marble floor. While a more elegant solution to texture sorting is desirable, just what this will look like will depend greatly on your own rendering engine. The code shown in the REFLECT_SORTED.CPP source file is meant to demonstrate the concept, not necessarily show the best possible way to do this for a general situation. The difference in frame rate with the ATI AGP graphics card was interesting — we dropped one frame per second. You should benchmark your own code. Texture sorting may not always pay off. I think the difference might be more positive in a real application, with many more textures being swapped to and fro. The amount of texture memory available can also have an influence on the effectiveness of this technique.

While binding textures saves the driver from having to reload and reformat texture data each time it's accessed, it is possible that texture data may still need to be shuffled back and forth between local memory (resident) and either AGP or system memory (not resident on the graphics card). Again, some drivers might consider AGP memory to be resident. Don't pay any attention to what the Intel documentation tells you regarding resident memory. Hardware manufacturers are not all handling resident memory in the same way. Their marketing literature calls it whatever they want, and you're left to fend for yourselves (that's the hard reality of being a developer).