2008/8/24 Stefan Dösinger stefan@codeweavers.com:
No, I meant to clamp it by the constant MAX_TEXTURES(=8). gl_info->max_textures is wrong here because gl_info->max_textures could be 4, GL_MAX_TEXTURE_COORDS could be 8. If the application uses fixed function vertex processing and pixel shaders it can make use of all 8 texture coords in the vertex pipeline even though the fixed function fragment pipeline supports only 4 textures. Or we could use the arbfp code which isn't limited by gl_info->max_textures.
Ok, I wasn't sure. Wrt arbfp though, it should report 8 for max_textures in that case, because that's how much simultaneous textures d3d can address. max_textures, max_texture_stages, etc. are the limits for what our d3d implementation can do, not GL.
You mean instead of textureNo? I don't think so. A stage is always mapped to a lower one, so I think we cannot trigger an error here. Dealing with all supported texture units here spares the loop below.
You probably can't trigger an error, but you might miss coordinates for a high texture stage that's mapped to a lower texture unit. I also don't think we should rely on details of how stages are mapped to units if we can avoid it.
- if (GL_SUPPORT(NV_REGISTER_COMBINERS)) {
/* The number of the mapped stages increases monotonically,so it's fine to use the last used one */
for (textureNo = mapped_stage + 1; textureNo <GL_LIMITS(textures); ++textureNo) {
GL_EXTCALL(glMultiTexCoord4fARB(GL_TEXTURE0_ARB +textureNo, 0, 0, 0, 1));
}- }
I'm probably missing something here, but why is it safe to remove that?
Because we have handled all supported texture units in the loop above. and supplied it with default coordinates if needed.
Except that we haven't. We've looped through the first max_texture_coords texture stages, but there's not guarantee that those stages also touch the first max_texture_coords units. In fact, unless you're using a 1:1 mapping, it's guaranteed they don't.
In the bigger picture, these various limits are pretty tricky to get right, I wonder if it might make more sense to handle most of this stuff in the tex unit map instead. That way we could be sure that if a stage is mapped to a sampler that sampler is safe to use.
While this sounds nice I am afraid it won't work too well. Beyond specifying the new settings we have to do other things like unsetting unneeded states, etc, so I don't think we can keep the state mappings all in one place. My other concern is that different pipeline implementations need different limits.
If you can guarantee that a texture unit isn't mapped when it isn't used, you can just walk through the rev_tex_unit_map and find the corresponding texture stage. That makes much more sense from GL's point of view.