NV_packed_float
NV_packed_float_linear

GL_NV_packed_float
GL_NV_packed_float_linear

Mark J. Kilgard, NVIDIA
Mathias Heyer, NVIDIA
Koji Ashida, NVIDIA 
Greg Roth, NVIDIA

Mathias Heyer, NVIDIA (mheyer 'at' nvidia.com)

Complete

Last Modified: 2012/09/26
NVIDIA Revision: 3

OpenGL ES Extension #127

Written against the OpenGL ES 2.0.25 (Nov. 2010) Specification.

EXT_color_buffer_half_float affects the definition of this
specification.

OES_texture_half_float affects the defintion of this specification.

NV_framebuffer_multisample affects the defintion of this
specification.

NV_texture_array affects the defintion of this specification.

EXT_texture_storage affects the defintion of this specification.

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.

Accepted by the <internalformat> parameter of RenderbufferStorage
and RenderBufferStorageMultisampleNV, TexStorage2DEXT and
TexStorage3DEXT:

    R11F_G11F_B10F_NV                                   0x8C3A

Accepted by the <type> parameter of ReadPixels, TexImage2D, 
TexSubImage2D, TexImage3DNV, TexSubImage3DNV:

    UNSIGNED_INT_10F_11F_11F_REV_NV                     0x8C3B

Add two new sections after Section "Floating-Point Computation":

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

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

Add to Table 3.2, p. 62:

    type Parameter                   Corresponding  Special
    Token Name                       GL Data Type   Interpretation
    -------------------------------  -------------  --------------
    UNSIGNED_INT_10F_11F_11F_REV_NV  uint           Yes

Add to Table 3.4, p. 63:

    Format           Type                             Bytes per Pixel
    ---------        -------------------------------  ---------------
    RGB              UNSIGNED_INT_10F_11F_11F_REV_NV  4

    type Parameter                    GL Data  Number of   Matching  
    Token Name                        Type     Components  Pixel Formats
    -------------------------------   -------  ----------  --------------
    UNSIGNED_INT_10F_11F_11F_REV_NV   uint     3           RGB

    UNSIGNED_INT_10F_11F_11F_REV_NV:

     31 30 ... 23 22 21 20 ... 12 11 10  9 ...  1  0
    +---------------+---------------+---------------+
    |      3rd      |      2nd      |      1st      |
    +---------------+---------------+---------------+

Add the following to the end of Section 4.3, subsection
"Final Color Conversion"

    If an implementation allows calling ReadPixels with a <type> of 
    UNSIGNED_INT_10F_11F_11F_REV_NV 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_NV format as shown in Section 3.6.


Add to Table 4.4, p. 106:

    type Parameter                                  Component
    Token Name                       GL Data Type   Conversion Formula
    --------------                   -------------  ------------------
    UNSIGNED_INT_10F_11F_11F_REV_NV  uint           c = f

(modify "Final Conversion", p. 106):
    If type is not FLOAT, HALF_FLOAT_OES or UNSIGNED_INT_10F_11F_11F_REV_NV,
    each component is first clamped to [0,1]. Then the appropriate conversion...

Add to Table 4.5, p. 117:

    Sized              Renderable        R     G     B     A     D     S
    Internal Format    Type              bits  bits  bits  bits  bits  bits
    ---------------    ----------------  ----  ----  ----  ----  ----  ----
    R11F_G11F_B10F_NV  color-renderable  f11   f11   f10

Relaxation of INVALID_ENUM errors
---------------------------------

RenderbufferStorage and RenderBufferStorageMultisampleNV accept
the new R11F_G11F_B10F_EXT token for <internalformat>.

ReadPixels, TexImage2D, TexSubImage2D, TexImage3DNV and
TexSubImage3DNV accept the new UNSIGNED_INT_10F_11F_11F_REV_EXT
token for <type>.


New errors
----------

INVALID_OPERATION is generated by ReadPixels, TexImage2D,
TexSubImage2D, TexImage3DNV and TexSubImage3DNV if <type> is
UNSIGNED_INT_10F_11F_11F_REV_EXT and <format> is not RGB.

If OES_texture_half_float is not supported, modify fifth paragraph
of 3.7.1 Texture Image Specification, p. 67:

"The selected groups are processed as described in section 3.6.2, stopping
after final expansion to RGBA. If the internal format of the texture is
fixed-point, components are clamped to [0,1]. Otherwise, values are not
modified."

Modify first sentence of "Unpacking", p. 62:

"Data are taken from client memory as a sequence of one of the GL data
types listed in Table 3.2. These elements are..."

Additionally, ignore all references to RGBA16F_EXT, RGB16F_EXT,
RG16F_EXT, R16F_EXT, HALF_FLOAT_OES and half.

If EXT_color_buffer_half_float is not supported, do not consider
R11F_G11F_B10F_NV color-renderable. Remove all changes and additions
to Chapter 4 of the OpenGL ES 2.0 Specification. 

If NV_packed_float_linear is not supported, using LINEAR
magnification filter and LINEAR, NEAREST_MIPMAP_LINEAR,
LINEAR_MIPMAP_NEAREST and LINEAR_MIPMAP_NEAREST minification
filters will cause packed float textures to be considered
incomplete.

If NV_framebuffer_multisample is missing, remove all refernences to
RenderBufferStorageMultisampleNV.

If NV_texture_array is not supported, remove all references to
TexImage3DNV and TexSubImage3DNV.

If EXT_texture_storage is not supported, remove all references to
TexStorage2DEXT and TexStorage3DEXT.

1) Are the new formats allowed in window surface and pbuffer managed
  by EGL?

  No.  Let's focus on framebuffer objects.

  See EXT_packed_float for other relevant issues.