back  Return to list

GL_ARB_color_buffer_float
homeprevnext Name
  
    ARB_color_buffer_float  
  
homeprevnext Name Strings
  
    GL_ARB_color_buffer_float  
    WGL_ARB_pixel_format_float  
    GLX_ARB_fbconfig_float  
  
homeprevnext Contributors
  
    Pat Brown  
    Jon Leech  
    Rob Mace  
    V Moya  
    Brian Paul  
  
homeprevnext Contact
  
    Dale Kirkland, NVIDIA (dkirkland 'at' nvidia.com)  
  
homeprevnext Status
  
    Complete. Appprove by the ARB on October 22, 2004.  
  
homeprevnext 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:  February 7, 2006  
    Version              6  
  
homeprevnext Number
  
    ARB Extension #39  
  
homeprevnext 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.  
  
homeprevnext 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.  
  
  
homeprevnext 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.  
  
homeprevnext 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.  
  
homeprevnext New Procedures and Functions
  
    void ClampColorARB(enum target, enum clamp);  
  
homeprevnext 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                     0x20B9  
  
    Accepted as a bit set in the GLX_RENDER_TYPE variable  
  
        GLX_RGBA_FLOAT_BIT                      0x00000004  
  
homeprevnext 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.  
  
  
homeprevnext 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...  
  
homeprevnext 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...  
  
  
homeprevnext Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
  
    None  
  
homeprevnext 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.  
  
homeprevnext Additions to Chapter 1 of the GLX 1.3 Specification (Overview)
  
    None  
  
homeprevnext Additions to Chapter 2 of the GLX 1.3 Specification (GLX Operation)
  
    None  
  
homeprevnext 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.  
  
homeprevnext Additions to Chapter 4 of the GLX 1.3 Specification (Encoding on the X Byte Stream)
  
    None  
  
homeprevnext Additions to Chapter 5 of the GLX 1.3 Specification (Extending OpenGL)
  
    None  
  
homeprevnext Additions to Chapter 6 of the GLX 1.3 Specification (GLX Versions)
  
    None  
  
homeprevnext Additions to Chapter 7 of the GLX 1.3 Specification (Glossary)
  
    None  
  
homeprevnext 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  
  
homeprevnext 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  
  
  
homeprevnext 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.  
  
homeprevnext Dependencies on WGL_ARB_pixel_format
  
    The WGL_ARB_pixel_format extension must be used to determine a  
    pixel format with float components.  
  
homeprevnext 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.  
  
homeprevnext 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.  ...  
  
homeprevnext 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.  
  
homeprevnext 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.  
  
  
homeprevnext Errors
  
    None  
  
homeprevnext 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  
  
homeprevnext New Implementation Dependent State
  
    None  
  
homeprevnext 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.  
      6   2/6/07   Jon Leech  Fix typos in enum naming.  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.