[10/10] WineD3D: Sort out some limit confusion

[Henri Verbeet]

2008/8/24 Stefan Dösinger <stefan at 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.