[Mesa-dev] [PATCH 2/4] mesa: Don't report types for 0-sized components of textures.

[Brian Paul]

On 11/11/2011 11:57 AM, Eric Anholt wrote:
> The GL_TEXTURE_WHATEVER_SIZE entrypoints were checking if the
> specified base type of the texture allowed that channel to be present
> before reporting the size of the channel, so that GL_RGB didn't end up
> with an alpha size if the hardware driver had to store it that way.
>
> The GL_TEXTURE_WHATEVER_TYPE entrypoints weren't checking it, so you
> would end up with strange responses from the GL involving 0-bit
> floating-point alpha components in GL_RGB32F, even though it says
> GL_NONE as expected for other 0-sized channels.
>
> Make _TYPE check _BaseFormat the same as _SIZE, which results in
> fixing most of the GL_RGB* testcases of gl-3.0-required-sized-formats
> pass on i965.
> ---
>   src/mesa/main/texparam.c |  116 ++++++++++++++++++++++++++--------------------
>   1 files changed, 66 insertions(+), 50 deletions(-)
>
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index 17eac5f..e9bed23 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -884,6 +884,67 @@ _mesa_TexParameterIuiv(GLenum target, GLenum pname, const GLuint *params)
>   }
>
>
> +static GLboolean
> +texture_base_type_allows_channel(const struct gl_texture_image *img,
> +				 GLenum pname)

Maybe just pass the base format as the first parameter instead of the 
texture image since that's the only field being accessed.  Then the 
function could be rename "base_type_has_channel()" - it might be 
useful elsewhere someday.  Maybe this could be combined with 
get_component_bits() in fbobject.c

-Brian