xwininfo fontconfig libX11 libXau libXdmcp libXext mesa libXinerama libxcb libxcb/xcb-proto libfontenc pixman xkbcomp mkfontscale xkeyboard-config git update 4 Jun 2013

xserver          commit c21344add2fc589df83b29be5831c36a372201bd
libxcb           commit 9ae84ad187e2ba440c40f44b8eb21c82c2fdbf12
libxcb/xcb-proto commit bdfedfa57a13ff805580cfacafc70f9cc55df363
xkeyboard-config commit dad9ade4e83d1ef5a517fcc4cc9ad3a79b47acce
libX11           commit 8496122eb00ce6cd5d2308ee54f64b68c378e455
libXdmcp         commit 0b443c1b769b9c9a3b45b4252afe07e18b709ff4
libXext          commit d8366afbb0d2e4fbb1e419b1187f490522270bea
libfontenc       commit 3acba630d8b57084f7e92c15732408711ed5137a
libXinerama      commit 6e1d1dc328ba8162bba2f4694e7f3c706a1491ff
libXau           commit 899790011304c4029e15abf410e49ce7cec17e0a
xkbcomp          commit ed582f4fccd4e23abcfba8b3b03649fea6414f44
pixman           commit 2acfac5f8e097ee2ae225d986f981b55d65dd152
mkfontscale      commit 19e2cb7c6a3ec2c5b1bc0d24866fa685eef0ee13
xwininfo         commit ba0d1b0da21d2dbdd81098ed5778f3792b472e13
fontconfig       commit cd9b1033a68816a7acfbba1718ba0aa5888f6ec7
mesa             commit 7bafd88c153e395274b632e7eae4bc9fc3aec1d2

1 files changed, 0 insertions, 214 deletions

diff --git a/mesalib/docs/MESA_texture_signed_rgba.spec b/mesalib/docs/MESA_texture_signed_rgba.spec
deleted file mode 100644
index e3a6b59af..000000000
--- a/mesalib/docs/MESA_texture_signed_rgba.spec
+++ /dev/null
@@ -1,214 +0,0 @@
-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.