1 files changed, 214 insertions, 214 deletions
diff --git a/mesalib/docs/MESA_texture_signed_rgba.spec b/mesalib/docs/MESA_texture_signed_rgba.spec
index bcc4d4203..e3a6b59af 100644
--- a/mesalib/docs/MESA_texture_signed_rgba.spec
+++ b/mesalib/docs/MESA_texture_signed_rgba.spec
@@ -1,214 +1,214 @@
-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.
+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.