Back to the OpenGL extension cross reference
GLX_ARB_fbconfig_float
ARB_color_buffer_float
Name Strings
GL_ARB_color_buffer_float
WGL_ARB_pixel_format_float
GLX_ARB_fbconfig_float
Contributors
Pat Brown
Jon Leech
Rob Mace
V Moya
Brian Paul
Contact
Dale Kirkland, 3Dlabs (dale.kirkland 'at' 3dlabs.com)
Status
Complete. Appprove by the ARB on October 22, 2004.
Version
Based on the ATI_pixel_format_float extension, verion 5
Enables based on work by Pat Brown from the color_clamp_control proposal
Last Modified Date: October 1, 2004
Version: 5
Number
ARB Extension #39
Dependencies
This extension is written against the OpenGL 2.0 Specification
but will work with the OpenGL 1.5 Specification.
WGL_ARB_pixel_format is required.
This extension interacts with ARB_fragment_program.
This extension interacts with ARB_fragment_shader.
This extension interacts with NV_float_buffer.
This extension interacts with ATI_pixel_format_float.
Overview
The standard OpenGL pipeline is based on a fixed-point pipeline.
While color components are nominally floating-point values in the
pipeline, components are frequently clamped to the range [0,1] to
accomodate the fixed-point color buffer representation and allow
for fixed-point computational hardware.
This extension adds pixel formats or visuals with floating-point
RGBA color components and controls for clamping of color
components within the pipeline.
For a floating-point RGBA pixel format, the size of each float
components is specified using the same attributes that are used
for defining the size of fixed-point components. 32-bit
floating-point components are in the standard IEEE float format.
16-bit floating-point components have 1 sign bit, 5 exponent bits,
and 10 mantissa bits.
Clamping control provides a way to disable certain color clamps
and allow programs, and the fixed-function pipeline, to deal in
unclamped colors. There are controls to modify clamping of vertex
colors, clamping of fragment colors throughout the pipeline, and
for pixel return data.
The default state for fragment clamping is "FIXED_ONLY", which
has the behavior of clamping colors for fixed-point color buffers
and not clamping colors for floating-pont color buffers.
Vertex colors are clamped by default.
IP Status
SGI owns US Patent #6,650,327, issued November 18, 2003. SGI
believes this patent contains necessary IP for graphics systems
implementing floating point (FP) rasterization and FP framebuffer
capabilities.
SGI will not grant the ARB royalty-free use of this IP for use in
OpenGL, but will discuss licensing on RAND terms, on an individual
basis with companies wishing to use this IP in the context of
conformant OpenGL implementations. SGI does not plan to make any
special exemption for open source implementations.
Contact Doug Crisman at SGI Legal for the complete IP disclosure.
Issues
1. How is this extension different from the ATI_pixel_format_float
extension?
RESOLVED: By default, this extension behaves like the
ATI_pixel_format_float, but also adds additional controls for
color clamping.
2. Should the clamp controls be automatically inferred based on
the format of the color buffer or textures used?
RESOLVED: Explicit controls should be supported -- this allows
the use of floating-point buffers to emulate fixed-point
operation, and allows for operating on unclamped values even
when rendering to a fixed-point framebuffer.
However, a default clamping mode called "FIXED_ONLY" is defined
that enables clamping only when rendering to a fixed-point color
buffer, which is the default for fragment processing. This is
done to maintain compatibility with previous extensions
(ATI_pixel_format_float), and to allow applications to switch
between fixed- and floating-point color buffers without having
to change the clamping mode on each switch.
3. How does the clamping control affect the blending equation?
RESOLVED: For fixed-point color buffers, the inputs and the
result of the blending equation are clamped. For floating-point
color buffers, no clamping occurs.
4. Should the requirements for the representable range of color
components be increased?
RESOLVED: No. Such a spec change would be complicated, since
the required precision may vary based on color buffer precision.
Despite the fact that there is no spec requirement, GL
implementations should have at least as much precision/range in
their colors as can be found in the framebuffer.
5. Should the vertex color clamping control apply to RasterPos?
WindowPos?
RESOLVED: Yes to both. RasterPos is processed just like a
vertex, so the vertex color clamping control applies
automatically. The WindowPos language in the OpenGL 2.0
specification explicitly refers to color clamping. Instead,
we modify the language to perform normal processing, but with
lighting forced off. This will result in the color clamping
logic applying.
6. What control should apply to DrawPixels RGBA components?
RESOLVED: The fragment color clamp control.
7. Should this extension modify the clamping of the texture
environment color components? TEXTURE_ENV_COLOR components
are currently specified to be clamped to [0,1] when TexEnv is
called.
RESOLVED: Yes. The texture environment color is no longer
clamped when specified. If fragment color clamping is enabled,
it will be clamped to [0,1] on use.
8. In texture environment application, should color components used
as an interpolation factor (e.g., alpha) be clamped to [0,1]?
RESOLVED: No. For interpolation-type blends, the weighting
factor is normally in the range [0,1]. But the math is well-
defined in the cases where it falls outside this range. When
fragment color clamping is enabled, all sources are clamped to
[0,1], so this is not an issue.
9. In the COMBINE texture environment mode, should any of the
source argument operands be clamped to [0,1] even when fragment
clamping is disabled? For example, ONE_MINUS_* mappings are
simple in a fixed-point pipeline are simple, but more
complicated in a floating-point one.
RESOLVED: No. The math behind ONE_MINUS_* is well-defined for
all inputs.
10. Should the clamping controls affect the texture comparison mode
for shadow mapping?
RESOLVED: No. The r coordinate should still be clamped to
[0,1] to match the depth texture. The result of the
comparison will naturally lie in the range [0,1].
11. Should the clamping controls affect the result of color sum?
RESOLVED: Yes.
12. Should the clamping controls affect the computed fog factor?
RESOLVED: No. The fog factor is not a color -- it is used to
blend between the fragment color and the fog color. The factor
should always be clamped to [0,1].
13. Should this extension modify the clamping of the fog color
components? FOG_COLOR components are specified to be clamped
to [0,1] when Fogfv is called.
RESOLVED: Yes. Fog color components are no longer clamped
when specified, but will be clamped when fog is applied if
fragment color clamping is enabled.
14. How does this extension interact with antialiasing application
(Section 3.12 of the OpenGL 2.0 spec)?
RESOLVED: Multiply floating-point alpha by coverage, even if
the alpha value is not being used as opacity. If applications
don't want this multiplication, they should not render
antialiased primitives. No spec language changes are needed
here.
15. How does this extension interact with multisample point fade
(Section 3.13 of the OpenGL 2.0 spec)?
RESOLVED: Multiply floating-point alpha by the fade factor,
even if the alpha value is not being used as opacity. If
applications don't want this multiplication, they should not
use multisample point fade. No spec language changes are
needed here.
16. Should this extension modify the clamping of the alpha test
reference value?
RESOLVED: Yes. The reference value is not clamped when
specified, by may be clamped when it is used.
17. Should this extension modify the clamping of the constant blend
color components?
RESOLVED: Yes. The blend color is not clamped when specified.
When rendering to a fixed-point framebuffer, the blend color
will be clamped as part of the blending operation.
18. Should this extension modify the clamping of clear colors?
RESOLVED: Yes. The clear color is not clamped when specified.
When clearing color buffers, the clear color is converted to
the format of the color buffer.
19. Should we provide a control to disable implicit clamping of
ReadPixels data? If so, how should it be specified?
RESOLVED: Yes. It is explicitely controlled by the target
CLAMP_READ_COLOR_ARB of the ClampColorARB function and clamps
the color during the final conversion.
20. How does this extension interact with CopyPixels?
RESOLVED: It has no special interaction. CopyPixels is specified
as roughly a ReadPixels/DrawPixels sequence, but the read color
clamp modified by this specification occur during final
conversion and therefore would not apply. The fragment color
clamp does affect the DrawPixels portion of the operation,
however. The net result is that calling CopyPixels with a
floating-point framebuffer will clamp color components if
fragment color clamping is enabled.
21. Should these clamping controls interact with PushAttrib and
PopAttrib? If so, what group should they belong to?
RESOLVED: For consistency, yes. Historically, all enables are
pushed and popped with both the enable bit and a second bit
corresponding to the function performed by the enable. The
present spec calls for pushing the vertex color clamp with the
lighting group and the fragment and read color clamp with the
color-buffer group (for lack of a better choice).
22. Should this extension require a floating-point color buffer
or texture?
RESOLVED: No. This extension provides the ability to pass an
unclamped color between vertex and fragment programs/shaders,
which may be useful. This was possible prior to this extension,
by passing the color data as texture coordinates or named
varying variables (for vertex/fragment shaders).
23. Does this extension interact with the ARB_vertex_program or
ARB_vertex_shader extensions?
RESOLVED: Only in the most trivial way. Both of these
extensions refer to the color clamping logic (Section 2.14.6
in the OpenGL 2.0 specification). This extension modifies that
logic to be under control of the CLAMP_VERTEX_COLOR_ARB enable.
It follows that this enable also controls the clamping of vertex
program or vertex shader results.
24. Does this extension interact with the ARB_fragment_program or
ARB_fragment_shader extensions?
RESOLVED: Yes. The only interaction is that the fragment color
clamp enable determines if the final color(s) produced by the
fragment program/shader has its components clamped to [0,1].
However, the fragment color clamp enable affects only the final
result; it does NOT affect any computations performed during
program execution. Note that the same clamping can be done
explicitly in a fragment program or shader.
ARB_fragment_program provides the "_SAT" opcode suffix to clamp
instruction results to [0,1].
25. Should this extension modify the clamping of the texture border
color components?
RESOLVED: Not by this extension. See the ARB_texture_float
extension.
26. When using vertex and fragment programs/shaders, should color
clamping be specified in the shader instead?
RESOLVED: No. All the existing program/shader extensions call
for the color outputs to be clamped to [0,1], except that
previous floating-point color buffer extensions disabled the
clamp of fragment program/shader outputs.
While it would be straightforward to have required that vertex
or fragment programs manually clamp their outputs if desired,
adding such a requirement at this point would pose compatibility
issues. It would probably require introduction of a special
directive to indicate that colors are unclamped.
If a GL implementation internally performs color clamping in a
vertex or fragment program, it may be necessary to recompile the
program if the corresponding clamp enable changes.
27. If certain colors in the OpenGL state vector were clamped in
previous versions of the spec, but now have the clamping
removed, do queries need to return clamped values for
compatibility with older GL versions? Should we add new query
tokens to return unclamped values?
RESOLVED: To minimize impact on this specification while allowing
for compatibility with older GL versions, the values of the
vertex/fragment color clamp enables should affect queries of such
state. If the corresponding color clamp is enabled, components
will be clamped to [0,1] when returned. Since color clamping is
enabled by default for fixed-point color buffers, the removal of
the clamps will not be observable by applications unless they
disable one or both clamps or choose a floating-point buffer
(which will not happen for "old" applications).
Note that this spec relaxes the clamp on the current raster
color, but we don't need to add a clamp on the corresponding
query. The current raster color is clamped when the GL computes
it, unless vertex color clamping is disabled by the application.
28. At what precision should alpha test be carried out? At the
precision of the framebuffer? Or some other unspecified
precision? What happens if you have a framebuffer with no
alpha?
RESOLVED: No specific precision requirements are added, except
that the reference value used in the alpha test should be
converted to the same precision and in the same manner as the
fragment's alpha. This requirement is intended to avoid cases
where the act of converting the alpha value of a fragment to
fixed-point (or lower-precision floating-point) might change the
result of the test.
29. How does this extension interact with accumulation buffers?
RESOLVED: This extension does not modify the nature of
accumulation buffers. Adding semantics for floating-point
accumulation buffers is left for a possible future extension.
The clamp on the RETURN operation is controlled by the fragment
color clamp enable.
30. How does this extension interact with OpenGL FEEDBACK mode?
RESOLVED: OpenGL FEEDBACK mode returns colors after clipping,
which is done after the vertex color clamping. Therefore, the
colors returned will be clamped to [0,1] if and only if vertex
color clamping is enabled. No spec language changes are
necessary.
31. Should we relax the language in Section 2.14.9 (Final Color
Processing) to not require conversion to fixed-point?
RESOLVED: Adding floating-point vertex colors requires that
this language be modified. Even for the clamped case, it seems
reasonable for implementations to simply clamp a floating-point
value to [0,1] without converting to a fixed-point
representation. This specification makes converting colors to
fixed-point optional. Colors will obviously still be converted
to fixed-point eventually if the framebuffer is fixed-point.
32. What should be done about the "preserving the bits" requirement
for Color*{ub,us,ui} commands in Section 2.14.9?
RESOLVED: If colors are represented as floats internally and
the frame-buffer is fixed-point, do we require that the MSBs of
fixed-point colors that don't go through lighting, and
non-trivial interpolation, or any non-trivial fragment operations
show up in the MSBs of the framebuffer?
33. How does this extension interact with multisample
ALPHA_TO_COVERAGE, where an alpha value expected to be in the
range [0,1] is turned into a set of coverage bits?
UNRESOLVED: For the purposes of generating sample coverage from
fragment alpha, the alpha values are effectively clamped to
[0,1]. Negative alpha values correspond to no coverage; alpha
values greater than one correspond to full coverage.
34. What happens if there are no color buffers in the framebuffer
and a clamp control is set to FIXED_ONLY?
RESOLVED: The present language treats a zero-bit color buffer
as fixed-point.
35. Should the clamping of fragment shader output gl_FragData[n]
be controlled by the fragment color clamp.
RESOLVED: Since the destination of the FragData is a color
buffer, the fragment color clamp control should apply.
36. Should logical operations be disabled for floating-point
color buffers.
RESOLVED: Yes. This matches the behavior in the ATI
specification.
37. Is it expected that a floating-point color read from a
floating-point color buffer exactly match a floating-point
color in a fragment? Will the alpha test of GL_EQUAL
be expected to work?
RESOLVED: This behavior is not required by this extension.
Floating-point data may have different precision at different
parts of the pipeline.
38. How does this extension handle the case where a floating-point
and a fixed-point buffer exists?
RESOLVED: For vertex colors, clamping occurs if any color
buffer are floating point. Fragment colors are handled
based on the format (fixed or float) of the color buffer
that they will be drawn to.
void ClampColorARB(enum target, enum clamp);
Accepted by the <pname> parameters of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
RGBA_FLOAT_MODE_ARB 0x8820
Accepted by the <target> parameter of ClampColorARB and the <pname>
parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev.
CLAMP_VERTEX_COLOR_ARB 0x891A
CLAMP_FRAGMENT_COLOR_ARB 0x891B
CLAMP_READ_COLOR_ARB 0x891C
Accepted by the <clamp> parameter of ClampColorARB.
FIXED_ONLY_ARB 0x891D
FALSE
TRUE
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_FLOAT_ARB 0x21A0
Accepted as values of the <render_type> arguments in the
glXCreateNewContext and glXCreateContext functions
GLX_RGBA_FLOAT_TYPE 0x20B9
Accepted as a bit set in the GLX_RENDER_TYPE variable
GLX_RGBA_FLOAT_BIT 0x00000004
Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
Add a new Section 2.1.2, (p. 6):
2.1.2 16-Bit Floating-Point Numbers
A 16-bit floating-point number has a 1-bit sign (S), a 5-bit
exponent (E), and a 10-bit mantissa (M). The value of a 16-bit
floating-point number is determined by the following:
(-1)^S * 0.0, if E == 0 and M == 0,
(-1)^S * 2^-14 * (M / 2^10), if E == 0 and M != 0,
(-1)^S * 2^(E-15) * (1 + M/2^10), if 0 < E < 31,
(-1)^S * INF, if E == 31 and M == 0, or
NaN, if E == 31 and M != 0,
where
S = floor((N mod 65536) / 32768),
E = floor((N mod 32768) / 1024), and
M = N mod 1024.
Implementations are also allowed to use any of the following
alternative encodings:
(-1)^S * 0.0, if E == 0 and M != 0,
(-1)^S * 2^(E-15) * (1 + M/2^10), if E == 31 and M == 0, or
(-1)^S * 2^(E-15) * (1 + M/2^10), if E == 31 and M != 0,
Any representable 16-bit floating-point value is legal as input
to a GL command that accepts 16-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.
Modify Section 2.13 (Current Raster Position), p. 54
(modify last paragraph on p. 55) Lighting, texture coordinate
generation and transformation, and clipping are not performed by
the WindowPos functions. Instead, in RGBA mode, the current raster
color and secondary color are obtained from the current color and
secondary color, respectively. If vertex color clamping is enable,
the current raster color and secondary color are clamped to [0, 1].
In color index mode, the current raster color index is set to the
current color index. The current raster texture coordinates are
set to the current texture coordinates, and the valid bit is set.
Modify Section 2.14 (Colors and Coloring), p. 57
(modify last paragraph on p.57) ... After lighting, RGBA colors are
optionally clamped to the range [0,1]. ...
Modify Section 2.14.6 (Clamping or Masking), p. 69
(modify first and second paragraphs of section) When the GL is in
RGBA mode and vertex color clamping is enabled, all components of
both primary and secondary colors are clamped to the range [0,1]
after lighting. If color clamping is disabled, the primary and
secondary colors are unmodified. Vertex color clamping is controlled
by calling
void ClampColorARB(enum target, enum clamp)
with a <target> set to VERTEX_COLOR_CLAMP_ARB. If <clamp> is TRUE,
vertex color clamping is enabled; if <clamp> is FALSE, vertex color
clamping is disabled. If <clamp> is FIXED_ONLY_ARB, vertex color
clamping is enabled if all enabled color buffers have fixed-point
components.
For a color index, the index is first converted to...
(add paragraph at the end of the section) The state required for
color clamping is an enumerant. Vertex color clamping is initially
TRUE.
Replace Section 2.14.9 (Final Color Processing), p. 71
In RGBA mode with vertex color clamping disabled, the floating-
point RGBA components are not modified.
In RGBA mode with vertex clamping enabled, each color component
(already clamped to [0,1]) may be converted (by rounding to nearest)
to a fixed-point value with m bits. We assume that the fixed-point
representation used represents each value k/(2^m - 1), with k in the
set {0, 1, . . . , 2^m - 1}, as k (e.g. 1.0 is represented in binary
as a string of all ones). m must be at least as large as the number
of bits in the corresponding component of the framebuffer. m must be
at least 2 for A if the framebuffer does not contain an A component,
or if there is only 1 bit of A in the framebuffer. GL
implementations are not required to convert clamped color components
to fixed-point.
Because a number of the form k/(2^m - 1) may not be represented
exactly as a limited-precision floating-point quantity, we place a
further requirement on the fixed-point conversion of RGBA
components. Suppose that lighting is disabled, the color associated
with a vertex has not been clipped, and one of Colorub, Colorus, or
Colorui was used to specify that color. When these conditions are
satisfied, an RGBA component must convert to a value that matches
the component as specified in the Color command: if m is less than
the number of bits b with which the component was specified, then
the converted value must equal the most significant m bits of the
specified value; otherwise, the most significant b bits of the
converted value must equal the specified value.
In color index mode, a color index is converted (by rounding to
nearest) to a fixed-point value with at least as many bits as there
are in the color index portion of the framebuffer.
Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
Modify Section 3.6.4 (Rasterization of Pixel Rectangles), p. 126
(modify next-to-last paragraph, p.136, "Final Conversion") ... For
RGBA components, if fragment color clamping is enabled, each
element is clamped to [0,1], and may be converted to fixed-point
according to the rules given in section 2.14.9 (Final Color
Processing). If fragment color clamping is disabled, RGBA
components are unmodified. Fragment color clamping is controlled
using ClampColorARB, as described in section 2.14.6, with a
<target> of FRAGMENT_COLOR_CLAMP_ARB.
(add new paragraph at the end of "Final Conversion", p.137) The
state required for fragment color clamping is an enumerant.
Fragment color clamping is initially set to FIXED_ONLY_ARB.
Modify Section 3.8.13 (Texture Environments and Functions), p.182
(modify third paragraph, p. 183, removing clamping language)
...TEXTURE_ENV_COLOR is set to an RGBA color by providing four
single-precision floating-point values. If integers are provided
for TEXTURE ENV COLOR, then they are converted to floating-point
as specified in table 2.9 for signed integers.
(replace the sixth paragraph of p. 183) If fragment color clamping
is enabled, all of these color values, including the results, are
clamped to the range [0,1]. If fragment color clamping is
disabled, the values are not clamped. The texture functions are
specified in tables 3.22, 3.23, and 3.24.
(modify seventh paragraph of p. 183) ... ALPHA_SCALE, respectively.
If fragment color clamping is enabled, the arguments and results
used in table 3.24 are clamped to [0,1]. Otherwise, the results
are unmodified.
Modify Section 3.9 (Color Sum), p. 191
(modify second paragraph) ... the A component of c_sec is unused.
If color sum is disabled, then c_pri is assigned to c. The
components of c are then clamped to the range [0,1] if and only
if fragment color clamping is enabled.
Modify Section 3.10 (Fog), p. 191
(modify fourth paragraph, p. 192, removing clamping language) ...If
these are not floating-point values, then they are converted to
floating-point using the conversion given in table 2.9 for signed
integers. If fragment color clamping is enabled, the components of
C_r and C_f and the result C are clamped to the range [0,1] before
the fog blend is performed.
Modify Section 3.11.2 (Shader Execution), p. 194
(modify Shader Inputs, first paragraph, p. 196) The built-in
variables gl_Color and gl_SecondaryColor hold the R, G, B, and A
components, respectively, of the fragment color and secondary
color. If the primary color or the secondary color components are
represented by the GL as fixed-point values, they undergo an
implied conversion to floating-point. This conversion must leave
the values 0 and 1 invariant. Floating-point color components
(resulting from a disabled vertex color clamp) are unmodified.
(modify Shader Outputs, first paragraph, p. 196) ... These are
gl_FragColor, gl_FragData[n], and gl_FragDepth. If fragment
clamping is enabled, the final fragment color values or the final
fragment data values written by a fragment shader are clamped to
the range [0, 1] and then may be converted to fixed-point as
described in section 2.14.9. If fragment clamping is disabled,
the final fragment color values or the final fragment data values
are not modified. The final fragment depth...
Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment
Operations and the Framebuffer)
Modify Chapter 4 Introduction, (p. 198)
(modify third paragraph, p. 198) Color buffers consist of either
unsigned integer color indices, R, G, B and optionally A unsigned
integer values, or R, G, B, and optionally A floating-point values.
The number of bitplanes...
Modify Section 4.1.3 (Multisample Fragment Operations), p. 200
(modify last paragraph, p. 200) ...and all 0's corresponding to all
alpha values being 0. The alpha values used to generate a coverage
value are clamped to the range [0,1]. It is also intended ...
Modify Section 4.1.5 (Alpha Test), p. 201
(modify first paragraph of section, deleting clamping of
reference value) ... The test is controlled with
void AlphaFunc(enum func, float ref);
func is a symbolic constant indicating the alpha test function;
ref is a reference value. When performing the alpha test, the GL
will convert the reference value to the same representation as the
the fragment's alpha value (floating-point or fixed-point).
For fixed-point, the reference value is converted according to the
rules given for an A component in section 2.14.9 and the fragment's
alpha value is rounded to the nearest integer. The possible ...
Modify Section 4.1.8 (Blending), p. 205
(modify first paragraph, p. 206) Source and destination values are
combined according to the blend equation, quadruplets of source and
destination weighting factors determined by the blend functions, and
a constant blend color to obtain a new set of R, G, B, and A values,
as described below.
If the color buffer is fixed-point, the components of the source
and destination values and blend factors are clamped to [0, 1]
prior to evaluating the blend equation, the components of the
blending result are clamped to [0,1] and converted to fixed-
point values in the manner described in section 2.14.9. If the
color buffer is floating-point, no clamping occurs. The
resulting four values are sent to the next operation.
(modify fifth paragraph, p. 206) Fixed-point destination
(framebuffer) components are taken to be fixed-point values
represented according to the scheme given in section 2.14.9
(Final Color Processing). Constant color components, floating-
point destination components, and source (fragment) components are
taken to be floating point values. If source components are
represented internally by the GL as either fixed-point values they
are also interepreted according to section 2.14.9.
(modify Blend Color section removing the clamp, p. 209) The
constant color C_c to be used in blending is specified with the
command
void BlendColor(float red, float green, float blue, float alpha);
The constant color can be used in both the source and destination
blending functions.
Replace Section 4.1.9 (Dithering), p. 209
Dithering selects between two representable color values or indices.
A representable value is a value that has an exact representation in
the color buffer. 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. The
selection may depend on the x_w and y_w coordinates of the pixel, as
well as on the exact value of c. If one of the two values does not
exist, then the selection defaults to the other value.
In color index mode dithering selects either the largest
representable index that is less than or equal to the incoming
color value, c, or the smallest representable index that is greater
than or equal to c. If one of the two indices does not exist, then
the selection defaults to the other value.
Many dithering selection algorithms are possible, but an individual
selection must depend only on the incoming color index or component
value and the fragment's x and y window coordinates. 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; a color index is rounded to the nearest representable index
value.
Dithering is enabled with Enable and disabled with Disable using the
symbolic constant DITHER. The state required is thus a single bit.
Initially dithering is enabled.
Section 4.1.10 (Logical Operation), p. 210
(insert after the first sentence, p. 210) Logical operation has no
effect on a floating-point destination color buffer. However, if
COLOR_LOGIC_OP is enabled, blending is still disabled.
Modify Section 4.2.3 (Clearing the Buffers), p. 215
(modify second paragraph, p. 216, removing clamp of clear color)
void ClearColor(float r, float g, float b, float a);
sets the clear value for the color buffers in RGBA mode.
(add to the end of first partial paragraph, p. 217) ... then a
Clear directed at that buffer has no effect. Fixed-point RGBA
color buffers are cleared to a color values derived by taking the
clear color, clamping to [0,1], and converting to fixed-point
according to the rules of section 2.14.9.
Modify Section 4.2.4 (The Accumulation Buffer), p. 217
(modify second paragraph in section, p. 217) ... Using ACCUM
obtains R, G, B, and A components from the color buffer currently
selected for reading (section 4.3.2). If the color buffer is
fixed-point, each component is considered as a fixed-point value
in [0,1] (see section 2.14.9) and is converted to floating-point.
Each result is then multiplied ...
(modify second paragraph on p. 218) The RETURN operation takes
each color value from the accumulation buffer and multiplies each
of the R, G, B, and A components by <value>. If fragment color
clamping is enabled, the results are then clamped to the range
[0,1]. ...
Modify Section 4.3.2 (Reading Pixels), p. 219
(modify paragraph at top of page, p. 222) ... For a fixed-point
color buffer, 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.14.9). For floating-point color buffer, the elements
are unmodified.
(modify second paragraph of "Final Conversion", p. 222) For an
RGBA color, if <type> is not FLOAT, or if the CLAMP_READ_COLOR_ARB
is TRUE, or CLAMP_READ_COLOR_ARB is FIXED_ONLY_ARB and the selected
color buffer is a fixed-point buffer, each component is first
clamped to [0,1]. Then the appropriate conversion...
Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
None
Additions to Chapter 6 of the OpenGL 2.0 Specification (State and
State Requests)
Modify Section 6.1.2, Data Conversions, p. 245
(add new paragraph at the end of the section, p. 245) If fragment
color clamping is enabled, querying of the texture border color,
texture environment color, fog color, alpha test reference value,
blend color, and RGBA clear color will clamp the corresponding
state values to [0,1] before returning them. This behavior
provides compatibility with previous versions of the GL that
clamped these values when specified.
Additions to Chapter 1 of the GLX 1.3 Specification (Overview)
None
Additions to Chapter 2 of the GLX 1.3 Specification (GLX Operation)
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_FOAT_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 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_FLOAT_BIT set.
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_FLOAT_TYPE then a
context that supports floating point RGBA rendering is
created.
Additions to Chapter 4 of the GLX 1.3 Specification (Encoding on the
X Byte Stream)
None
Additions to Chapter 5 of the GLX 1.3 Specification (Extending
OpenGL)
None
Additions to Chapter 6 of the GLX 1.3 Specification (GLX Versions)
None
Additions to Chapter 7 of the GLX 1.3 Specification (Glossary)
None
Additions to the GLX Specification
Modify the bit field GLX_RENDER_TYPE to:
GLX_RENDER_TYPE
The type of pixel data. This bit field can have the
following bit set: GLX_RGBA_BIT, GLX_RGBA_FLOAT_BIT,
GLX_COLOR_INDEX_BIT
Adds to the accepted values of the <render_type> argument
in the glXCreateNewContext and glXCreateContextWithSGIX
functions to:
<render_type>
Type of rendering context requested. This argument
can have the following values: GLX_RGBA_TYPE,
GLX_RGBA_FLOAT_TYPE, GLX_COLOR_INDEX_TYPE
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, or WGL_TYPE_COLORINDEX_ARB.
Dependencies on WGL_ARB_pixel_format
The WGL_ARB_pixel_format extension must be used to determine a
pixel format with float components.
Dependencies on ARB_fragment_program
(modify 2nd paragraph of Section 3.11.4.4 language) If fragment
color clamping is enabled, the fragment's color components are first
clamped to the range [0,1] and are optionally converted to fixed
point as in section 2.14.9. If the fragment program does not write
result.color, the color will be undefined in subsequent stages.
Dependencies on ARB_fragment_shader
(modify 1st paragraph of Section 3.11.6 language) ... are
gl_FragColor and gl_FragDepth. If fragment color clamping is
enabled, the final fragment color values written by a fragment
shader are clamped to the range [0,1] and are optionally converted
to fixed-point as described in section 2.14.9, Final Color
Processing. ...
Dependencies on NV_float_buffer
Note that the WGL/GLX enumerants for the NV and ARB extensions
do not have the same values, so it is possible to distinguish
between "NV" and "ARB" pixel formats.
If NV_float_buffer and ARB_color_buffer_float are both supported,
restrictions imposed by NV_float_buffer are removed. In
particular, antialiasing application, multisample fragment
operations, alpha test, and blending are all performed as
specified in this extension. Additionally, it is not necessary to
use a fragment program or shader to render to a floating-point
color buffer allocated using the NV_float_buffer extension.
Note also that vertex color clamp portion of this extension does
not interact with NV_float_buffer.
Dependencies on ATI_pixel_format_float
The basic policy of ATI_pixel_format_float regarding clamping is
that vertex color clamping is unaffected (still enabled) and that
fragment color clamping is automatically disabled when rendering
to floating-point color buffers.
This extension is designed so that the defaults are compatible
with the ATI_pixel_format_float, so there is no need for separate
"ATI" and "ARB" floating-point pixel formats.
Errors
None
New State
(modify table 6.10, p. 271)
Initial
Get Value Type Get Command Value Description Sec. Attribute
------------------------- ---- ----------- ------- --------------- ---- ---------
CLAMP_VERTEX_COLOR_ARB B GetIntegerv TRUE vertex color 2.14.6 lighting/enable
clamping
CLAMP_FRAGMENT_COLOR_ARB B GetIntegerv FIXED_ fragment color 2.14.6 color-buffer/enable
ONLY_ARB clamping
CLAMP_READ_COLOR_ARB B GetIntegerv FIXED_ read color 2.14.6 color-buffer/enable
ONLY_ARB clamping
(modify table 6.33, p. 294)
Minimum
Get Value Type Get Command Value Description Sec. Attribute
------------------------ ---- ----------- ------- ---------------- ---- ----------
RGBA_FLOAT_MODE_ARB B GetBooleanv - True if RGBA 2.7 -
components are
floats
New Implementation Dependent State
None
Revision History
Rev. Date Author Changes
---- -------- --------- --------------------------------------------
1 2/26/04 Kirkland Initial version based on the ATI extension.
2 3/11/04 Kirkland Changed spec to be both a GL and WGL spec.
Updated language for float16 number handling.
Added bit encodings for half values.
Removed the clamped color query.
Updated the language for dithering.
3 7/23/04 Kirkland Added alternative encodings options for
float16 format.
4 9/17/04 Kirkland Merged the color clamp control spec with
this spec.
Updated to reference the OpenGL 2.0 spec.
Added the specification for GLX.
5 10/1/04 Kirkland Updated IP section.
Reviewed by the ARB and closed all
UNRESOLVED issues.
Added an invariant that discusses the
handling of the alpha test.
Implementation Support
List of OpenGL implementations supporting the GLX_ARB_fbconfig_float extension
Original File
Original text file for the GLX_ARB_fbconfig_float extension
Page generated on Sun Nov 20 18:37:10 2005