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
