Home | History | Annotate | Download | only in specs
      1 Name
      2 
      3     MESA_texture_signed_rgba
      4 
      5 Name Strings
      6 
      7     GL_MESA_texture_signed_rgba
      8 
      9 Contact
     10 
     11 
     12 
     13 Notice
     14 
     15 
     16 
     17 IP Status
     18 
     19     No known IP issues
     20 
     21 Status
     22 
     23 
     24 
     25 Version
     26 
     27     0.3, 2009-03-24
     28 
     29 Number
     30 
     31     Not assigned ?
     32 
     33 Dependencies
     34 
     35     Written based on the wording of the OpenGL 2.0 specification.
     36 
     37     This extension trivially interacts with ARB_texture_float.
     38     This extension shares some language with ARB_texture_compression_rgtc
     39     but does not depend on it.
     40 
     41 Overview
     42 
     43     OpenGL prior to 3.1 does not support any signed texture formats.
     44     ARB_texture_compression_rgtc introduces some compressed red and
     45     red_green signed formats but no uncompressed ones, which might
     46     still be useful. NV_texture_shader adds signed texture formats,
     47     but also a lot of functionality which has been superseded by fragment
     48     shaders.
     49     It is usually possible to get the same functionality
     50     using a unsigned format by doing scale and bias in a shader, but this
     51     is undesirable since modern hardware has direct support for this.
     52     This extension adds a signed 4-channel texture format by backporting
     53     the relevant features from OpenGL 3.1, as a means to support this in
     54     OpenGL implementations only supporting older versions.
     55 
     56 Issues
     57 
     58     1) What should this extension be called?
     59 
     60        RESOLVED: MESA_texture_signed_rgba seems reasonable.
     61        The rgba part is there because only 4 channel format is supported.
     62 
     63 
     64     2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
     65        be supported?
     66 
     67        RESOLVED: NO. To keep this extension simple, only add the most
     68        universal format, rgba. alpha/luminance can't be trivially supported
     69        since OpenGL 3.1 does not support them any longer, and there is some
     70        implied dependency on ARB_texture_rg for red/red_green formats so
     71        avoid all this. Likewise, only 8 bits per channel is supported.
     72 
     73 
     74     3) Should this extension use new enums for the texture formats?
     75 
     76        RESOLVED: NO. Same enums as those used in OpenGL 3.1.
     77 
     78 
     79     4) How are signed integer values mapped to floating-point values?
     80 
     81        RESOLVED: Same as described in issue 5) of
     82        ARB_texture_compression_rgtc (quote):
     83        A signed 8-bit two's complement value X is computed to
     84        a floating-point value Xf with the formula:
     85 
     86                 { X / 127.0, X > -128
     87            Xf = {
     88                 { -1.0,      X == -128
     89 
     90        This conversion means -1, 0, and +1 are all exactly representable,
     91        however -128 and -127 both map to -1.0.  Mapping -128 to -1.0
     92        avoids the numerical awkwardness of have a representable value
     93        slightly more negative than -1.0.
     94 
     95        This conversion is intentionally NOT the "byte" conversion listed
     96        in Table 2.9 for component conversions.  That conversion says:
     97 
     98            Xf = (2*X + 1) / 255.0
     99 
    100        The Table 2.9 conversion is incapable of exactly representing
    101        zero.
    102 
    103        (Difference to ARB_texture_compression_rgtc):
    104        This is the same mapping as OpenGL 3.1 uses.
    105        This is also different to what NV_texture_shader used.
    106        The above mapping should be considered the reference, but there
    107        is some leeway so other mappings are allowed for implementations which
    108        cannot do this. Particularly the mapping given in NV_texture_shader or
    109        the standard OpenGL byte/float mapping is considered acceptable too, as
    110        might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
    111        127 (that is, uses different scale factors for negative and positive
    112        numbers).
    113        Also, it is ok to store incoming GL_BYTE user data as-is, without
    114        converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
    115        and converting back (using the mapping described here).
    116        Other than those subtle issues there are no other non-standard
    117        conversions used, so when using for instance CopyTexImage2D with
    118        a framebuffer clamped to [0,1] all converted numbers will be in the range
    119        [0, 127] (and not scaled and biased).
    120 
    121 
    122     5) How will signed components resulting from RGBA8_SNORM texture
    123        fetches interact with fragment coloring?
    124 
    125        RESOLVED: Same as described in issue 6) of
    126        ARB_texture_compression_rgtc (quote):
    127        The specification language for this extension is silent
    128        about clamping behavior leaving this to the core specification
    129        and other extensions.  The clamping or lack of clamping is left
    130        to the core specification and other extensions.
    131 
    132        For assembly program extensions supporting texture fetches
    133        (ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
    134        etc.) or the OpenGL Shading Language, these signed formats will
    135        appear as expected with unclamped signed components as a result
    136        of a texture fetch instruction.
    137 
    138        If ARB_color_buffer_float is supported, its clamping controls
    139        will apply.
    140 
    141        NV_texture_shader extension, if supported, adds support for
    142        fixed-point textures with signed components and relaxed the
    143        fixed-function texture environment clamping appropriately.  If the
    144        NV_texture_shader extension is supported, its specified behavior
    145        for the texture environment applies where intermediate values
    146        are clamped to [-1,1] unless stated otherwise as in the case
    147        of explicitly clamped to [0,1] for GL_COMBINE.  or clamping the
    148        linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
    149 
    150        Otherwise, the conventional core texture environment clamps
    151        incoming, intermediate, and output color components to [0,1].
    152 
    153        This implies that the conventional texture environment
    154        functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
    155        using GLSL (and with none of the extensions referred to above)
    156        is unable to make proper use of the signed texture formats added
    157        by this extension because the conventional texture environment
    158        requires texture source colors to be clamped to [0,1].  Texture
    159        filtering of these signed formats would be still signed, but
    160        negative values generated post-filtering would be clamped to
    161        zero by the core texture environment functionality.  The
    162        expectation is clearly that this extension would be co-implemented
    163        with one of the previously referred to extensions or used with
    164        GLSL for the new signed formats to be useful.
    165 
    166 
    167     6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
    168        functions?
    169 
    170        RESOLVED: YES.
    171 
    172 
    173     7) What to do with GetTexParameter if ARB_texture_float is supported,
    174        in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
    175        TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
    176 
    177        RESOLVED: ARB_texture_float states type is either NONE,
    178        UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
    179        SIGNED_NORMALIZED, which will be returned accordingly. This is the
    180        same behaviour as in OpenGL 3.1.
    181 
    182 
    183 New Tokens
    184 
    185 
    186     Accepted by the <internalformat> parameter of
    187     TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
    188 
    189         RGBA_SNORM                                0x8F93
    190         RGBA8_SNORM                               0x8F97
    191 
    192     Returned by the <params> parameter of GetTexLevelParameter:
    193 
    194         SIGNED_NORMALIZED                         0x8F9C
    195 
    196 
    197 Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
    198 
    199  -- Section 3.8.1, Texture Image Specification
    200 
    201     Add to Table 3.16 (page 154): Sized internal formats
    202 
    203     Sized             Base             R    G    B    A    L    I    D
    204     Internal Format   Internal Format bits bits bits bits bits bits bits
    205     ---------------   --------------- ---- ---- ---- ---- ---- ---- ----
    206     RGBA8_SNORM       RGBA             8    8    8    8    0    0    0
    207 
    208 
    209 Dependencies on ARB_texture_float extension:
    210 
    211     If ARB_texture_float is supported, GetTexParameter queries with <value>
    212     of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
    213     TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
    214     the base internal format is RGBA_SNORM.
    215