• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    EXT_packed_float
4
5Name Strings
6
7    GL_EXT_packed_float
8    WGL_EXT_pixel_format_packed_float
9    GLX_EXT_fbconfig_packed_float
10
11Contact
12
13    Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
14
15Status
16
17    Preliminary
18
19Version
20
21    Date: February 15, 2006
22    Revision: 0.3
23
24Number
25
26    328
27
28Dependencies
29
30    OpenGL 1.1 required
31
32    ARB_color_buffer_float affects this extension.
33
34    EXT_texture_shared_exponent trivially affects this extension.
35
36    EXT_framebuffer_object affects this extension.
37
38    WGL_ARB_pixel_format is required for use with WGL.
39
40    WGL_ARB_pbuffer affects WGL pbuffer support for this extension.
41
42    GLX 1.3 is required for use with GLX.
43
44    This extension is written against the OpenGL 2.0 (September 7,
45    2004) specification.
46
47Overview
48
49    This extension adds a new 3-component floating-point texture format
50    that fits within a single 32-bit word.  This format stores 5 bits
51    of biased exponent per component in the same manner as 16-bit
52    floating-point formats, but rather than 10 mantissa bits, the red,
53    green, and blue components have 6, 6, and 5 bits respectively.
54    Each mantissa is assumed to have an implied leading one except in the
55    denorm exponent case.  There is no sign bit so only non-negative
56    values can be represented.  Positive infinity, positive denorms,
57    and positive NaN values are representable.  The value of the fourth
58    component returned by a texture fetch is always 1.0.
59
60    This extension also provides support for rendering into an unsigned
61    floating-point rendering format with the assumption that the texture
62    format described above could also be advertised as an unsigned
63    floating-point format for rendering.
64
65    The extension also provides a pixel external format for specifying
66    packed float values directly.
67
68New Procedures and Functions
69
70    None
71
72New Tokens
73
74    Accepted by the <internalformat> parameter of TexImage1D,
75    TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and
76    RenderbufferStorageEXT:
77
78        R11F_G11F_B10F_EXT                            0x8C3A
79
80    Accepted by the <type> parameter of DrawPixels, ReadPixels,
81    TexImage1D, TexImage2D, GetTexImage, TexImage3D, TexSubImage1D,
82    TexSubImage2D, TexSubImage3D, GetHistogram, GetMinmax,
83    ConvolutionFilter1D, ConvolutionFilter2D, ConvolutionFilter3D,
84    GetConvolutionFilter, SeparableFilter2D, GetSeparableFilter,
85    ColorTable, ColorSubTable, and GetColorTable:
86
87        UNSIGNED_INT_10F_11F_11F_REV_EXT              0x8C3B
88
89    Accepted by the <pname> parameters of GetIntegerv, GetFloatv, and
90    GetDoublev:
91
92        RGBA_SIGNED_COMPONENTS_EXT                    0x8C3C
93
94    Accepted as a value in the <piAttribIList> and <pfAttribFList>
95    parameter arrays of wglChoosePixelFormatARB, and returned in the
96    <piValues> parameter array of wglGetPixelFormatAttribivARB, and the
97    <pfValues> parameter array of wglGetPixelFormatAttribfvARB:
98
99        WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT              0x20A8
100
101    Accepted as values of the <render_type> arguments in the
102    glXCreateNewContext and glXCreateContext functions
103
104        GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT              0x20B1
105
106    Returned by glXGetFBConfigAttrib (when <attribute> is set to
107    GLX_RENDER_TYPE) and accepted by the <attrib_list> parameter of
108    glXChooseFBConfig (following the GLX_RENDER_TYPE token):
109
110        GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT                0x00000008
111
112Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation)
113
114 -- Add two new sections after Section 2.1.2, (page 6):
115
116    2.1.A  Unsigned 11-Bit Floating-Point Numbers
117
118    An unsigned 11-bit floating-point number has no sign bit, a 5-bit
119    exponent (E), and a 6-bit mantissa (M).  The value of an unsigned
120    11-bit floating-point number (represented as an 11-bit unsigned
121    integer N) is determined by the following:
122
123        0.0,                      if E == 0 and M == 0,
124        2^-14 * (M / 64),         if E == 0 and M != 0,
125        2^(E-15) * (1 + M/64),    if 0 < E < 31,
126        INF,                      if E == 31 and M == 0, or
127        NaN,                      if E == 31 and M != 0,
128
129    where
130
131        E = floor(N / 64), and
132        M = N mod 64.
133
134    Implementations are also allowed to use any of the following
135    alternative encodings:
136
137        0.0,                      if E == 0 and M != 0
138        2^(E-15) * (1 + M/64)     if E == 31 and M == 0
139        2^(E-15) * (1 + M/64)     if E == 31 and M != 0
140
141    When a floating-point value is converted to an unsigned 11-bit
142    floating-point representation, finite values are rounded to the closet
143    representable finite value.  While less accurate, implementations
144    are allowed to always round in the direction of zero.  This means
145    negative values are converted to zero.  Likewise, finite positive
146    values greater than 65024 (the maximum finite representable unsigned
147    11-bit floating-point value) are converted to 65024.  Additionally:
148    negative infinity is converted to zero; positive infinity is converted
149    to positive infinity; and both positive and negative NaN are converted
150    to positive NaN.
151
152    Any representable unsigned 11-bit floating-point value is legal
153    as input to a GL command that accepts 11-bit floating-point data.
154    The result of providing a value that is not a floating-point number
155    (such as infinity or NaN) to such a command is unspecified, but must
156    not lead to GL interruption or termination.  Providing a denormalized
157    number or negative zero to GL must yield predictable results.
158
159    2.1.B  Unsigned 10-Bit Floating-Point Numbers
160
161    An unsigned 10-bit floating-point number has no sign bit, a 5-bit
162    exponent (E), and a 5-bit mantissa (M).  The value of an unsigned
163    10-bit floating-point number (represented as an 10-bit unsigned
164    integer N) is determined by the following:
165
166        0.0,                      if E == 0 and M == 0,
167        2^-14 * (M / 32),         if E == 0 and M != 0,
168        2^(E-15) * (1 + M/32),    if 0 < E < 31,
169        INF,                      if E == 31 and M == 0, or
170        NaN,                      if E == 31 and M != 0,
171
172    where
173
174        E = floor(N / 32), and
175        M = N mod 32.
176
177    When a floating-point value is converted to an unsigned 10-bit
178    floating-point representation, finite values are rounded to the closet
179    representable finite value.  While less accurate, implementations
180    are allowed to always round in the direction of zero.  This means
181    negative values are converted to zero.  Likewise, finite positive
182    values greater than 64512 (the maximum finite representable unsigned
183    10-bit floating-point value) are converted to 64512.  Additionally:
184    negative infinity is converted to zero; positive infinity is converted
185    to positive infinity; and both positive and negative NaN are converted
186    to positive NaN.
187
188    Any representable unsigned 10-bit floating-point value is legal
189    as input to a GL command that accepts 10-bit floating-point data.
190    The result of providing a value that is not a floating-point number
191    (such as infinity or NaN) to such a command is unspecified, but must
192    not lead to GL interruption or termination.  Providing a denormalized
193    number or negative zero to GL must yield predictable results.
194
195Additions to Chapter 3 of the 2.0 Specification (Rasterization)
196
197 -- Section 3.6.4, Rasterization of Pixel Rectangles
198
199    Add a new row to Table 3.5 (page 128):
200
201        type Parameter                    Corresponding  Special
202        Token Name                        GL Data Type   Interpretation
203        --------------------------------  -------------  --------------
204        UNSIGNED_INT_10F_11F_11F_REV_EXT   uint           yes
205
206    Add a new row to table 3.8: Packed pixel formats (page 132):
207
208        type Parameter                    GL Data  Number of   Matching
209        Token Name                        Type     Components  Pixel Formats
210        --------------------------------  -------  ----------  -------------
211        UNSIGNED_INT_10F_11F_11F_REV_EXT   uint     3           RGB
212
213    Add a new entry to table 3.11: UNSIGNED_INT formats (page 134):
214
215        UNSIGNED_INT_10F_11F_11F_REV_EXT:
216
217        31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
218        +----------------------------+--------------------------------+---------------------------------+
219        |           3rd              |             2nd                |             1st                 |
220        +----------------------------+--------------------------------+---------------------------------+
221
222    Add to the end of the 2nd paragraph starting "Pixels are draw using":
223
224    "If type is UNSIGNED_INT_10F_11F_11F_REV_EXT and format is not RGB
225    then the error INVALID_ENUM occurs."
226
227    Add UNSIGNED_INT_10F_11F_11F_REV_EXT to the list of packed formats
228    in the 10th paragraph after the "Packing" subsection (page 130).
229
230    Add before the 3rd paragraph (page 135, starting "Calling DrawPixels
231    with a type of BITMAP...") from the end of the "Packing" subsection:
232
233    "Calling DrawPixels with a type of UNSIGNED_INT_10F_11F_11F_REV_EXT
234    and format of RGB is a special case in which the data are a series
235    of GL uint values.  Each uint value specifies 3 packed components
236    as shown in table 3.11.  The 1st, 2nd, and 3rd components are
237    called f_red (11 bits), f_green (11 bits), and f_blue (10 bits)
238    respectively.
239
240    f_red and f_green are treated as unsigned 11-bit floating-point values
241    and converted to floating-point red and green components respectively
242    as described in section 2.1.A.  f_blue is treated as an unsigned
243    10-bit floating-point value and converted to a floating-point blue
244    component as described in section 2.1.B."
245
246 -- Section 3.8.1, Texture Image Specification:
247
248    "Alternatively if the internalformat is R11F_G11F_B10F_EXT, the red,
249    green, and blue bits are converted to unsigned 11-bit, unsigned
250    11-bit, and unsigned 10-bit floating-point values as described
251    in sections 2.1.A and 2.1.B.  These encoded values can be later
252    decoded back to floating-point values due to texture image sampling
253    or querying."
254
255    Add a new row to Table 3.16 (page 154).
256
257        Sized                  Base             R     G     B     A     L     I     D
258        Internal Format        Internal Format  bits  bits  bits  bits  bits  bits  bits
259        ---------------------  ---------------  ----  ----  ----  ----  ----  ----  ----
260        R11F_G11F_B10F_EXT     RGB              11    11    10
261
262Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations
263and the Frame Buffer)
264
265 -- Modify Chapter 4 Introduction, (page 198)
266
267    Modify first sentence of third paragraph (page 198):
268
269    "Color buffers consist of either signed or unsigned integer color
270    indices, R, G, B and optionally A signed or unsigned integer values,
271    or R, G, B, and optionally A signed or unsigned floating-point
272    values."
273
274 -- Section 4.3.2, Reading Pixels
275
276    Add a row to table 4.7 (page 224);
277
278                                                    Component
279    type Parameter                    GL Data Type  Conversion Formula
280    --------------------------------  ------------  ------------------
281    UNSIGNED_INT_10F_11F_11F_REV_EXT   uint          special
282
283    Replace second paragraph of "Final Conversion" (page 222) to read:
284
285    For an RGBA color, if <type> is not one of FLOAT,
286    UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT,
287    or if the CLAMP_READ_COLOR_ARB is TRUE, or CLAMP_READ_COLOR_ARB
288    is FIXED_ONLY_ARB and the selected color (or texture) buffer is
289    a fixed-point buffer, each component is first clamped to [0,1].
290    Then the appropriate conversion formula from table 4.7 is applied
291    the component."
292
293    Add a paragraph after the second paragraph of "Final Conversion"
294    (page 222):
295
296    "In the special case when calling ReadPixels with a type of
297    UNSIGNED_INT_10F_11F_11F_REV_EXT and format of RGB, the conversion
298    is done as follows:  The returned data are packed into a series of
299    GL uint values. The red, green, and blue components are converted
300    to unsigned 11-bit floating-point, unsigned 11-bit floating-point,
301    and unsigned 10-bit floating point as described in section
302    2.1.A and 2.1.B.  The resulting red 11 bits, green 11 bits, and blue
303    10 bits are then packed as the 1st, 2nd, and 3rd components of the
304    UNSIGNED_INT_10F_11F_11F_REV_EXT format as shown in table 3.11."
305
306Additions to Chapter 5 of the 2.0 Specification (Special Functions)
307
308    None
309
310Additions to Chapter 6 of the 2.0 Specification (State and State Requests)
311
312    None
313
314Additions to the OpenGL Shading Language specification
315
316    None
317
318Additions to Chapter 3 of the GLX 1.3 Specification (Functions and
319Errors)
320
321    Replace Section 3.3.3 (p.12) Paragraph 4 to:
322
323    The attribute GLX_RENDER_TYPE has as its value a mask indicating
324    what type of GLXContext a drawable created with the corresponding
325    GLXFBConfig can be bound to. The following bit settings are supported:
326    GLX_RGBA_BIT, GLX_RGBA_FLOAT_BIT, GLX_RGBA_UNSIGNED_FLOAT_BIT,
327    GLX_COLOR_INDEX_BIT.  If combinations of bits are set in the mask
328    then drawables created with the GLXFBConfig can be bound to those
329    corresponding types of rendering contexts.
330
331    Add to Section 3.3.3 (p.15) after first paragraph:
332
333    Note that unsigned floating point rendering is only supported
334    for GLXPbuffer drawables.  The GLX_DRAWABLE_TYPE attribute of
335    the GLXFBConfig must have the GLX_PBUFFER_BIT bit set and the
336    GLX_RENDER_TYPE attribute must have the GLX_RGBA_UNSIGNED_FLOAT_BIT
337    set.  Unsigned floating point rendering assumes the framebuffer
338    format has no sign bits so all component values are non-negative.
339    In contrast, conventional floating point rendering assumes signed
340    components.
341
342    Modify Section 3.3.7 (p.25 Rendering Contexts) remove period
343    at end of second paragraph and replace with:
344
345    ; if render_type is set to GLX_RGBA_UNSIGNED_FLOAT_TYPE then a
346    context that supports unsigned floating point RGBA rendering is
347    created.
348
349GLX Protocol
350
351    None.
352
353Additions to the WGL Specification
354
355    Modify the values accepted by WGL_PIXEL_TYPE_ARB to:
356
357        WGL_PIXEL_TYPE_ARB
358        The type of pixel data. This can be set to WGL_TYPE_RGBA_ARB,
359        WGL_TYPE_RGBA_FLOAT_ARB, WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT,
360        or WGL_TYPE_COLORINDEX_ARB.
361
362    Add this explanation of unsigned floating point rendering:
363
364    "Unsigned floating point rendering assumes the framebuffer format has
365    no sign bits so all component values are non-negative.  In contrast,
366    conventional floating point rendering assumes signed components."
367
368Dependencies on WGL_ARB_pbuffer
369
370    Ignore the "Additions to the WGL Specification" section if
371    WGL_ARB_pbuffer is not supported.
372
373Dependencies on WGL_ARB_pixel_format
374
375    The WGL_ARB_pixel_format extension must be used to determine a
376    pixel format with unsigned float components.
377
378Dependencies on ARB_color_buffer_float
379
380    If ARB_color_buffer_float is not supported, replace this amended
381    sentence from 4.3.2 above
382
383    For an RGBA color, if <type> is not one of FLOAT,
384    UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT,
385    or if the CLAMP_READ_COLOR_ARB is TRUE, or CLAMP_READ_COLOR_ARB
386    is FIXED_ONLY_ARB and the selected color (or texture) buffer is
387    a fixed-point buffer, each component is first clamped to [0,1]."
388
389    with
390
391    "For an RGBA color, if <type> is not one of FLOAT,
392    UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT
393    and the selected color buffer (or texture image for GetTexImage)
394    is a fixed-point buffer (or texture image for GetTexImage), each
395    component is first clamped to [0,1]."
396
397Dependencies on EXT_texture_shared_exponent
398
399    If EXT_texture_shared_exponent is not supported, delete the reference
400    to UNSIGNED_INT_5_9_9_9_REV_EXT in section 4.3.2.
401
402Dependencies on EXT_framebuffer_object
403
404    If EXT_framebuffer_object is not supported, then
405    RenderbufferStorageEXT is not supported and the R11F_G11F_B10F_EXT
406    internalformat is therefore not supported by RenderbufferStorageEXT.
407
408    If EXT_framebuffer_object is supported, glRenderbufferStorageEXT
409    accepts GL_RG11F_B10F_EXT for its internalformat parameter because
410    GL_RG11F_B10F_EXT has a base internal format of GL_RGB that is listed
411    as color-renderable by the EXT_framebuffer_object specification.
412
413Errors
414
415    Relaxation of INVALID_ENUM errors
416    ---------------------------------
417
418    TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D,
419    and RenderbufferStorageEXT accept the new R11F_G11F_B10F_EXT token
420    for internalformat.
421
422    DrawPixels, ReadPixels, TexImage1D, TexImage2D, GetTexImage,
423    TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D,
424    GetHistogram, GetMinmax, ConvolutionFilter1D, ConvolutionFilter2D,
425    ConvolutionFilter3D, GetConvolutionFilter, SeparableFilter2D,
426    GetSeparableFilter, ColorTable, ColorSubTable, and GetColorTable
427    accept the new UNSIGNED_INT_10F_11F_11F_REV_EXT token for type.
428
429    New errors
430    ----------
431
432    INVALID_OPERATION is generated by DrawPixels, ReadPixels, TexImage1D,
433    TexImage2D, GetTexImage, TexImage3D, TexSubImage1D, TexSubImage2D,
434    TexSubImage3D, GetHistogram, GetMinmax, ConvolutionFilter1D,
435    ConvolutionFilter2D, ConvolutionFilter3D, GetConvolutionFilter,
436    SeparableFilter2D, GetSeparableFilter, ColorTable, ColorSubTable,
437    and GetColorTable if <type> is UNSIGNED_INT_10F_11F_11F_REV_EXT and
438    <format> is not RGB.
439
440New State
441
442    In table 6.17, Textures (page 278), increment the 42 in "n x Z42*"
443    by 1 for the R11F_G11F_B10F_EXT format.
444
445    [NOTE: The OpenGL 2.0 specification actually should read "n x Z48*"
446    because of the 6 generic compressed internal formats in table 3.18.]
447
448    (modify table 6.33, p. 294)
449
450                                                      Initial
451    Get Value                    Type   Get Command   Value    Description         Sec.   Attribute
452    --------------------------   ----   -----------   -------  ------------------  ----   ----------
453    RGBA_SIGNED_COMPONENTS_EXT   4xB    GetIntegerv   -        True if respective  4      -
454                                                               R, G, B, and A
455                                                               components are
456                                                               signed
457
458New Implementation Dependent State
459
460    None
461
462Issues
463
464    1)  What should this extension be called?
465
466        RESOLVED: EXT_packed_float
467
468        This extension provides a new 3-component packed float format
469        for use as a texture internal format, pixel external format,
470        and framebuffer color format.
471
472        "packed" indicates the extension is packing components
473        at reduced precisions (similar to EXT_packed_pixels or
474        NV_packed_depth_stencil).
475
476        EXT_r11f_g11f_b10f_float was considered but there's no precedent
477        for extension names to be so explicit (or cryptic?) about format
478        specifics in the extension name.
479
480    2)  Should there be an rgb11f_b10f framebuffer format?
481
482        RESOLVED:  Yes.  Unsigned floating-point rendering formats for GLX
483        and WGL are provided.  The assumption is that this functionality
484        could be used to advertise a pixel format with 11 bits of unsigned
485        floating-point red, 11 bits of unsigned floating-point green,
486        and 10 bits of floating-point blue.
487
488        In theory, an implementation could advertise other component sizes
489        other than 11/11/10 for an unsigned floating-point framebuffer
490        format but that is not expected.
491
492    3)  Should there be GLX and WGL extension strings?
493
494        RESOLVED:  Yes, there are WGL and GLX tokens added to
495        support querying unsigned floating-point color buffer
496        formats named WGL_EXT_pixel_format_packed_float and
497        GLX_EXT_fbconfig_packed_float respectively.
498
499    4)  Should there be an unequal distribution of red, green, and blue
500        mantissa bits?
501
502        RESOLVED:  Yes.  A 6-bit mantissa for red and green is unbalanced
503        with the 5-bit mantissa for blue, but this allows all the bits of
504        a 32 bit word (6+6+5+3*5=32) to be used.  The blue component is
505        chosen to have fewer bits because 1) it is the third component,
506        and 2) there's a belief that the human eye is less sensitive
507        to blue variations..
508
509        Developers should be aware that subtle yellowing or bluing
510        of gray-scale values is possible because of the extra bit of
511        mantissa in the red and green components.
512
513    5)  Should there be an external format for r11f_g11f_b10f?
514
515        RESOLVED:  Yes.  This makes it fast to load GL_R11F_G11F_B10F_EXT
516        textures without any translation by the driver.
517
518    6)  What is the exponent bias?
519
520        RESOLVED:  15, just like 16-bit half-precision floating-point
521        values.
522
523    7)  Can s10e5 floating-point filtering be used to filter
524        r11f_g11f_b10f values?  If so, how?
525
526        RESOLVED:  Yes.  It is easy to promote r11f_g11f_b10f values to
527        s10e5 components.
528
529    8)  Should automatic mipmap generation be supported for r11f_g11f_b10f
530        textures?
531
532        RESOLVED:  Yes.
533
534    9)  Should non-texture and non-framebuffer commands for loading
535        pixel data accept the GL_UNSIGNED_INT_10F_11F_11F_REV_EXT type?
536
537        RESOLVED:  Yes.
538
539        Once the pixel path has to support the new type/format combination
540        of GL_UNSIGNED_INT_5_9_9_9_REV_EXT / GL_RGB for specifying and
541        querying texture images, it might as well be supported for all
542        commands that pack and unpack RGB pixel data.
543
544        The specification is written such that the glDrawPixels
545        type/format parameters are accepted by glReadPixels,
546        glTexGetImage, glTexImage2D, and other commands that are specified
547        in terms of glDrawPixels.
548
549    10) Should non-texture internal formats (such as for color tables,
550        convolution kernels, histogram bins, and min/max tables) accept
551        GL_R11F_G11F_B10F_EXT format?
552
553        RESOLVED:  No.
554
555        That's pointless.  No hardware is ever likely to support
556        GL_R11F_G11F_B10F_EXT internal formats for anything other than
557        textures and maybe color buffers in the future.  This format is
558        not interesting for color tables, convolution kernels, etc.
559
560    11) Should a format be supported with sign bits for each component?
561
562        RESOLVED:  No.  A sign bit for each of the three components would
563        steal too many bits from the mantissa.  This format is intended
564        for storing radiance and irradiance values that are physically
565        non-negative.
566
567    12) Should we support a non-REV version of the
568        GL_UNSIGNED_INT_10F_11F_11F_REV_EXT token?
569
570        RESOLVED:  No.  We don't want to promote different arrangements
571        of the bitfields for r11f_g11f_b10f values.
572
573    13) Can you use the GL_UNSIGNED_INT_10F_11F_11F_REV_EXT format with
574        just any format?
575
576        RESOLVED:  You can only use the
577        GL_UNSIGNED_INT_10F_11F_11F_REV_EXT format with GL_RGB.
578        Otherwise, the GL generates a GL_INVALID_OPERATION error.
579        Just as the GL_UNSIGNED_BYTE_3_3_2 format just works with GL_RGB
580        (or else the GL generates a GL_INVALID_OPERATION error), so
581        should GL_UNSIGNED_INT_10F_11F_11F_REV_EXT.
582
583    14) Should blending be supported for a packed float framebuffer
584        format?
585
586        RESOLVED:  Yes.  Blending is required for other floating-point
587        framebuffer formats introduced by ARB_color_buffer_float.
588        The equations for blending should be evaluated with signed
589        floating-point math but the result will have to be clamped to
590        non-negative values to be stored back into the packed float
591        format of the color buffer.
592
593    15) Should unsigned floating-point framebuffers be queried
594        differently from conventional (signed) floating-point
595        framebuffers?
596
597        RESOLVED:  Yes.  An existing application using
598        ARB_color_buffer_float can rightfully expect a floating-point
599        color buffer format to provide signed components.  The packed
600        float format does not provide a sign bit.  Simply treating packed
601        float color buffer formats as floating-point might break some
602        existing applications that depend on a float color buffer to be
603        signed.
604
605        For this reason, there are new WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT
606        (for WGL) and GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT (for GLX)
607        framebuffer format parameters.
608
609    16) What should glGet of GL_RGBA_FLOAT_MODE_ARB return for unsigned
610        float color buffer formats?
611
612        RESOLVED.  GL_RGBA_FLOAT_MODE_ARB should return true.  The packed
613        float components are unsigned but still floating-point.
614
615    17) Can you query with glGet to determine if the color buffer has
616        unsigned float components?
617
618        RESOLVED:  Yes.  Call glGetIntegerv
619        on GL_RGBA_SIGNED_COMPONENTS_EXT.  The value returned is
620        a 4-element array.  Element 0 corresponds to red, element 1
621        corresponds to green, element 2 corresponds to blue, and element
622        3 corresponds to alpha.  If a color component is signed, its
623        corresponding element is true (GL_TRUE).  This is the same way
624        the GL_COLOR_WRITEMASK bits are formatted.
625
626        For the packed float format, all the elements are zeroed since
627        the red, green, and blue components are unsigned and the alpha
628        component is non-existent.  All elements are also zeroed for
629        conventional fixed-point color buffer formats.  Elements are
630        set for signed floating-point formats such as those introduced
631        by ARB_color_buffer_float.  If a component (such as alpha) has
632        zero bits, the component should not be considered signed and so
633        the bit for the respective component should be zeroed.
634
635        This generality allows a future extension to specify float
636        color buffer formats that had a mixture of signed and unsigned
637        floating-point components.  However, this extension only provides
638        a packed float color format with all unsigned components.
639
640    18) How many bits of alpha should GL_ALPHA_BITS return for the packed
641        float color buffer format?
642
643        RESOLVED:  Zero.
644
645    19) Can you render to a packed float texture with the
646        EXT_framebuffer_object functionality?
647
648        RESOLVED:  Yes.
649
650        Potentially an implementation could return
651        GL_FRAMEBUFFER_UNSUPPORTED_EXT when glCheckFramebufferStatusEXT
652        for a framebuffer object including a packed float color buffer,
653        but implementations are likely to support (and strongly encouraged
654        to support) the packed float format for use with a framebuffer
655        object because the packed float format is expected to be a
656        memory-efficient floating-point color format well-suited for
657        rendering, particularly rendering involving high-dynamic range.
658
659    20) This extension is for a particular packed float format.  What if
660        new packed float formats come along?
661
662        RESOLVED:  A new extension could be introduced with a name like
663        EXT_packed_float2, but at this time, no other such extensions
664        are expected except for the EXT_texture_shared_exponent
665        extension.  It simply hard to justify packing three or more
666        components into a single 32-bit word in lots of different ways
667        since any approach is going to be a compromise of some sort.
668        For two-component or one-component floating-point formats, the
669        existing ARB_texture_float formats fit nicely into 16 or 32 bits
670        by simply using half precision floating-point.  If 64 bits are
671        allowed for a pixel, the GL_RGBA16F_ARB is a good choice.
672
673        The packed float format is similar to the format introduced by
674        the EXT_texture_shared_exponent extension, but that extension
675        is not a pure packed float format.  Unlike the packed float
676        format, the EXT_texture_shared_exponent format shares a single
677        exponent between the RGB components rather than providing
678        an independent exponent for each component.  Because the
679        EXT_texture_shared_exponent uses fewer bits to store exponent
680        values, more mantissa precision is provided.
681
682    21) Should this extension provide pbuffer support?
683
684        RESOLVED:  Yes.  Pbuffers are core GLX 1.3 functionality.
685        While using FBO is probably the preferred way to render to
686        r11f_g11f_b10f framebuffers but pbuffer support is natural
687        to provide.  WGL should have r11f_g11f_b10f pbuffer support too.
688
689    22) Must an implementation support NaN, Infinity, and/or denorms?
690
691        RESOLVED:  The preferred implementation is to support NaN,
692        Infinity, and denorms.  Implementations are allowed to flush
693        denorms to zero, and treat NaN and Infinity values as large
694        finite values.
695
696        This allowance flushes denorms to zero:
697
698            0.0,                      if E == 0 and M != 0
699
700        This allowance treats Infinity as a finite value:
701
702            2^16                      if E == 31 and M == 0
703
704        This allowance treats NaN encodings as finite values:
705
706            2^16 * (1 + M/64)         if E == 31 and M != 0
707
708        The expectation is that mainstream GPUs will support NaN,
709        Infinity, and denorms while low-end implementations such as for
710        OpenGL ES 2.0 will likely support denorms but neither NaN nor
711        Infinity.
712
713        There is not an indication of how these floating-point special
714        values are treated (though an application could test an
715        implementation if necessary).
716
717    23) Should this extension interoperate with framebuffer objects?
718
719        RESOLVED:  Definitely.  No particular specification language is
720        required.
721
722        In particular, glRenderbufferStorageEXT should accept
723        GL_R11F_G11F_B10F_EXT for its internalformat parameter (true
724        because this extension adds a new format to Table 3.16).
725
726    24) Are negative color components clamped to zero when written into
727        an unsigned floating-point color buffer?  If so, do we need to
728        say in the Blending or Dithering language that negative color
729        components are clamped to zero?
730
731        RESOLVED:  Yes, negative color components are clamped to zero when
732        written to an unsigned floating-point color buffer.  No specification
733        language is required for this behavior because the ARB_color_buffer_float
734        extension says
735
736        "In RGBA mode dithering selects, for each color component, either
737        the most positive representable color value (for that particular
738        color component) that is less than or equal to the incoming
739        color component value, c, or the most negative representable
740        color value that is greater than or equal to c.
741
742        If dithering is disabled, then each incoming color component
743        c is replaced with the most positive representable color value
744        (for that particular component) that is less than or equal to c,
745        or by the most negative representable value, if no representable
746        value is less than or equal to c;"
747
748        The most negative representable value for unsigned
749        floating-point values is zero.  So the existing language from
750        ARB_color_buffer_float already indicates that negative values
751        are clamped to zero for unsigned floating-point color buffers.
752        No additional specification language is required.
753
754    25) Prior texture internal formats have generic formats (example:
755        GL_RGB) and corresponding sized formats (GL_RGB8, GL_RGB10,
756        etc.).  Should we add a generic format corresponding to
757        GL_R11F_G11F_B10F_EXT?
758
759        RESOLVED:  No.  It's unlikely there will be any other unsigned
760        floating-point texture formats.
761
762Revision History
763
764    None
765