Name
EXT_packed_float
Name Strings
GL_EXT_packed_float
WGL_EXT_pixel_format_packed_float
GLX_EXT_fbconfig_packed_float
Contact
Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
Status
Preliminary
Version
Date: February 15, 2006
Revision: 0.3
Number
328
Dependencies
OpenGL 1.1 required
ARB_color_buffer_float affects this extension.
EXT_texture_shared_exponent trivially affects this extension.
EXT_framebuffer_object affects this extension.
WGL_ARB_pixel_format is required for use with WGL.
WGL_ARB_pbuffer affects WGL pbuffer support for this extension.
GLX 1.3 is required for use with GLX.
This extension is written against the OpenGL 2.0 (September 7,
2004) specification.
Overview
This extension adds a new 3-component floating-point texture format
that fits within a single 32-bit word. This format stores 5 bits
of biased exponent per component in the same manner as 16-bit
floating-point formats, but rather than 10 mantissa bits, the red,
green, and blue components have 6, 6, and 5 bits respectively.
Each mantissa is assumed to have an implied leading one except in the
denorm exponent case. There is no sign bit so only non-negative
values can be represented. Positive infinity, positive denorms,
and positive NaN values are representable. The value of the fourth
component returned by a texture fetch is always 1.0.
This extension also provides support for rendering into an unsigned
floating-point rendering format with the assumption that the texture
format described above could also be advertised as an unsigned
floating-point format for rendering.
The extension also provides a pixel external format for specifying
packed float values directly.
New Procedures and Functions
None
New Tokens
Accepted by the <internalformat> parameter of TexImage1D,
TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and
RenderbufferStorageEXT:
R11F_G11F_B10F_EXT 0x8C3A
Accepted by the <type> parameter of DrawPixels, ReadPixels,
TexImage1D, TexImage2D, GetTexImage, TexImage3D, TexSubImage1D,
TexSubImage2D, TexSubImage3D, GetHistogram, GetMinmax,
ConvolutionFilter1D, ConvolutionFilter2D, ConvolutionFilter3D,
GetConvolutionFilter, SeparableFilter2D, GetSeparableFilter,
ColorTable, ColorSubTable, and GetColorTable:
UNSIGNED_INT_10F_11F_11F_REV_EXT 0x8C3B
Accepted by the <pname> parameters of GetIntegerv, GetFloatv, and
GetDoublev:
RGBA_SIGNED_COMPONENTS_EXT 0x8C3C
Accepted as a value in the <piAttribIList> and <pfAttribFList>
parameter arrays of wglChoosePixelFormatARB, and returned in the
<piValues> parameter array of wglGetPixelFormatAttribivARB, and the
<pfValues> parameter array of wglGetPixelFormatAttribfvARB:
WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT 0x20A8
Accepted as values of the <render_type> arguments in the
glXCreateNewContext and glXCreateContext functions
GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT 0x20B1
Returned by glXGetFBConfigAttrib (when <attribute> is set to
GLX_RENDER_TYPE) and accepted by the <attrib_list> parameter of
glXChooseFBConfig (following the GLX_RENDER_TYPE token):
GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT 0x00000008
Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation)
-- Add two new sections after Section 2.1.2, (page 6):
2.1.A Unsigned 11-Bit Floating-Point Numbers
An unsigned 11-bit floating-point number has no sign bit, a 5-bit
exponent (E), and a 6-bit mantissa (M). The value of an unsigned
11-bit floating-point number (represented as an 11-bit unsigned
integer N) is determined by the following:
0.0, if E == 0 and M == 0,
2^-14 * (M / 64), if E == 0 and M != 0,
2^(E-15) * (1 + M/64), if 0 < E < 31,
INF, if E == 31 and M == 0, or
NaN, if E == 31 and M != 0,
where
E = floor(N / 64), and
M = N mod 64.
Implementations are also allowed to use any of the following
alternative encodings:
0.0, if E == 0 and M != 0
2^(E-15) * (1 + M/64) if E == 31 and M == 0
2^(E-15) * (1 + M/64) if E == 31 and M != 0
When a floating-point value is converted to an unsigned 11-bit
floating-point representation, finite values are rounded to the closet
representable finite value. While less accurate, implementations
are allowed to always round in the direction of zero. This means
negative values are converted to zero. Likewise, finite positive
values greater than 65024 (the maximum finite representable unsigned
11-bit floating-point value) are converted to 65024. Additionally:
negative infinity is converted to zero; positive infinity is converted
to positive infinity; and both positive and negative NaN are converted
to positive NaN.
Any representable unsigned 11-bit floating-point value is legal
as input to a GL command that accepts 11-bit floating-point data.
The result of providing a value that is not a floating-point number
(such as infinity or NaN) to such a command is unspecified, but must
not lead to GL interruption or termination. Providing a denormalized
number or negative zero to GL must yield predictable results.
2.1.B Unsigned 10-Bit Floating-Point Numbers
An unsigned 10-bit floating-point number has no sign bit, a 5-bit
exponent (E), and a 5-bit mantissa (M). The value of an unsigned
10-bit floating-point number (represented as an 10-bit unsigned
integer N) is determined by the following:
0.0, if E == 0 and M == 0,
2^-14 * (M / 32), if E == 0 and M != 0,
2^(E-15) * (1 + M/32), if 0 < E < 31,
INF, if E == 31 and M == 0, or
NaN, if E == 31 and M != 0,
where
E = floor(N / 32), and
M = N mod 32.
When a floating-point value is converted to an unsigned 10-bit
floating-point representation, finite values are rounded to the closet
representable finite value. While less accurate, implementations
are allowed to always round in the direction of zero. This means
negative values are converted to zero. Likewise, finite positive
values greater than 64512 (the maximum finite representable unsigned
10-bit floating-point value) are converted to 64512. Additionally:
negative infinity is converted to zero; positive infinity is converted
to positive infinity; and both positive and negative NaN are converted
to positive NaN.
Any representable unsigned 10-bit floating-point value is legal
as input to a GL command that accepts 10-bit floating-point data.
The result of providing a value that is not a floating-point number
(such as infinity or NaN) to such a command is unspecified, but must
not lead to GL interruption or termination. Providing a denormalized
number or negative zero to GL must yield predictable results.
Additions to Chapter 3 of the 2.0 Specification (Rasterization)
-- Section 3.6.4, Rasterization of Pixel Rectangles
Add a new row to Table 3.5 (page 128):
type Parameter Corresponding Special
Token Name GL Data Type Interpretation
-------------------------------- ------------- --------------
UNSIGNED_INT_10F_11F_11F_REV_EXT uint yes
Add a new row to table 3.8: Packed pixel formats (page 132):
type Parameter GL Data Number of Matching
Token Name Type Components Pixel Formats
-------------------------------- ------- ---------- -------------
UNSIGNED_INT_10F_11F_11F_REV_EXT uint 3 RGB
Add a new entry to table 3.11: UNSIGNED_INT formats (page 134):
UNSIGNED_INT_10F_11F_11F_REV_EXT:
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
+----------------------------+--------------------------------+---------------------------------+
| 3rd | 2nd | 1st |
+----------------------------+--------------------------------+---------------------------------+
Add to the end of the 2nd paragraph starting "Pixels are draw using":
"If type is UNSIGNED_INT_10F_11F_11F_REV_EXT and format is not RGB
then the error INVALID_ENUM occurs."
Add UNSIGNED_INT_10F_11F_11F_REV_EXT to the list of packed formats
in the 10th paragraph after the "Packing" subsection (page 130).
Add before the 3rd paragraph (page 135, starting "Calling DrawPixels
with a type of BITMAP...") from the end of the "Packing" subsection:
"Calling DrawPixels with a type of UNSIGNED_INT_10F_11F_11F_REV_EXT
and format of RGB is a special case in which the data are a series
of GL uint values. Each uint value specifies 3 packed components
as shown in table 3.11. The 1st, 2nd, and 3rd components are
called f_red (11 bits), f_green (11 bits), and f_blue (10 bits)
respectively.
f_red and f_green are treated as unsigned 11-bit floating-point values
and converted to floating-point red and green components respectively
as described in section 2.1.A. f_blue is treated as an unsigned
10-bit floating-point value and converted to a floating-point blue
component as described in section 2.1.B."
-- Section 3.8.1, Texture Image Specification:
"Alternatively if the internalformat is R11F_G11F_B10F_EXT, the red,
green, and blue bits are converted to unsigned 11-bit, unsigned
11-bit, and unsigned 10-bit floating-point values as described
in sections 2.1.A and 2.1.B. These encoded values can be later
decoded back to floating-point values due to texture image sampling
or querying."
Add a new row to Table 3.16 (page 154).
Sized Base R G B A L I D
Internal Format Internal Format bits bits bits bits bits bits bits
--------------------- --------------- ---- ---- ---- ---- ---- ---- ----
R11F_G11F_B10F_EXT RGB 11 11 10
Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations
and the Frame Buffer)
-- Modify Chapter 4 Introduction, (page 198)
Modify first sentence of third paragraph (page 198):
"Color buffers consist of either signed or unsigned integer color
indices, R, G, B and optionally A signed or unsigned integer values,
or R, G, B, and optionally A signed or unsigned floating-point
values."
-- Section 4.3.2, Reading Pixels
Add a row to table 4.7 (page 224);
Component
type Parameter GL Data Type Conversion Formula
-------------------------------- ------------ ------------------
UNSIGNED_INT_10F_11F_11F_REV_EXT uint special
Replace second paragraph of "Final Conversion" (page 222) to read:
For an RGBA color, if <type> is not one of FLOAT,
UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT,
or if the CLAMP_READ_COLOR_ARB is TRUE, or CLAMP_READ_COLOR_ARB
is FIXED_ONLY_ARB and the selected color (or texture) buffer is
a fixed-point buffer, each component is first clamped to [0,1].
Then the appropriate conversion formula from table 4.7 is applied
the component."
Add a paragraph after the second paragraph of "Final Conversion"
(page 222):
"In the special case when calling ReadPixels with a type of
UNSIGNED_INT_10F_11F_11F_REV_EXT and format of RGB, the conversion
is done as follows: The returned data are packed into a series of
GL uint values. The red, green, and blue components are converted
to unsigned 11-bit floating-point, unsigned 11-bit floating-point,
and unsigned 10-bit floating point as described in section
2.1.A and 2.1.B. The resulting red 11 bits, green 11 bits, and blue
10 bits are then packed as the 1st, 2nd, and 3rd components of the
UNSIGNED_INT_10F_11F_11F_REV_EXT format as shown in table 3.11."
Additions to Chapter 5 of the 2.0 Specification (Special Functions)
None
Additions to Chapter 6 of the 2.0 Specification (State and State Requests)
None
Additions to the OpenGL Shading Language specification
None
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and
Errors)
Replace Section 3.3.3 (p.12) Paragraph 4 to:
The attribute GLX_RENDER_TYPE has as its value a mask indicating
what type of GLXContext a drawable created with the corresponding
GLXFBConfig can be bound to. The following bit settings are supported:
GLX_RGBA_BIT, GLX_RGBA_FLOAT_BIT, GLX_RGBA_UNSIGNED_FLOAT_BIT,
GLX_COLOR_INDEX_BIT. If combinations of bits are set in the mask
then drawables created with the GLXFBConfig can be bound to those
corresponding types of rendering contexts.
Add to Section 3.3.3 (p.15) after first paragraph:
Note that unsigned floating point rendering is only supported
for GLXPbuffer drawables. The GLX_DRAWABLE_TYPE attribute of
the GLXFBConfig must have the GLX_PBUFFER_BIT bit set and the
GLX_RENDER_TYPE attribute must have the GLX_RGBA_UNSIGNED_FLOAT_BIT
set. Unsigned floating point rendering assumes the framebuffer
format has no sign bits so all component values are non-negative.
In contrast, conventional floating point rendering assumes signed
components.
Modify Section 3.3.7 (p.25 Rendering Contexts) remove period
at end of second paragraph and replace with:
; if render_type is set to GLX_RGBA_UNSIGNED_FLOAT_TYPE then a
context that supports unsigned floating point RGBA rendering is
created.
GLX Protocol
None.
Additions to the WGL Specification
Modify the values accepted by WGL_PIXEL_TYPE_ARB to:
WGL_PIXEL_TYPE_ARB
The type of pixel data. This can be set to WGL_TYPE_RGBA_ARB,
WGL_TYPE_RGBA_FLOAT_ARB, WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT,
or WGL_TYPE_COLORINDEX_ARB.
Add this explanation of unsigned floating point rendering:
"Unsigned floating point rendering assumes the framebuffer format has
no sign bits so all component values are non-negative. In contrast,
conventional floating point rendering assumes signed components."
Dependencies on WGL_ARB_pbuffer
Ignore the "Additions to the WGL Specification" section if
WGL_ARB_pbuffer is not supported.
Dependencies on WGL_ARB_pixel_format
The WGL_ARB_pixel_format extension must be used to determine a
pixel format with unsigned float components.
Dependencies on ARB_color_buffer_float
If ARB_color_buffer_float is not supported, replace this amended
sentence from 4.3.2 above
For an RGBA color, if <type> is not one of FLOAT,
UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT,
or if the CLAMP_READ_COLOR_ARB is TRUE, or CLAMP_READ_COLOR_ARB
is FIXED_ONLY_ARB and the selected color (or texture) buffer is
a fixed-point buffer, each component is first clamped to [0,1]."
with
"For an RGBA color, if <type> is not one of FLOAT,
UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT
and the selected color buffer (or texture image for GetTexImage)
is a fixed-point buffer (or texture image for GetTexImage), each
component is first clamped to [0,1]."
Dependencies on EXT_texture_shared_exponent
If EXT_texture_shared_exponent is not supported, delete the reference
to UNSIGNED_INT_5_9_9_9_REV_EXT in section 4.3.2.
Dependencies on EXT_framebuffer_object
If EXT_framebuffer_object is not supported, then
RenderbufferStorageEXT is not supported and the R11F_G11F_B10F_EXT
internalformat is therefore not supported by RenderbufferStorageEXT.
If EXT_framebuffer_object is supported, glRenderbufferStorageEXT
accepts GL_RG11F_B10F_EXT for its internalformat parameter because
GL_RG11F_B10F_EXT has a base internal format of GL_RGB that is listed
as color-renderable by the EXT_framebuffer_object specification.
Errors
Relaxation of INVALID_ENUM errors
---------------------------------
TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D,
and RenderbufferStorageEXT accept the new R11F_G11F_B10F_EXT token
for internalformat.
DrawPixels, ReadPixels, TexImage1D, TexImage2D, GetTexImage,
TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D,
GetHistogram, GetMinmax, ConvolutionFilter1D, ConvolutionFilter2D,
ConvolutionFilter3D, GetConvolutionFilter, SeparableFilter2D,
GetSeparableFilter, ColorTable, ColorSubTable, and GetColorTable
accept the new UNSIGNED_INT_10F_11F_11F_REV_EXT token for type.
New errors
----------
INVALID_OPERATION is generated by DrawPixels, ReadPixels, TexImage1D,
TexImage2D, GetTexImage, TexImage3D, TexSubImage1D, TexSubImage2D,
TexSubImage3D, GetHistogram, GetMinmax, ConvolutionFilter1D,
ConvolutionFilter2D, ConvolutionFilter3D, GetConvolutionFilter,
SeparableFilter2D, GetSeparableFilter, ColorTable, ColorSubTable,
and GetColorTable if <type> is UNSIGNED_INT_10F_11F_11F_REV_EXT and
<format> is not RGB.
New State
In table 6.17, Textures (page 278), increment the 42 in "n x Z42*"
by 1 for the R11F_G11F_B10F_EXT format.
[NOTE: The OpenGL 2.0 specification actually should read "n x Z48*"
because of the 6 generic compressed internal formats in table 3.18.]
(modify table 6.33, p. 294)
Initial
Get Value Type Get Command Value Description Sec. Attribute
-------------------------- ---- ----------- ------- ------------------ ---- ----------
RGBA_SIGNED_COMPONENTS_EXT 4xB GetIntegerv - True if respective 4 -
R, G, B, and A
components are
signed
New Implementation Dependent State
None
Issues
1) What should this extension be called?
RESOLVED: EXT_packed_float
This extension provides a new 3-component packed float format
for use as a texture internal format, pixel external format,
and framebuffer color format.
"packed" indicates the extension is packing components
at reduced precisions (similar to EXT_packed_pixels or
NV_packed_depth_stencil).
EXT_r11f_g11f_b10f_float was considered but there's no precedent
for extension names to be so explicit (or cryptic?) about format
specifics in the extension name.
2) Should there be an rgb11f_b10f framebuffer format?
RESOLVED: Yes. Unsigned floating-point rendering formats for GLX
and WGL are provided. The assumption is that this functionality
could be used to advertise a pixel format with 11 bits of unsigned
floating-point red, 11 bits of unsigned floating-point green,
and 10 bits of floating-point blue.
In theory, an implementation could advertise other component sizes
other than 11/11/10 for an unsigned floating-point framebuffer
format but that is not expected.
3) Should there be GLX and WGL extension strings?
RESOLVED: Yes, there are WGL and GLX tokens added to
support querying unsigned floating-point color buffer
formats named WGL_EXT_pixel_format_packed_float and
GLX_EXT_fbconfig_packed_float respectively.
4) Should there be an unequal distribution of red, green, and blue
mantissa bits?
RESOLVED: Yes. A 6-bit mantissa for red and green is unbalanced
with the 5-bit mantissa for blue, but this allows all the bits of
a 32 bit word (6+6+5+3*5=32) to be used. The blue component is
chosen to have fewer bits because 1) it is the third component,
and 2) there's a belief that the human eye is less sensitive
to blue variations..
Developers should be aware that subtle yellowing or bluing
of gray-scale values is possible because of the extra bit of
mantissa in the red and green components.
5) Should there be an external format for r11f_g11f_b10f?
RESOLVED: Yes. This makes it fast to load GL_R11F_G11F_B10F_EXT
textures without any translation by the driver.
6) What is the exponent bias?
RESOLVED: 15, just like 16-bit half-precision floating-point
values.
7) Can s10e5 floating-point filtering be used to filter
r11f_g11f_b10f values? If so, how?
RESOLVED: Yes. It is easy to promote r11f_g11f_b10f values to
s10e5 components.
8) Should automatic mipmap generation be supported for r11f_g11f_b10f
textures?
RESOLVED: Yes.
9) Should non-texture and non-framebuffer commands for loading
pixel data accept the GL_UNSIGNED_INT_10F_11F_11F_REV_EXT type?
RESOLVED: Yes.
Once the pixel path has to support the new type/format combination
of GL_UNSIGNED_INT_5_9_9_9_REV_EXT / GL_RGB for specifying and
querying texture images, it might as well be supported for all
commands that pack and unpack RGB pixel data.
The specification is written such that the glDrawPixels
type/format parameters are accepted by glReadPixels,
glTexGetImage, glTexImage2D, and other commands that are specified
in terms of glDrawPixels.
10) Should non-texture internal formats (such as for color tables,
convolution kernels, histogram bins, and min/max tables) accept
GL_R11F_G11F_B10F_EXT format?
RESOLVED: No.
That's pointless. No hardware is ever likely to support
GL_R11F_G11F_B10F_EXT internal formats for anything other than
textures and maybe color buffers in the future. This format is
not interesting for color tables, convolution kernels, etc.
11) Should a format be supported with sign bits for each component?
RESOLVED: No. A sign bit for each of the three components would
steal too many bits from the mantissa. This format is intended
for storing radiance and irradiance values that are physically
non-negative.
12) Should we support a non-REV version of the
GL_UNSIGNED_INT_10F_11F_11F_REV_EXT token?
RESOLVED: No. We don't want to promote different arrangements
of the bitfields for r11f_g11f_b10f values.
13) Can you use the GL_UNSIGNED_INT_10F_11F_11F_REV_EXT format with
just any format?
RESOLVED: You can only use the
GL_UNSIGNED_INT_10F_11F_11F_REV_EXT format with GL_RGB.
Otherwise, the GL generates an GL_INVALID_OPERATION error.
Just as the GL_UNSIGNED_BYTE_3_3_2 format just works with GL_RGB
(or else the GL generates an GL_INVALID_OPERATION error), so
should GL_UNSIGNED_INT_10F_11F_11F_REV_EXT.
14) Should blending be supported for a packed float framebuffer
format?
RESOLVED: Yes. Blending is required for other floating-point
framebuffer formats introduced by ARB_color_buffer_float.
The equations for blending should be evaluated with signed
floating-point math but the result will have to be clamped to
non-negative values to be stored back into the packed float
format of the color buffer.
15) Should unsigned floating-point framebuffers be queried
differently from conventional (signed) floating-point
framebuffers?
RESOLVED: Yes. An existing application using
ARB_color_buffer_float can rightfully expect a floating-point
color buffer format to provide signed components. The packed
float format does not provide a sign bit. Simply treating packed
float color buffer formats as floating-point might break some
existing applications that depend on a float color buffer to be
signed.
For this reason, there are new WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT
(for WGL) and GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT (for GLX)
framebuffer format parameters.
16) What should glGet of GL_RGBA_FLOAT_MODE_ARB return for unsigned
float color buffer formats?
RESOLVED. GL_RGBA_FLOAT_MODE_ARB should return true. The packed
float components are unsigned but still floating-point.
17) Can you query with glGet to determine if the color buffer has
unsigned float components?
RESOLVED: Yes. Call glGetIntegerv
on GL_RGBA_SIGNED_COMPONENTS_EXT. The value returned is
a 4-element array. Element 0 corresponds to red, element 1
corresponds to green, element 2 corresponds to blue, and element
3 corresponds to alpha. If a color component is signed, its
corresponding element is true (GL_TRUE). This is the same way
the GL_COLOR_WRITEMASK bits are formatted.
For the packed float format, all the elements are zeroed since
the red, green, and blue components are unsigned and the alpha
component is non-existent. All elements are also zeroed for
conventional fixed-point color buffer formats. Elements are
set for signed floating-point formats such as those introduced
by ARB_color_buffer_float. If a component (such as alpha) has
zero bits, the component should not be considered signed and so
the bit for the respective component should be zeroed.
This generality allows a future extension to specify float
color buffer formats that had a mixture of signed and unsigned
floating-point components. However, this extension only provides
a packed float color format with all unsigned components.
18) How many bits of alpha should GL_ALPHA_BITS return for the packed
float color buffer format?
RESOLVED: Zero.
19) Can you render to a packed float texture with the
EXT_framebuffer_object functionality?
RESOLVED: Yes.
Potentially an implementation could return
GL_FRAMEBUFFER_UNSUPPORTED_EXT when glCheckFramebufferStatusEXT
for a framebuffer object including a packed float color buffer,
but implementations are likely to support (and strongly encouraged
to support) the packed float format for use with a framebuffer
object because the packed float format is expected to be a
memory-efficient floating-point color format well-suited for
rendering, particularly rendering involving high-dynamic range.
20) This extension is for a particular packed float format. What if
new packed float formats come along?
RESOLVED: A new extension could be introduced with a name like
EXT_packed_float2, but at this time, no other such extensions
are expected except for the EXT_texture_shared_exponent
extension. It simply hard to justify packing three or more
components into a single 32-bit word in lots of different ways
since any approach is going to be a compromise of some sort.
For two-component or one-component floating-point formats, the
existing ARB_texture_float formats fit nicely into 16 or 32 bits
by simply using half precision floating-point. If 64 bits are
allowed for a pixel, the GL_RGBA16F_ARB is a good choice.
The packed float format is similar to the format introduced by
the EXT_texture_shared_exponent extension, but that extension
is not a pure packed float format. Unlike the packed float
format, the EXT_texture_shared_exponent format shares a single
exponent between the RGB components rather than providing
an independent exponent for each component. Because the
EXT_texture_shared_exponent uses fewer bits to store exponent
values, more mantissa precision is provided.
21) Should this extension provide pbuffer support?
RESOLVED: Yes. Pbuffers are core GLX 1.3 functionality.
While using FBO is probably the preferred way to render to
r11f_g11f_b10f framebuffers but pbuffer support is natural
to provide. WGL should have r11f_g11f_b10f pbuffer support too.
22) Must an implementation support NaN, Infinity, and/or denorms?
RESOLVED: The preferred implementation is to support NaN,
Infinity, and denorms. Implementations are allowed to flush
denorms to zero, and treat NaN and Infinity values as large
finite values.
This allowance flushes denorms to zero:
0.0, if E == 0 and M != 0
This allowance treats Infinity as a finite value:
2^16 if E == 31 and M == 0
This allowance treats NaN encodings as finite values:
2^16 * (1 + M/64) if E == 31 and M != 0
The expectation is that mainstream GPUs will support NaN,
Infinity, and denorms while low-end implementations such as for
OpenGL ES 2.0 will likely support denorms but neither NaN nor
Infinity.
There is not an indication of how these floating-point special
values are treated (though an application could test an
implementation if necessary).
23) Should this extension interoperate with framebuffer objects?
RESOLVED: Definitely. No particular specification language is
required.
In particular, glRenderbufferStorageEXT should accept
GL_R11F_G11F_B10F_EXT for its internalformat parameter (true
because this extension adds a new format to Table 3.16).
24) Are negative color components clamped to zero when written into
an unsigned floating-point color buffer? If so, do we need to
say in the Blending or Dithering language that negative color
components are clamped to zero?
RESOLVED: Yes, negative color components are clamped to zero when
written to an unsigned floating-point color buffer. No specification
language is required for this behavior because the ARB_color_buffer_float
extension says
"In RGBA mode dithering selects, for each color component, either
the most positive representable color value (for that particular
color component) that is less than or equal to the incoming
color component value, c, or the most negative representable
color value that is greater than or equal to c.
If dithering is disabled, then each incoming color component
c is replaced with the most positive representable color value
(for that particular component) that is less than or equal to c,
or by the most negative representable value, if no representable
value is less than or equal to c;"
The most negative representable value for unsigned
floating-point values is zero. So the existing language from
ARB_color_buffer_float already indicates that negative values
are clamped to zero for unsigned floating-point color buffers.
No additional specification language is required.
25) Prior texture internal formats have generic formats (example:
GL_RGB) and corresponding sized formats (GL_RGB8, GL_RGB10,
etc.). Should we add a generic format corresponding to
GL_R11F_G11F_B10F_EXT?
RESOLVED: No. It's unlikely there will be any other unsigned
floating-point texture formats.
Revision History
None
