3 performance questions

[KRONOS]

A)
I'm using multitexturing and vertex array, so at any given time, for texture units 0 and 1, they're state is: glEnable(GL_TEXTURE_2D) and glEnableClientState(GL_TEXTURE_ARRAY). But sometimes the geometry doesn't need a second pass, so I disable texturing on unit 1. But should I also disable the ClientState? I don't know if even with texturing disabled, the drivers fetch the texture coordinates because of the ClientState been enabled, even not being necessary...

B)
When using Vertex Array Range, should I put the indices in that memory to? They do not change, so I think that would be a performance boost.

C)
Does S3 and texture compression work only in 32 bits textures? I didn't see any format to work with 16bits textures.

[pocketmoon]

b) Nope - keep you indices in system memory
They don't get accessed in the same way as your actual vertices so sticking them in AGP memory is bad.

[jwatte]

1) disable the client state when you don't want the texture coordinate array to be enabled

2) do not put indices in the vertex array range, as the CPU needs to touch them on their way to the card

3) s3tc is well documented; each 4x4 block of pixels interpolates between two 16-bit color values (although the interpolation is supposed to happen using 32-bit expansions of those)

When it comes to texture compression, offline compressors are likely to give you better quality than letting the driver compress. Any format that can be converted to RGB565 can theorethically be compressed as dxt1, and rgb565:a8 can be compressed as dxt3 or dxt5 (though in practice, dxt5 looks better than dxt3 for the vast majority of cases, and they're the same size)

[evanGLizr]

Originally posted by KRONOS:
A)
I'm using multitexturing and vertex array, so at any given time, for texture units 0 and 1, they're state is: glEnable(GL_TEXTURE_2D) and glEnableClientState(GL_TEXTURE_ARRAY). But sometimes the geometry doesn't need a second pass, so I disable texturing on unit 1. But should I also disable the ClientState? I don't know if even with texturing disabled, the drivers fetch the texture coordinates because of the ClientState been enabled, even not being necessary...



You *must* disable the texcoord client state if your arrays are no longer valid or you don't want to use them, no matter texture is disabled or not. The driver cannot double-guess and not send the texcoords just because texturing is disabled: the app may use the texcoords for something unrelated to texturing, like tangent space coordinate frame calculation in combination with register combiner/fragment shaders or the like.