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 parameter of TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: RGBA_SNORM 0x8F93 RGBA8_SNORM 0x8F97 Returned by the 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 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.