← Back to branch summary

~mmach/netext73/mesa-haswell

« back to all changes in this revision

Viewing changes to docs/_extra/specs/MESA_texture_signed_rgba.spec

  • Committer: mmach
  • Date: 2022-09-22 19:56:13 UTC
  • Revision ID: netbit73@gmail.com-20220922195613-wtik9mmy20tmor0i
2022-09-22 21:17:09

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/_extra/specs/MESA_texture_signed_rgba.spec
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.