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 parameter of TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and RenderbufferStorageEXT: R11F_G11F_B10F_EXT 0x8C3A Accepted by the 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 parameters of GetIntegerv, GetFloatv, and GetDoublev: RGBA_SIGNED_COMPONENTS_EXT 0x8C3C Accepted as a value in the and parameter arrays of wglChoosePixelFormatARB, and returned in the parameter array of wglGetPixelFormatAttribivARB, and the parameter array of wglGetPixelFormatAttribfvARB: WGL_TYPE_RGBA_UNSIGNED_FLOAT_EXT 0x20A8 Accepted as values of the arguments in the glXCreateNewContext and glXCreateContext functions GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT 0x20B1 Returned by glXGetFBConfigAttrib (when is set to GLX_RENDER_TYPE) and accepted by the 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 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 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 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 is UNSIGNED_INT_10F_11F_11F_REV_EXT and 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 a GL_INVALID_OPERATION error. Just as the GL_UNSIGNED_BYTE_3_3_2 format just works with GL_RGB (or else the GL generates a 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