State sorting performance questions.

Hi,

I’m trying to write a rending engine that minimizes state changes by sorting objects by the opengl state that they require to render. This is a two part question:

  1. Currently I’m planning to try preserve video memory by keeping texture parameters (eg filtering, wrapping, etc) separate from the opengl texture id and hence the texture data. This seems better if say a texture is loaded twice with different filtering, then the bitmap data isn’t duplicated (I’m already reference counting and using handle objects to my application’s internal texture objects). The downside of this is that it adds more complexity to my code since there are more redundant calls to check for and it means I have to do more than a glBindTexture when I change textures as I render the frame. Is this a false economy? Is changing the texture parameters expensive enough that it warrants creating two textures?

  2. Can anybody point me towards some kind of chart that ranks opengl operations by approximately how expensive they are? I want to make sure I’m not wasting time and adding complexity by doing unnecessary “optimization” Or is this completely driver/hardware dependent?

Thanks,
Lucas

First, let me make sure I understand you correctly. You’re creating an OpenGL texture object and uploading the image as usual. Then, when you go to use the texture for rendering, you apply the filtering and texture coordinate addressing modes. Is this correct?

This generally isn’t a performance problem. Usually binding a texture is expensive, but changing the addressing and filtering modes is usually pretty cheap.

Some other related food for thought (may or may not be applicable):
This is a relatively uncommon case for me (I’m not sure about your usage however). For the most part, I keep filtering as a quality option for the user to decide as there is usually a direct quality->performance trade off (some textures, such as lookup tables, I handle differently however).

  • Kevin B

Yup, that’s exactly it.

Based on what you said, I think i’ll just keep doing it this way since it wont have noticable performace hit and in bizarre cases where somebody wants to load multiple verions of the same texture with differnt parameters it wont choke and waste video memory. Although at least I only have to sort by texture object and not by filtering paramters too though.