Name ARB_color_buffer_float Name Strings GL_ARB_color_buffer_float WGL_ARB_pixel_format_float GLX_ARB_fbconfig_float Contributors Pat Brown, NVIDIA James Jones, NVIDIA Jon Leech Rob Mace, ATI V Moya Brian Paul, Tungsten Graphics Contact Dale Kirkland, NVIDIA (dkirkland 'at' nvidia.com) Notice Copyright (c) 2004-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Specification Update Policy Khronos-approved extension specifications are updated in response to issues and bugs prioritized by the Khronos OpenGL Working Group. For extensions which have been promoted to a core Specification, fixes will first appear in the latest version of that core Specification, and will eventually be backported to the extension document. This policy is described in more detail at https://www.khronos.org/registry/OpenGL/docs/update_policy.php Status Complete. Approved by the ARB on October 22, 2004. Version Based on the ATI_pixel_format_float extension, version 5 Enables based on work by Pat Brown from the color_clamp_control proposal Last Modified Date: April 1, 2015 Version: 9 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. New Procedures and Functions void ClampColorARB(enum target, enum clamp); New Tokens Accepted by the parameters of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: RGBA_FLOAT_MODE_ARB 0x8820 Accepted by the parameter of ClampColorARB and the 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 parameter of ClampColorARB. FIXED_ONLY_ARB 0x891D FALSE TRUE Accepted as a value in the and parameter arrays of wglChoosePixelFormatARB, and returned in the parameter array of wglGetPixelFormatAttribivARB, and the parameter array of wglGetPixelFormatAttribfvARB: WGL_TYPE_RGBA_FLOAT_ARB 0x21A0 Accepted as values of the arguments in the glXCreateNewContext and glXCreateContext functions GLX_RGBA_FLOAT_TYPE_ARB 0x20B9 Accepted as a bit set in the GLX_RENDER_TYPE variable GLX_RGBA_FLOAT_BIT_ARB 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 set to CLAMP_VERTEX_COLOR_ARB. If is TRUE, vertex color clamping is enabled; if is FALSE, vertex color clamping is disabled. If 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 of CLAMP_FRAGMENT_COLOR_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 . 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 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_FLOAT_BIT_ARB, and 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_ARB 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_ARB, 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 one of the following bits set: GLX_RGBA_BIT, GLX_RGBA_FLOAT_BIT_ARB, GLX_COLOR_INDEX_BIT Adds to the accepted values of the argument in the glXCreateNewContext and glXCreateContextWithSGIX functions to: Type of rendering context requested. This argument can have the following values: GLX_RGBA_TYPE, GLX_RGBA_FLOAT_TYPE_ARB, GLX_COLOR_INDEX_TYPE GLX Protocol The following rendering commands are sent to the server as part of a glXRender request: ClampColorARB 2 12 rendering command length 2 234 rendering command opcode 4 CARD32 target 4 CARD32 clamp 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. 6 2/6/07 Jon Leech Fix typos in enum naming. 7 2/13/07 Jon Leech Add GLX protocol from James Jones at NVIDIA. 8 2/15/07 Jon Leech Assign GLX rendering opcode. 9 4/1/15 Jon Leech Add missing _ARB suffix to GLX_RGBA_FLOAT_TYPE and GLX_RGBA_FLOAT_BIT (bug 13717).