mesa: Disallow deprecated SNORM formats for renderbuffers
mesa: Disallow deprecated SNORM formats for renderbuffers

The OpenGL 3.2 core profile spec says:

    "The following base internal formats from table 3.11 are
    color-renderable: RED, RG, RGB, and RGBA. The sized internal formats
    from table 3.12 that have a color-renderable base internal format
    are also color-renderable. No other formats, including compressed
    internal formats, are color-renderable."

The OpenGL 3.2 compatibility profile spec says (only ALPHA is added):

    "The following base internal formats from table 3.16 are
    color-renderable: ALPHA, RED, RG, RGB, and RGBA. The sized internal formats
    from table 3.17 that have a color-renderable base internal format
    are also color-renderable. No other formats, including compressed
    internal formats, are color-renderable."

Table 3.12 in the core profile spec and table 3.17 in the compatibility
profile spec list SNORM formats as having a base internal format of RED,
RG, RGB, or RGBA.  From this we infer that they should also be color
renderable.

The OpenGL ES 3.0 spec says:

    "An internal format is color-renderable if it is one of the formats
    from table 3.12 noted as color-renderable or if it is unsized format
    RGBA or RGB. No other formats, including compressed internal
    formats, are color-renderable."

In the OpenGL ES 3.0 spec, none of the SNORM formats have "color-
renderable" marked in table 3.12.  The RGB I and UI formats also are not
color-renderable in ES3, but we'll save that change for another patch.

Both NVIDIA's closed-source driver (version 304.64) and AMD's
closed-source driver (Catalyst 12.6 on HD 3650) reject *all* SNORM
formats for renderbuffers in OpenGL 3.3 compatibility profiles.

v2: Move {RED,RG,RGB,RGBA}_SNORM changes from the this commit to the
next commit.  Based on suggestions from Ken.

Signed-off-by: Ian Romanick <2b237cafb16dc45038e85df6c85e74e6d899eba9@intel.com>
Reviewed-by: Marek Olšák <74bac9a67a04041c3586cda013cc5a11352e67be@gmail.com>
Reviewed-by: Kenneth Graunke <bd2562f754ec92342f93f61c25d731e290a2ffa8@whitecape.org>
Reviewed-by: Eric Anholt <96f164ad4d9b2b0dacf8ebee2bb1eeb3aa69adf1@anholt.net>

zeux/glsl-optimizer,djreep81/glsl-optimizer,tokyovigilante/glsl-optimizer,mapbox/glsl-optimizer,dellis1972/glsl-optimizer,benaadams/glsl-optimizer,bkaradzic/glsl-optimizer,djreep81/glsl-optimizer,mcanthony/glsl-optimizer,dellis1972/glsl-optimizer,zeux/glsl-optimizer,dellis1972/glsl-optimizer,metora/MesaGLSLCompiler,mapbox/glsl-optimizer,zeux/glsl-optimizer,zz85/glsl-optimizer,bkaradzic/glsl-optimizer,zz85/glsl-optimizer,mapbox/glsl-optimizer,zz85/glsl-optimizer,djreep81/glsl-optimizer,metora/MesaGLSLCompiler,mcanthony/glsl-optimizer,zz85/glsl-optimizer,bkaradzic/glsl-optimizer,jbarczak/glsl-optimizer,benaadams/glsl-optimizer,djreep81/glsl-optimizer,tokyovigilante/glsl-optimizer,benaadams/glsl-optimizer,bkaradzic/glsl-optimizer,jbarczak/glsl-optimizer,wolf96/glsl-optimizer,wolf96/glsl-optimizer,wolf96/glsl-optimizer,zz85/glsl-optimizer,mapbox/glsl-optimizer,zeux/glsl-optimizer,tokyovigilante/glsl-optimizer,jbarczak/glsl-optimizer,mcanthony/glsl-optimizer,mcanthony/glsl-optimizer,mcanthony/glsl-optimizer,tokyovigilante/glsl-optimizer,tokyovigilante/glsl-optimizer,djreep81/glsl-optimizer,zeux/glsl-optimizer,mapbox/glsl-optimizer,jbarczak/glsl-optimizer,benaadams/glsl-optimizer,benaadams/glsl-optimizer,dellis1972/glsl-optimizer,jbarczak/glsl-optimizer,dellis1972/glsl-optimizer,bkaradzic/glsl-optimizer,metora/MesaGLSLCompiler,wolf96/glsl-optimizer,benaadams/glsl-optimizer,zz85/glsl-optimizer,wolf96/glsl-optimizer