1Name
2
3    MESA_texture_signed_rgba
4
5Name Strings
6
7    GL_MESA_texture_signed_rgba
8
9Contact
10
11
12
13Notice
14
15
16
17IP Status
18
19    No known IP issues
20
21Status
22
23
24
25Version
26
27    0.3, 2009-03-24
28
29Number
30
31    Not assigned ?
32
33Dependencies
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
41Overview
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
56Issues
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
183New 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
197Additions 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
209Dependencies 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