Back to the OpenGL extension cross reference
WGL_NV_float_buffer
NV_float_buffer
Name Strings
GL_NV_float_buffer
WGL_NV_float_buffer
Contact
Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
Notice
Copyright NVIDIA Corporation, 2001-2003.
IP Status
NVIDIA Proprietary.
Status
Implemented in CineFX (NV30) Emulation driver, August 2002.
Shipping in Release 40 NVIDIA driver for CineFX hardware, January 2003.
Version
Last Modified: $Date: 2003/06/16 $
NVIDIA Revision: Revision: #16
Number
281
Dependencies
Written based on the wording of the OpenGL 1.3 specification and the
WGL_ARB_pixel_format extension specification.
The following extensions are required:
* NV_fragment_program
* NV_texture_rectangle
* WGL_ARB_pixel_format
* WGL_ARB_render_texture
* WGL_NV_render_texture_rectangle
EXT_paletted_texture trivially affects the definition of this extension.
SGIX_depth_texture trivially affects the definition of this extension.
NV_texture_shader trivially affects the definition of this extension.
NV_half_float trivially affects the definition of this extension.
Overview
This extension builds upon NV_fragment_program to provide a framebuffer
and texture format that allows fragment programs to read and write
unconstrained floating point data.
In unextended OpenGL, most computations dealing with color or depth
buffers are typically constrained to operate on values in the range [0,1].
Computational results are also typically clamped to the range [0,1].
Color, texture, and depth buffers themselves also hold values mapped to
the range [0,1].
The NV_fragment_program extension provides a general computational model
that supports floating-point numbers constrained only by the precision of
the underlying data types. The quantites computed by fragment programs do
not necessarily correspond in number or in range to conventional
attributes such as RGBA colors or depth values. Because of the range and
precision constraints imposed by conventional fixed-point color buffers,
it may be difficult (if not impossible) to use them to implement certain
multi-pass algorithms.
To enhance the extended range and precision available through fragment
programs, this extension provides floating-point RGBA color buffers that
can be used instead of conventional fixed-point RGBA color buffers. A
floating-point RGBA color buffer consists of one to four floating-point
components stored in the 16- or 32-bit floating-point formats (fp16 or
fp32) defined in the NV_half_float and NV_fragment_program extensions.
When a floating-point color buffer is used, the results of fragment
programs, as written to the "x", "y", "z", and "w" components of the
o[COLR] or o[COLH] output registers, are written directly to the color
buffer without any clamping or modification. Certain per-fragment
operations are bypassed when rendering to floating-point color buffers.
A floating-point color buffer can also be used as a texture map, either by
reading back the contents and then using conventional TexImage calls, or
by using the buffer directly via the ARB_render_texture extension.
This extension has many uses. Some possible uses include:
(1) Multi-pass algorithms with arbitrary intermediate results that
don't have to be artifically forced into the range [0,1]. In
addition, intermediate results can be written without having to
worry about out-of-range values.
(2) Deferred shading algorithms where an expensive fragment program is
executed only after depth testing is fully complete. Instead, a
simple program is executed, which stores the parameters necessary
to produce a final result. After the entire scene is rendered, a
second pass is executed over the entire frame buffer to execute
the complex fragment program using the results written to the
floating-point color buffer in the first pass. This will save the
cost of applying complex fragment programs to fragments that will
not appear in the final image.
(3) Use floating-point texture maps to evaluate functions with
arbitrary ranges. Arbitrary functions with a finite domain can be
approximated using a texture map holding sample results and
piecewise linear approximation.
There are several significant limitations on the use of floating-point
color buffers. First, floating-point color buffers do not support frame
buffer blending. Second, floating-point texture maps do not support
mipmapping or any texture filtering other than NEAREST. Third,
floating-point texture maps must be 2D, and must use the
NV_texture_rectangle extension.
IP Status
NVIDIA Proprietary.
NVIDIA Confidential.
Issues
Should the extension create a separate non-RGBA pixel formats or simply
extend existing RGBA formats?
RESOLVED: Extend existing RGBA formats. Since fragment programs
generally build on RGBA semantics, it's cleaner to avoid creating a
separate "XYZW" mode. There are several special semantics that need
to be added: clear color state is now not clamped, and ReadPixels
will clamp to [0,1] only if the source data comes from fixed-point
color buffers.
Fragment programs can be written that store data completely unrelated
to color into a floating-point "RGBA" buffer.
Can floating-point color buffers be displayed? If so, how?
RESOLVED: Not in this extension. Floating-point color buffers can be
used only as pbuffers. Hardware necessary to display floating-point
color buffers would be expensive and consume significant memory
bandwidth.
Is it possible to encode more than four distinct values in a
floating-point color buffer?
RESOLVED: Yes. The NV_fragment_program extension contains pack and
unpack instructions (PK2H, PK2US, PK4B, PK4UB, PK4UBG, UP2H, UP2US,
UP4B, UP4UB, UP4UBG) that allow fragment programs to encode multiple
values into a single 32-bit component. In particular, it is possible
to pack two half-precision floats, two normalized unsigned shorts, or
four normalized signed or unsigned bytes into a single 32-bit
component.
A program can use a pack instruction to pack multiple values into a
single 32-bit component and then write the resulting component to a
floating-point color buffer with 32-bit components. On a subsequent
rendering pass, a program can read back the stored data (using texture
mapping) and use the equivalent unpack instruction to restore the
original values. The only data lost in this process comes from the
loss of precision or clamping in the packing operation, where the
original values are converted to data types with lower precision or a
smaller data range.
What happens when rendering to an floating-point color buffer if fragment
program mode is disabled? Or when fragment program mode is enabled, but
no program is loaded?
RESOLVED: Fragment programs are required to use floating-point color
buffers. An INVALID_OPERATION error is generated by any GL command
that generates fragments if FRAGMENT_PROGRAM_NV is disabled. The same
behavior already exists for conventional frame buffers if
FRAGMENT_PROGRAM_NV is enabled but the bound fragment program is
invalid.
Should alpha test be supported with floating-point color buffers?
RESOLVED: No. It is trivial to implement an alpha test in a fragment
program using the KIL instruction, which requires no dedicated frame
buffer logic.
Should blending be supported with floating-point color buffers?
RESOLVED: Not in this extension. While blending would clearly be
useful, full-precision floating-point blenders are expensive. In
addition, a computational model more general than traditional blending
(with its 1-x operations and clamping) is desirable. The traditional
OpenGL blending model would not be the most suitable computational
model for future blend-enabled floating-point color buffers.
An alternative to conventional blending (operating at a coarser
granularity) is to (1) render a pass into the color buffer, (2) bind
the color buffer as a texture rectangle using this extension and
ARB_render_texture, (3) perform texture lookups in a fragment program
using the TEX instruction with f[WPOS].xy as a 2D texture coordinate,
and (4) perform the necessary blending between the passes using the
same fragment program.
Should we provide accumulation buffers for pixel formats with
floating-point color buffers?
RESOLVED: No. Accumulation operations contents can be achieved using
fragment programs to perform the accumulation, which requires no
dedicated frame buffer logic.
Should fragment program color results be converted to match the format of
the frame buffer, or should an error result? For example, what if we
write to o[COLR] but have a 16-bit frame buffer?
RESOLVED: Conversions can be performed simply in hardware, so no
error semantics are required. This mechanism also allows the same
programs to be shared between contexts with different pixel formats.
Applications should be aware that if color components contain packed
data, a data type mismatch may result in a floating-point data
conversion that corrupts the packed data.
How should floating-point color buffers interact with multisampling? For
normal color buffers, the multiple samples for each pixel are required to
be filtered down to a single pixel in the color buffer. Similar filtering
on floating-point color buffers does not necessarily make sense. Should
there even be a normal color buffer in this case?
RESOLVED: The initial implementation of this extension does not
provide floating-point color buffers that support multisampling.
Multisample fragment operations (e.g., SAMPLE_COVERAGE) are explicitly
not supported by extension. This extension does not modify the
portion of the spec where multiple samples are resolved to a single
color value. So if floating-point color buffers were provided, the
multiple samples are filtered down to a single result value, most
likely by computing a per-component average value.
Conventional RGBA primitive antialiasing multiplies coverage by the alpha
component of the fragment's color, with the assumption that alpha blending
will be performed. How does antialiasing work with floating-point color
buffers?
RESOLVED: It doesn't. The computed coverage is not accessible to
fragment programs and is discarded. Note also that conventional
antialiasing requires alpha blending, which does not work for
floating-point color buffers.
What are the semantics for ReadPixels when using an floating-point color
buffer?
RESOLVED: ReadPixels from a floating-point color buffer works like
any other RGBA read, except that the final results are not clamped to
the range [0,1]. This ensures that we can save and restore
floating-point color buffers using ReadPixels/DrawPixels.
What are the semantics for Bitmap when using an floating-point color
buffer?
RESOLVED: Bitmap generates fragments using the current raster
attributes, which are then passed to fragment programs like any other
fragments. Bitmaps will be drawn using the color of the current
raster position, whose components are clamped to [0,1] when the raster
position is sent.
What are the semantics for DrawPixels when using a floating-point color
buffer? How about CopyPixels?
RESOLVED: DrawPixels generates fragments with the originally
specified color values; components are not clamped to [0,1]. For
fixed-point color buffers, DrawPixels will generate fragments with
clamped color components.
CopyPixels is defined in the spec as a ReadPixels followed by a
DrawPixels, and will operate similarly.
This mechanism allows applications to write floating-point data
directly into a floating-point color buffer without any clamping.
Since DrawPixels and CopyPixels generate fragments and fragment
programs are required to render to floating-point color buffers, a
fragment program is still required to load a floating-point color
buffer using DrawPixels.
What are the semantics for Clear when using an floating-point color
buffer?
RESOLVED: Clears work as normal, except that values outside the range
[0,1] can be written to the color buffer. The core spec is modified
so that clear color values are not clamped to [0,1]. Instead, for
fixed-point color buffers, clear colors are clamped to [0,1] at clear
time.
For compatibility with conventional OpenGL, queries of
CLEAR_COLOR_VALUE will clamp components to [0,1]. A separate
FLOAT_CLEAR_COLOR_VALUE_NV query is added to query unclamped color
clear values.
Why don't floating-point textures support filtering? What can be done to
achieve texture filtering?
RESOLVED: Extended OpenGL texture filtering (including mipmapping and
support for anisotropic filters) is very computationally expensive.
Even simple linear filtering for floating-point textures with large
components is expensive.
Linear filters can be implemented in fragment programs by doing
multiple lookups into the same texture. Since fragment programs allow
the use of arbitrary coordinates into arbitrary texture maps, this
type of operation can be easily done.
A 1D linear filter can be implemented using an nx1 texture rectangle
with the following (untested) fragment program, assuming the 1D
coordinate is in f[TEX0].x:
ADDR H2.xy, f[TEX0].x, {0.0, 1.0};
FRCH H3.x, R1.x; # compute the blend factor
TEX H0, H2.x, TEX0, RECT; # lookup 1st sample
TEX H1, H2.y, TEX0, RECT; # lookup 2nd sample
LRPH H0, H3.x, H1, H0; # blend
A 2D linear filter can be implemented similarly, assuming the 2D
coordinate is in f[TEX0].xy:
ADDH H2, f[TEX0].xyxy, {0.0, 0.0, 1.0, 1.0};
FRCH H3.xy, H2.xyxy; # base weights
ADDH H3.zw, 1.0, -H3.xyxy; # 1-base weights
MULH H3, H3.xzxz, H3.yyww; # bilinear filter weights
TEX H1, R2.xyxy, TEX0, RECT; # lookup 1st sample
MULH H0, H1, H3.x; # blend
TEX H1, R2.zyzy, TEX0, RECT; # lookup 2nd sample
MADH H0, H1, H3.y, H0; # blend
TEX H0, R2.xwxw, TEX0, RECT; # lookup 3rd sample
MADH H0, H1, H3.z, H0; # blend
TEX H1, R2.zwzw, TEX0, RECT; # lookup 4th sample
MADH H0, H1, H3.w, H0; # blend
Fragment programs can be used to perform more-or-less arbitrary
filtering using similar methods, and the DDX and DDY instructions can
be used to refine the shape of the filter.
Why must the NV_texture_rectangle extension be used in order to use
floating-point texture maps?
RESOLVED: On many graphics hardware platforms, texture maps are
stored using a special memory encodings designed to optimize rendering
performance. In current hardware, conventional texture maps usually
top out at 32 bits per texel. The logic required to encode and decode
128-bit texels (and frame buffer pixels) optimally is substantially
more complex.
What happens if you try to use an floating-point texture without a
fragment program?
RESOLVED: No error is generated, but that texture is effectively
disabled. This is similar to the behavior if an application tried to
use a normal texture having an inconsistent set of mipmaps.
How does NV_float_buffer interact with the OpenGL 1.2 imaging subset?
RESOLVED: The imaging subset as specified should work properly with
floating-point color buffers, but is not modified by this extension.
There are imaging operations (e.g., color tables, histograms) that
expect the components they operate on to be in the range [0,1], and
this extension makes no attempt to extend such functionality.
How does NV_float_buffer interact with SGIS_generate_mipmap?
RESOLVED: Since this extension supports only texture rectangles
(which have no mipmaps), this issue is moot.
In the general case, mipmaps should be generated using an appropriate
downsample filter, where floating-point component values are averaged.
Components should not be clamped during any such mipmap generation.
What is the deal with the names of the clear color query tokens?
RESOLVED: The "normal" OpenGL clear color (clamped to [0,1]) is
queried using the token COLOR_CLEAR_VALUE. This extension provides a
new query for unclamped values, using the token
FLOAT_CLEAR_COLOR_VALUE_NV. Notice that "CLEAR" and "COLOR" are
reversed due to a mistake made when the spec was first written. This
spec lists the core query token, and originally had "CLEAR" and
"COLOR" reversed there, too.
Then again, the core specification is inconsistent since the queried
state is set by calling glClearColor(), with "Clear" before "Color".
What performance issues exist with this functionality?
See the "NV3x Implementation Issues" section of the
specification.
How should the texture border color (values) be handled for float
textures?
RESOLVED: Clamp the texture border color (values) to [0,1]
when sampling a float texture's border. In core OpenGL 1.0, the
texture border color components are clamped to the range [01,].
The NV_texture_shader extension added support for signed texture
components. We decided to provide GL_TEXTURE_BORDER_VALUES as
a way of specifying a version of the texture border color whose
components were not clamped to [0,1] when set. This was to
provide a way of specifying negative texture border components.
In practice, that has not proven particularly useful. No real
applications are known to have specified negative texture border
values components.
Ideally, the unclamped GL_TEXTURE_BORDER_VALUES state could
provide an unclamped (unmassaged) set of floating-point color
components for the texture border color. This requires an
additional 96 bits of state per texture unit to support this,
and based on the experience with NV_texture_shader's support for
texture border values outside the [0,1] range, it is simply not
worth it.
For compatibility with the NV_texture_shader extension, we
provide language saying that floating-point textures clamp
the components of the TEXTURE_BORDER_VALUES vector [0,1] when
sampling the border color.
None.
Accepted by the <internalformat> parameter of TexImage2D and
CopyTexImage2D:
FLOAT_R_NV 0x8880
FLOAT_RG_NV 0x8881
FLOAT_RGB_NV 0x8882
FLOAT_RGBA_NV 0x8883
FLOAT_R16_NV 0x8884
FLOAT_R32_NV 0x8885
FLOAT_RG16_NV 0x8886
FLOAT_RG32_NV 0x8887
FLOAT_RGB16_NV 0x8888
FLOAT_RGB32_NV 0x8889
FLOAT_RGBA16_NV 0x888A
FLOAT_RGBA32_NV 0x888B
Accepted by the <pname> parameter of GetTexLevelParameterfv and
GetTexLevelParameteriv:
TEXTURE_FLOAT_COMPONENTS_NV 0x888C
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
and GetDoublev:
FLOAT_CLEAR_COLOR_VALUE_NV 0x888D
FLOAT_RGBA_MODE_NV 0x888E
Accepted in the <piAttributes> array of wglGetPixelFormatAttribivARB and
wglGetPixelFormatAttribfvARB and in the <piAttribIList> and
<pfAttribFList> arrays of wglChoosePixelFormatARB:
WGL_FLOAT_COMPONENTS_NV 0x20B0
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV 0x20B1
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV 0x20B2
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV 0x20B3
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV 0x20B4
Accepted in the <piAttribIList> array of wglCreatePbufferARB and returned
in the <value> parameter of wglQueryPbufferARB when <iAttribute> is
WGL_TEXTURE_FORMAT_ARB:
WGL_TEXTURE_FLOAT_R_NV 0x20B5
WGL_TEXTURE_FLOAT_RG_NV 0x20B6
WGL_TEXTURE_FLOAT_RGB_NV 0x20B7
WGL_TEXTURE_FLOAT_RGBA_NV 0x20B8
Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation)
None.
Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization)
Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 91)
(modify first paragraph of "Final Conversion", p. 102) ... For RGBA
components, the final conversion depends on the format of the color
buffer. If the components of the color buffer are fixed-point, each
element is clamped to [0,1] and converted to fixed-point according to the
rules given in section 2.13.9 (Final Color Processing). If the components
of the color buffer are floating-point, the elements are not modified.
Modify Section 3.8.1, Texture Image Specification (p. 116)
(modify last paragaph, p. 116) The selected groups are processed exactly
as for DrawPixels stopping just before final conversion. For textures
with fixed-point RGBA internal formats, each R, G, B, A component is
clamped to [0,1].
(modify first paragraph, p. 117) Components are then selected from the
resulting pixel groups to obtain a texture with the base internal format
specified by (or derived from) <internalformat>. Table 3.15 summarizes
the mapping of pixel group values to texture components, ...
(add to end of first paragraph, p. 117) Specifying a value of <format>
incompatible with <internalformat> produces the error INVALID_OPERATION.
A pixel format and texture internal format are compatible if the pixel
format can generate a pixel group of the type listed in the "Pixel Group
Type" column of Table 3.15 in the row corresponding to the base internal
format.
(add between first and second paragraphs, p.117) Textures with a base
internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, and
FLOAT_RGBA_NV are known as floating-point textures. Floating-point
textures are only supported for the TEXTURE_RECTANGLE_NV target.
Specifying an floating-point texture with any other target will produce an
INVALID_OPERATION error.
(modify last paragraph, p. 117) The internal component resolution is the
number of bits allocated to each component in a texture image. If
internalformat is specified as a base internal format, the GL stores the
resulting texture with internal component resolutions of its own choosing.
If a sized internal format is specified, the memory allocation per texture
component is assigned by the GL to match the allocations listed in Table
3.16 as closely as possible. ...
(modify Table 3.15, p. 118 -- Respecify this table with all extensions
relevant to texture formats supported by NVIDIA. For this extension, add
four base internal formats.)
Base Internal Pixel Component Internal
Format Group Type Values Components
--------------------- ---------- --------- ---------------
ALPHA RGBA A A
LUMINANCE RGBA R L
LUMINANCE_ALPHA RGBA R,A L,A
INTENSITY RGBA R I
RGB RGBA R,G,B R,G,B
RGBA RGBA R,G,B,A R,G,B,A
* COLOR_INDEX CI CI CI
* DEPTH_COMPONENT DEPTH DEPTH DEPTH
* HILO_NV HILO HI,LO HI,LO
* DSDT_NV TEXOFF DS,DT DS,DT
* DSDT_MAG_NV TEXOFF DS,DT,MAG DS,DT,MAG
* DSDT_MAG_INTENSITY_NV TEXOFF
or RGBA DS,DT,MAG,VIB DS,DT,MAG,I
FLOAT_R_NV RGBA R R (float)
FLOAT_RG_NV RGBA R,G R,G (float)
FLOAT_RGB_NV RGBA R,G,B R,G,B (float)
FLOAT_RGBA_NV RGBA R,G,B,A R,G,B,A (float)
Table 3.15: Conversion from pixel groups to internal texture
components. "Pixel Group Type" defines the type of pixel group
required for the specified internal format. All internal components
are stored as unsigned-fixed point numbers, except for DS/DT (signed
fixed-point numbers) and floating-point R,G,B,A (signed floating-point
numbers). See Section 3.8.12 for a description of texture components
R, G, B, A, L, and I. See NV_texture_shader spec (Section 3.8.13) for
a description of texture components HI, LO, DS, DT, and MAG.
* - indicates formats found in other extension specs: COLOR_INDEX in
EXT_paletted texture; DEPTH_COMPONENT in SGIX_depth_texture; and
HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV in
NV_texture_shader.
(modify Table 3.16, p. 119 -- Respecify this table with all extensions
relevant to sized texture internal formats supported by NVIDIA. For this
extension, add eight sized internal formats.)
Sized Base
Int. Format Int. Format Component Name / Type-Size
------------------- --------------- ---------------------------
ALPHA4 ALPHA A/U4
ALPHA8 ALPHA A/U8
ALPHA12 ALPHA A/U12
ALPHA16 ALPHA A/U16
LUMINANCE4 LUMINANCE L/U4
LUMINANCE8 LUMINANCE L/U8
LUMINANCE12 LUMINANCE L/U12
LUMINANCE16 LUMINANCE L/U16
LUMINANCE4_ALPHA4 LUMINANCE_ALPHA A/U4 L/U4
LUMINANCE6_ALPHA2 LUMINANCE_ALPHA A/U2 L/U6
LUMINANCE8_ALPHA8 LUMINANCE_ALPHA A/U8 L/U8
LUMINANCE12_ALPHA4 LUMINANCE_ALPHA A/U4 L/U12
LUMINANCE12_ALPHA12 LUMINANCE_ALPHA A/U12 L/U12
LUMINANCE16_ALPHA16 LUMINANCE_ALPHA A/U16 L/U16
INTENSITY4 INTENSITY I/U4
INTENSITY8 INTENSITY I/U8
INTENSITY12 INTENSITY I/U12
INTENSITY16 INTENSITY I/U16
R3_G3_B2 RGB R/U3 G/U3 B/U2
RGB4 RGB R/U4 G/U4 B/U4
RGB5 RGB R/U5 G/U5 B/U5
RGB8 RGB R/U8 G/U8 B/U8
RGB10 RGB R/U10 G/U10 B/10
RGB12 RGB R/U12 G/U12 B/U12
RGB16 RGB R/U16 G/U16 B/U16
RGBA2 RGBA R/U2 G/U2 B/U2 A/U2
RGBA4 RGBA R/U4 G/U4 B/U4 A/U4
RGB5_A1 RGBA R/U5 G/U5 B/U5 A/U1
RGBA8 RGBA R/U8 G/U8 B/U8 A/U8
RGB10_A2 RGBA R/U10 G/U10 B/U10 A/U2
RGBA12 RGBA R/U12 G/U12 B/U12 A/U12
RGBA16 RGBA R/U16 G/U16 B/U16 A/U16
* COLOR_INDEX1_EXT COLOR_INDEX CI/U1
* COLOR_INDEX2_EXT COLOR_INDEX CI/U2
* COLOR_INDEX4_EXT COLOR_INDEX CI/U4
* COLOR_INDEX8_EXT COLOR_INDEX CI/U8
* COLOR_INDEX16_EXT COLOR_INDEX CI/U16
* DEPTH_COMPONENT16_SGIX DEPTH_COMPONENT Z/U16
* DEPTH_COMPONENT24_SGIX DEPTH_COMPONENT Z/U24
* DEPTH_COMPONENT32_SGIX DEPTH_COMPONENT Z/U32
* HILO16_NV HILO HI/U16 LO/U16
* SIGNED_HILO16_NV HILO HI/S16 LO/S16
* SIGNED_RGBA8_NV RGBA R/S8 G/S8 B/S8 A/S8
* SIGNED_RGB8_
UNSIGNED_ALPHA8_NV RGBA R/S8 G/S8 B/S8 A/U8
* SIGNED_RGB8_NV RGB R/S8 G/S8 B/S8
* SIGNED_LUMINANCE8_NV LUMINANCE L/S8
* SIGNED_LUMINANCE8_
ALPHA8_NV LUMINANCE_ALPHA L/S8 A/S8
* SIGNED_ALPHA8_NV ALPHA A/S8
* SIGNED_INTENSITY8_NV INTENSITY I/S8
* DSDT8_NV DSDT_NV DS/S8 DT/S8
* DSDT8_MAG8_NV DSDT_MAG_NV DS/S8 DT/S8 MAG/U8
* DSDT8_MAG8_ DSDT_MAG_
INTENSITY8_NV INTENSITY_NV DS/S8 DT/S8 MAG/U8 I/U8
FLOAT_R16_NV FLOAT_R_NV R/F16
FLOAT_R32_NV FLOAT_R_NV R/F32
FLOAT_RG16_NV FLOAT_RG_NV R/F16 G/F16
FLOAT_RG32_NV FLOAT_RG_NV R/F32 G/F32
FLOAT_RGB16_NV FLOAT_RGB_NV R/F16 G/F16 B/F16
FLOAT_RGB32_NV FLOAT_RGB_NV R/F32 G/F32 B/F32
FLOAT_RGBA16_NV FLOAT_RGBA_NV R/F16 G/F16 B/F16 A/F16
FLOAT_RGBA32_NV FLOAT_RGBA_NV R/F32 G/F32 B/F32 A/F32
Table 3.16: Sized Internal Formats. Describes the correspondence of
sized internal formats to base internal formats, and desired component
resolutions. Component resolution descriptions are of the form
"<NAME>/<TYPE><SIZE>", where NAME specifies the component name in
Table 3.15, TYPE is "U" for unsigned fixed-point, "S" for signed
fixed-point, and "F" for unsigned floating-point. <SIZE> is the
number of requested bits per component.
* - indicates formats found in other extension specs: COLOR_INDEX in
EXT_paletted texture; DEPTH_COMPONENT in SGIX_depth_texture; and
HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV in
NV_texture_shader.
Modify Section 3.8,7, Minification (p. 141)
Change the last paragraph (as modified by the NV_texture_shader
extension) to read (only the last sentence changes from the
NV_texture_shader version):
"If any of the selected tauijk, tauij, or taui in the above equations
refer to a border texel with i < -bs, j < bs, k < -bs, i >= ws-bs, j
>= hs-bs, or k >= ds-bs, then the border values given by the current
setting of TEXTURE_BORDER_VALUES is used instead of the unspecified
value or values. If the texture contains color components, the
components of the TEXTURE_BORDER_VALUES vector are interpreted as
an RGBA color to match the texture's internal format in a manner
consistent with table 3.15. If the texture contains HILO components,
the first and second components of the TEXTURE_BORDER_VALUES vector
are interpreted as the hi and lo components respectively. If the
texture contains texture offset group components, the first, second,
third, and fourth components of the TEXTURE_BORDER_VALUES vector
are interpreted as ds, dt, mag, and vib components respectively.
Additionally, the texture border values are clamped appropriately
depending on the signedness of each particular component. Unsigned
components and components of floating-point textures are clamped to
[0,1]; signed components (not including floating-point textures)
are clamped to [-1,1]."
(Add after the last paragraph in the section) Floating-point textures
(those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV,
FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than
NEAREST. For such textures, NEAREST filtering is applied regardless of
the setting of TEXTURE_MIN_FILTER.
Modify Section 3.8.8, Magnification (p. 141)
(Add after the last paragraph in the section) Floating-point textures
(those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV,
FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than
NEAREST. For such textures, NEAREST filtering is applied regardless of
the setting of TEXTURE_MAG_FILTER.
Modify Section 3.8.13, Texture Environments and Texture Functions (p. 147)
(Add paragraph after discussion of all the values used in the
miscellaneous tables in this section.) If the base internal format is
HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV, FLOAT_R_NV,
FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV, the texture lookup results
are not supported using conventional OpenGL texture functions. In this
case, the corresponding texture function is NONE (Cv = Cf, Av = Af), and
it is as though texture mapping were disabled for that texture unit.
Modify Section 3.11, Antialiasing Application (p. 155)
Finally, if antialiasing is enabled for the primitive from which a
rasterized fragment was produced, then the computed coverage value may be
applied to the fragment. In RGBA mode with fixed-point frame buffers, the
value is multiplied by the fragment's alpha (A) value to yield a final
alpha value. In RGBA mode with floating-point frame buffers, the coverage
value is simply discarded. In color index mode, the value is used to set
the low order bits of the color index value as described in section 3.2.
Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment
Operations and the Frame Buffer)
Modify Chapter 4 Introduction (p. 156)
(replace next-to-last paragraph)
The GL provides three types of color buffers: color index, fixed-point
RGBA, or floating-point RGBA. Color index buffers consist of unsigned
integer color indices. Fixed-point RGBA buffers consist of R, G, B, and
optionally, A unsigned integer values. Floating-point RGBA buffers
consist of R, and optionally, G, B, and A floating-point component values,
corresponding to the X, Y, Z, and W outputs, respectively, of a fragment
program. The number of bitplanes in each of the color buffers, the depth
buffer, ...
Modify Section 4.1.3, Multisample Fragment Operations (p. 158)
This step applies only for fixed-point RGBA color buffers. Otherwise,
proceed to the next step. ...
Modify Section 4.1.4, Alpha Test (p. 159)
This step applies only for fixed-point RGBA color buffers. Otherwise,
proceed to the next step. ...
Modify Section 4.1.7, Blending (p. 161)
(modify second paragraph)
This blending is dependent on the incoming fragment's alpha value and that
of the corresponding currently stored pixel. Blending applies only for
fixed-point RGBA color buffers; otherwise, it is bypassed. ...
Modify Section 4.1.8, Dithering (p. 165)
Dithering selects between two color values or indices. Dithering does not
apply to floating-point RGBA color buffers. ...
Modify Section 4.1.9, Logical Operation (p. 165)
Finally, a logical operation is applied between the incoming fragment's
color or index values and the color or index values stored at the
corresponding location in the frame buffer. Logical operations do not
apply to floating-point color buffers. ...
Modify Section 4.2.3, Clearing the Buffers (p. 171)
...
void ClearColor(float r, float g, float b, float a);
sets the clear value for RGBA color buffers. When a fixed-point color
buffer is cleared, the effective clear color is derived by clamping each
component to [0,1] and converting to fixed-point according to the rules in
section 2.13.9. When a floating-point color buffer is cleared, the
components of the clear value are used directly without being clamped.
Modify Section 4.2.4, The Accumulation Buffer (p. 172)
(modify last paragraph) ... If there is no accumulation buffer, or if
color buffer is not fixed-point RGBA, Accum generates the error
INVALID_OPERATION.
Modify Section 4.3.2, Reading Pixels
(modify "Conversion of RGBA Values", p. 176) This step applies only if the
GL is in RGBA mode, and then only if format is neither STENCIL INDEX nor
DEPTH COMPONENT. The R, G, B, and A values form a group of elements. If
the color buffer has fixed-point format, each element is taken to be a
fixed-point value in [0,1] with m bits, where m is the number of bits in
the corresponding color component of the selected buffer (see section
2.13.9).
(add to end of "Final Conversion", p. 177) ... For an RGBA color,
components are clamped depending on the data type of the buffer being
read. For fixed-point buffers, each component is clamped to [0.1]. For
floating-point buffers, if <type> is not FLOAT or HALF_FLOAT_NV, each
component is clamped to [0,1] if <type> is unsigned or [-1,1] if <type> is
signed and then converted according to Table 4.7.
Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions)
None.
Additions to Chapter 6 of the OpenGL 1.3 Specification (State and
State Requests)
Modify Section 6.1.4, Texture Queries (p. 200)
Modify Table 6.1 (add new rows, corresponding to new internal formats,
p. 202)
Base Internal Format R G B A
-------------------- --- --- --- ---
FLOAT_R_NV R 0 0 1
FLOAT_RG_NV R G 0 1
FLOAT_RGB_NV R G B 1
FLOAT_RGBA_NV R G B A
Additions to Appendix A of the OpenGL 1.3 Specification (Invariance)
None.
Additions to the WGL Specification
First, close your eyes and pretend that a WGL specification actually
existed. Maybe if we all concentrate hard enough, one will magically
appear.
Modify/add to the description of <piAttributes> in
wglGetPixelFormatAttribivARB and <pfAttributes> in
wglGetPixelFormatAttribfvARB:
WGL_FLOAT_COMPONENTS_NV
True if the R, G, B, and A components of each color buffer are
represented as (unclamped) floating-point numbers.
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV
True if the pixel format describes a floating-point color that can be
bound to a texture rectangle with internal formats of FLOAT_R_NV,
FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV, respectively. Currently
only pbuffers can be bound as textures so this attribute will only be
TRUE if WGL_DRAW_TO_PBUFFER is also TRUE. Additionally,
floating-point color buffers can not be bound to texture targets other
than TEXTURE_RECTANGLE_NV.
Add new table entries for pixel format attribute matching in
wglChoosePixelFormatARB.
Attribute Type Match Criteria
------------------------- ------- --------------
WGL_FLOAT_COMPONENTS_NV boolean exact
WGL_BIND_TO_TEXTURE_ boolean exact
RECTANGLE_FLOAT_R_NV
WGL_BIND_TO_TEXTURE_ boolean exact
RECTANGLE_FLOAT_RG_NV
WGL_BIND_TO_TEXTURE_ boolean exact
RECTANGLE_FLOAT_RGB_NV
WGL_BIND_TO_TEXTURE_ boolean exact
RECTANGLE_FLOAT_RGBA_NV
(In the wglCreatePbufferARB section, modify the attribute list)
WGL_TEXTURE_FORMAT_ARB
This attribute indicates the base internal format of the texture that
will be created when a color buffer of a pbuffer is bound to a texture
map. It can be set to WGL_TEXTURE_RGB_ARB (indicating an internal
format of RGB), WGL_TEXTURE_RGBA_ARB (indicating a base internal
format of RGBA), WGL_TEXTURE_FLOAT_R_NV (indicating a base internal
format of FLOAT_R_NV), WGL_TEXTURE_FLOAT_RG_NV (indicating a base
internal format of FLOAT_RG_NV), WGL_TEXTURE_FLOAT_RGB_NV (indicating
a base internal format of FLOAT_RGB_NV), WGL_TEXTURE_FLOAT_RGBA_NV
(indicating a base internal format of FLOAT_RGBA_NV), or
WGL_NO_TEXTURE_ARB. The default value is WGL_NO_TEXTURE_ARB.
(In the wglCreatePbufferARB section, modify the discussion of what happens
to the depth/stencil/accum buffers when switching between mipmap levels or
cube map faces.)
For pbuffers with a texture format of WGL_TEXTURE_RGB_ARB,
WGL_TEXTURE_RGBA_ARB, WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV,
WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, there will be a
separate set of color buffers for each mipmap level and cube map face in
the pbuffer. Otherwise, the WGL implementation is free to share a single
set of color, auxillary, and accumulation buffers between levels or faces.
(In the wglCreatePbufferARB section, modify the error list)
ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is
WGL_TEXTURE_FLOAT_R_NV,
WGL_TEXTURE_FLOAT_RG_NV,
WGL_TEXTURE_FLOAT_RGB_NV, or
WGL_TEXTURE_FLOAT_RGBA_NV, and
WGL_TEXTURE_TARGET_ARB is not
WGL_TEXTURE_RECTANGLE_NV.
ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is
WGL_TEXTURE_FLOAT_R_NV,
WGL_TEXTURE_TARGET_ARB is
WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV
attribute is not set in the pixel format.
ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is
WGL_TEXTURE_FLOAT_RG_NV,
WGL_TEXTURE_TARGET_ARB is
WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV
attribute is not set in the pixel format.
ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is
WGL_TEXTURE_FLOAT_RGB_NV,
WGL_TEXTURE_TARGET_ARB is
WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV
attribute is not set in the pixel format.
ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is
WGL_TEXTURE_FLOAT_RGBA_NV,
WGL_TEXTURE_TARGET_ARB is
WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV
attribute is not set in the pixel format.
Modify wglBindTexImageARB:
...
The pbuffer attribute WGL_TEXTURE_FORMAT_ARB determines the base
internal format of the texture. The format-specific component sizes
are also determined by pbuffer attributes as shown in the table below.
The component sizes are dependent on the format of the texture.
Component Size Format
--------- ------------------------ ----------------------------
R WGL_RED_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG,
FLOAT_RGB, FLOAT_RGBA
G WGL_GREEN_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG,
FLOAT_RGB, FLOAT_RGBA
B WGL_BLUE_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG,
FLOAT_RGB, FLOAT_RGBA
A WGL_ALPHA_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG,
FLOAT_RGB, FLOAT_RGBA
Additions to the AGL/GLX Specification
None.
Dependencies on EXT_paletted_texture, SGIX_depth_texture, and NV_texture_shader
If any of these extensions are not supported, the rows in Tables 3.15 and
3.16 corresponding to texture formats defined by the unsupported extension
should be removed.
If NV_texture_shader is not supported, ignore the amended
paragraph from the NV_texture_shader specificiaton describing
TEXTURE_BORDER_VALUES clamping in favor of the original OpenGL
specification language.
Dependencies on NV_half_float
If GL_NV_half_float is not supported, all references to HALF_FLOAT_NV
should be deleted.
GLX Protocol
None.
Errors
INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap, CopyPixels,
or a command that performs an explicit Begin if the color buffer has a
floating-point RGBA format and FRAGMENT_PROGRAM_NV is disabled.
INVALID_OPERATION is generated by TexImage3D, TexImage2D, TexImage1D,
TexSubImage3D, TexSubImage2D, or TexSubImage1D if the pixel group type
corresponding to <format> is not compatible with the base internal format
of the texture.
INVALID_OPERATION is generated by TexImage3D, TexImage1D, or
CopyTexImage1D if the base internal format corresponding to
<internalformat> is FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or
FLOAT_RGBA_NV.
INVALID_OPERATION is generated by TexImage2D or CopyTexImage2D if the base
internal format corresponding to <internalformat> is FLOAT_R_NV,
FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV and <target> is not
TEXTURE_RECTANGLE_NV.
INVALID_OPERATION is generated by Accum if the color buffer has a color
index or floating-point RGBA format.
ERROR_INVALID_DATA is generated by wglCreatePbufferARB if
WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV,
WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, and
WGL_TEXTURE_TARGET_ARB is not WGL_TEXTURE_RECTANGLE_NV.
ERROR_INVALID_DATA is generated by wglCreatePbufferARB if
WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_TARGET_ARB
is WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV attribute is not set in the pixel
format.
ERROR_INVALID_DATA is generated by wglCreatePbufferARB if
WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_TARGET_ARB
is WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV attribute is not set in the
pixel format.
ERROR_INVALID_DATA is generated by wglCreatePbufferARB if
WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGB_NV, WGL_TEXTURE_TARGET_ARB
is WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV attribute is not set in the
pixel format.
ERROR_INVALID_DATA is generated by wglCreatePbufferARB if
WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGBA_NV,
WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the
WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV attribute is not set in the
pixel format.
New State
(Modify Table 6.15, Texture Objects (cont.), p. 223)
Init.
Get Value Type Get Command Value Description Sec. Attribute
--------------------------- ----- ------------ ----- --------------------- ----- ------------
TEXTURE_FLOAT_COMPONENTS_NV n x B GetTexLevel- 0 True if texture holds 3.8 -
unclamped floating-
point values
(Modify Table 6.19, Framebuffer Control, p. 227)
Init.
Get Value Type Get Command Value Description Sec. Attribute
-------------------------- ---- ----------- ------- ------------------------ ----- ------------
COLOR_CLEAR_VALUE C GetFloatv 0,0,0,0 Color buffer clear value 4.2.3 color-buffer
(RGBA mode), each value
clamped to [0,1].
FLOAT_CLEAR_COLOR_VALUE_NV 4xR GetFloatv 0,0,0,0 Color buffer clear value 4.2.3 color-buffer
(RGBA mode), each value
unclamped.
New Implementation Dependent State
(Modify Table 6.28, Implementation Dependent Values, p. 236)
Init.
Get Value Type Get Command Value Description Sec. Attribute
------------------ ---- ----------- ----- --------------------- ---- ---------
FLOAT_RGBA_MODE_NV B GetBooleanv - True if color buffers 4 -
store floating-point
data
NV3x Implementation Details
NV3x GPUs (GeForce FX, etc.) support hardware acceleration for float
textures with two or more components only when the repeat mode state
(S and T) is GL_CLAMP_TO_EDGE. If you use either the GL_CLAMP or
GL_CLAMP_TO_BORDER repeat modes with a float texture with two or
more components, the software rasterizer is used.
However, if you use a single-component float texture (GL_FLOAT_R_NV,
etc.), all clamping repeat modes (GL_CLAMP, GL_CLAMP_TO_EDGE, and
GL_CLAMP_TO_BORDER) are available with full hardware acceleration.
The two-, three-, and four-component texture formats all use the
same amount of texture memory storage (128 bits per texel for the
GL_FLOAT_x32 formats, and 64 bits per texel for the GL_FLOAT_x16
formats). Future GPUs will likely store two and three component
float textures more efficiently.
The GL_FLOAT_R32_NV and GL_FLOAT_R16_NV texture formats each use 32
bits per texel. Future GPUs will likely store GL_FLOAT_R16_NV more
efficiently.
NVIDIA treats the unsized internal formats GL_FLOAT_R_NV,
GL_FLOAT_RGBA_NV, etc. the same as GL_FLOAT_R32_NV,
GL_FLOAT_RGBA32_NV, etc.
Revision History
Rev. Date Author Changes
---- -------- -------- --------------------------------------------
16 06/16/03 pbrown Corrected the usage of WGL_TEXTURE_FLOAT_R_NV and
related enums in the list of enumerants.
15 01/23/03 mjk Document texture border color (values) behavior
for float textures. See issue.
14 01/20/03 mjk Added NV3x Implementation Details section.
13 11/27/02 pbrown Fixed the name of the clear color query enum in
the state table -- the core spec says
COLOR_CLEAR_VALUE. The enum in this extension is
FLOAT_CLEAR_COLOR_VALUE_NV. Documented this
inconsistency.
12 10/09/02 pbrown Clarified that the floating-point internal format
enums can not be passed TexImage1D and
TexImage3D.
11 07/19/02 pbrown Cleaned up a number of items in the issues
section. Removed limitation that DrawPixels and
CopyPixels color components are clamped to
[0,1]. Removed language modifying multisample
color filtering -- if multisample buffers are
supported, the color components will be filtered
on a componentwise basis.
10 07/09/02 pbrown Fixed contradictory issue resolutions.
9 01/31/02 pbrown Added revision history.
8 01/29/02 pbrown Fix spec to indicate that
TEXTURE_FLOAT_COMPONENTS_NV is queried by
GetTexLevelParameter*() calls instead of the
generic gets.
7 12/26/01 pbrown Documented limitation where DrawPixels/CopyPixels
data are clamped to [0,1], even when the color
buffer is floating-point. This is consistent
with the fact that pixel data is supposed to go
in f[COL0] (fixed-point interpolator). Changed
float texture to RGBA expansion to always fill in
with (0,0,0,1), not (0,0,0,0). This is more
consistent with our other texture formats.
6 11/30/01 pbrown Assigned WGL enumerant values.
5 11/27/01 pbrown Modify NV_float_buffer to eliminate the
dependencies on NV_render_depth_texture, now that
they are no longer necessary. More pedantic
fixes.
4 10/29/01 pbrown Add documentation of possible uses of
floating-point color buffers.
3 10/19/01 pbrown Assign GL enumerants. Fixed some bugs in the use
of #defines in the spec. Added ARB_imaging
and SGIS_generate_mipmap interaction issues.
Implementation Support
List of OpenGL implementations supporting the WGL_NV_float_buffer extension
Original File
Original text file for the WGL_NV_float_buffer extension
Page generated on Sun Nov 20 18:39:50 2005