Name

    MESA_texture_signed_rgba

Name Strings

    GL_MESA_texture_signed_rgba

Contact


Notice


IP Status

    No known IP issues

Status


Version

    0.3, 2009-03-24

Number

    Not assigned ?

Dependencies

    Written based on the wording of the OpenGL 2.0 specification.

    This extension trivially interacts with ARB_texture_float.
    This extension shares some language with ARB_texture_compression_rgtc
    but does not depend on it.

Overview

    OpenGL prior to 3.1 does not support any signed texture formats.
    ARB_texture_compression_rgtc introduces some compressed red and
    red_green signed formats but no uncompressed ones, which might
    still be useful. NV_texture_shader adds signed texture formats,
    but also a lot of functionality which has been superseded by fragment
    shaders.
    It is usually possible to get the same functionality
    using a unsigned format by doing scale and bias in a shader, but this
    is undesirable since modern hardware has direct support for this.
    This extension adds a signed 4-channel texture format by backporting
    the relevant features from OpenGL 3.1, as a means to support this in
    OpenGL implementations only supporting older versions.

Issues

    1) What should this extension be called?

       RESOLVED: MESA_texture_signed_rgba seems reasonable.
       The rgba part is there because only 4 channel format is supported.


    2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
       be supported?

       RESOLVED: NO. To keep this extension simple, only add the most
       universal format, rgba. alpha/luminance can't be trivially supported
       since OpenGL 3.1 does not support them any longer, and there is some
       implied dependency on ARB_texture_rg for red/red_green formats so
       avoid all this. Likewise, only 8 bits per channel is supported.


    3) Should this extension use new enums for the texture formats?

       RESOLVED: NO. Same enums as those used in OpenGL 3.1.


    4) How are signed integer values mapped to floating-point values?

       RESOLVED: Same as described in issue 5) of
       ARB_texture_compression_rgtc (quote):
       A signed 8-bit two's complement value X is computed to
       a floating-point value Xf with the formula:

                { X / 127.0, X > -128
           Xf = {
                { -1.0,      X == -128

       This conversion means -1, 0, and +1 are all exactly representable,
       however -128 and -127 both map to -1.0.  Mapping -128 to -1.0
       avoids the numerical awkwardness of have a representable value
       slightly more negative than -1.0.

       This conversion is intentionally NOT the "byte" conversion listed
       in Table 2.9 for component conversions.  That conversion says:

           Xf = (2*X + 1) / 255.0

       The Table 2.9 conversion is incapable of exactly representing
       zero.

       (Difference to ARB_texture_compression_rgtc):
       This is the same mapping as OpenGL 3.1 uses.
       This is also different to what NV_texture_shader used.
       The above mapping should be considered the reference, but there
       is some leeway so other mappings are allowed for implementations which
       cannot do this. Particularly the mapping given in NV_texture_shader or
       the standard OpenGL byte/float mapping is considered acceptable too, as
       might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
       127 (that is, uses different scale factors for negative and positive
       numbers).
       Also, it is ok to store incoming GL_BYTE user data as-is, without
       converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
       and converting back (using the mapping described here).
       Other than those subtle issues there are no other non-standard
       conversions used, so when using for instance CopyTexImage2D with
       a framebuffer clamped to [0,1] all converted numbers will be in the range
       [0, 127] (and not scaled and biased).


    5) How will signed components resulting from RGBA8_SNORM texture
       fetches interact with fragment coloring?

       RESOLVED: Same as described in issue 6) of
       ARB_texture_compression_rgtc (quote):
       The specification language for this extension is silent
       about clamping behavior leaving this to the core specification
       and other extensions.  The clamping or lack of clamping is left
       to the core specification and other extensions.

       For assembly program extensions supporting texture fetches
       (ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
       etc.) or the OpenGL Shading Language, these signed formats will
       appear as expected with unclamped signed components as a result
       of a texture fetch instruction.

       If ARB_color_buffer_float is supported, its clamping controls
       will apply.

       NV_texture_shader extension, if supported, adds support for
       fixed-point textures with signed components and relaxed the
       fixed-function texture environment clamping appropriately.  If the
       NV_texture_shader extension is supported, its specified behavior
       for the texture environment applies where intermediate values
       are clamped to [-1,1] unless stated otherwise as in the case
       of explicitly clamped to [0,1] for GL_COMBINE.  or clamping the
       linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.

       Otherwise, the conventional core texture environment clamps
       incoming, intermediate, and output color components to [0,1].

       This implies that the conventional texture environment
       functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
       using GLSL (and with none of the extensions referred to above)
       is unable to make proper use of the signed texture formats added
       by this extension because the conventional texture environment
       requires texture source colors to be clamped to [0,1].  Texture
       filtering of these signed formats would be still signed, but
       negative values generated post-filtering would be clamped to
       zero by the core texture environment functionality.  The
       expectation is clearly that this extension would be co-implemented
       with one of the previously referred to extensions or used with
       GLSL for the new signed formats to be useful.


    6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
       functions?

       RESOLVED: YES.


    7) What to do with GetTexParameter if ARB_texture_float is supported,
       in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
       TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?

       RESOLVED: ARB_texture_float states type is either NONE,
       UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
       SIGNED_NORMALIZED, which will be returned accordingly. This is the
       same behaviour as in OpenGL 3.1.


New Tokens


    Accepted by the <internalformat> parameter of
    TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:

        RGBA_SNORM                                0x8F93
        RGBA8_SNORM                               0x8F97

    Returned by the <params> parameter of GetTexLevelParameter:

        SIGNED_NORMALIZED                         0x8F9C


Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):

 -- Section 3.8.1, Texture Image Specification

    Add to Table 3.16 (page 154): Sized internal formats

    Sized             Base             R    G    B    A    L    I    D
    Internal Format   Internal Format bits bits bits bits bits bits bits
    ---------------   --------------- ---- ---- ---- ---- ---- ---- ----
    RGBA8_SNORM       RGBA             8    8    8    8    0    0    0


Dependencies on ARB_texture_float extension:

    If ARB_texture_float is supported, GetTexParameter queries with <value>
    of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
    TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
    the base internal format is RGBA_SNORM.