Roland Scheidegger | c6a6cc1 | 2009-03-27 19:39:52 +0100 | [diff] [blame] | 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 superceded 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. Particulary 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. |