xref: /third_party/openGLES/extensions/EXT/EXT_packed_float.txt (revision 5bd8dead)

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 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