| 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 <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_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 <target> set to CLAMP_VERTEX_COLOR_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 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 <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_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 <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_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). |
