Name APPLE_float_pixels Name Strings GL_APPLE_float_pixels Contact Geoff Stahl, Apple (gstahl 'at' apple.com) Jeremy Sandmel, Apple (jsandmel 'at' apple.com) Status Shipping Mac OS X v10.2.3 (version 1.0) Version 1.0 Number 368 Dependencies Written based on the wording of the OpenGL 2.0 specification. Depends on (but does not require) ARB_texture_float Depends on (but does not require) ARB_color_buffer_float Depends on (but does not require) ARB_half_float_pixel Interacts with APPLEX_texture_float_16_filter. Interacts with APPLEX_color_buffer_float_16_blend. Overview This extensions adds texture types, texture internal formats and color buffers composed of both 32 bit and 16 floating point numbers. 16 bit floats (half float) are very similar to the IEEE single-precision floating-point standard, except that it has only 5 exponent bits and 10 mantissa bits. All floating point numbers are clamped to the limits of the range representable by their respective format. Specifically, APPLE_float_pixels adds four pieces of functionality to OpenGL. First, it provides an HALF_APPLE texture type allowing clients to pass textures in the half float format. Second, it adds 12 additional sized internal formats to allow OpenGL to process and maintain texture data in the requested format if possible. Next, it provides the COLOR_FLOAT_APPLE pixel format to allow creation of floating point and half float color buffers. Lastly, it provides an additional query to allow clients to verify that they have a floating point color buffer. The HALF_APPLE texture type allows clients to use source textures composed of half float color components. This constant is use in the type parameter in DrawPixels, ReadPixels and texturing commands with a corresponding GL half data type, which corresponds to a 16 bit half float, and has no special interpretation. Clients can use the 12 additional (6 floating point and 6 half float) sized internal texture formats to specify the mapping of R, G, B and A values to texture components, as they would with any other sized internal texture format. Note, as is the standard practice with OpenGL, implementations should map the sized internal texture R, G, B and A values to internal components with memory allocations as close as possible to those specified in the sized internal format. Floating point color buffers are created by specifying the appropriate color floating point pixel format attribute for the windowing system API in use by the client. Both 128 bit and 64 bit floating point color buffers can be supported, the former with full 32 bit floating point components and the latter with 16 bit half float components. Additionally, clients can query to see if they have a floating point color buffer using GetBooleanv with COLOR_FLOAT_APPLE as the get value. The number of bits per color buffer component can be determined in the usual manner. Issues: 1. How is this extension different from the ARB floating point extensions? Conceptually, this extension can be considered the union of the feature sets from the following extensions: ARB_texture_float ARB_color_buffer_float ARB_half_float_pixel with the following EXCEPTIONS: * this extension does not support the the per-component query of TEXTURE_*_TYPE from ARB_texture_float. * this extension only supports the half float pixel type from ARB_half_float_pixel for {Draw|Read}|Pixels and Tex{Sub}Image{1D|2D|3D}, and for color buffers as described by ARB_color_buffer_float. (Note: unlike the ARB_half_float extension, APPLE_float_pixels does not support using 16 bit half float data with the imaging subset routines that accept images, i.e., ConvolutionFilter{1D|2D}, ColorTable, etc. * this extension does not include the ClampColorARB routine from ARB_color_buffer_float. It does, however, use the default clamping behavior specified in the ARB_color_buffer_float extension. Note that this means the following in this extension: - vertex color outputs are always clamped, regardless of color buffer format - fragment color outputs are clamped when writing to a fixed point color buffer and unclamped when writing to a floating point color buffer, and - the read color returned by ReadPixels/CopyPixels/GetTexImage/etc. is clamped when reading from a fixed point format and unclamped when reading from a floating point format. * unlike ARB_texture_float, this extension only supports GL_NEAREST filtering for float (and half float) textures. * unlike ARB_color_buffer_float, this extension does not support src/dst alpha blending on float (and half float) destination color buffers. 2. Since this extension is more limited than the ARB floating point extensions, what is the appropriate (and "future-proof") method for an application to use to query for floating point color buffer and texture support? This extension and the related extensions APPLEX_color_buffer_float_16_blend and APPLEX_texture_float_16_filter, should be considered "transitional" in nature. The limited functionality described by these extensions is superseded by the more powerful ARB extensions and as hardware becomes more capable, it is possible that future revisions of OpenGL may deprecate or remove them altogether. As such, to allow for ease of transition to support of the ARB floating point extensions, applications are *strongly* encouraged to use the following algorithm to query for floating point texture and color buffer support: // any Floating Point Support at all? bool supportsFloatColorBuffers = FALSE; bool supportsFloatTextures = FALSE; // 16 bit/component Floating Point Blend/Filter Support? bool supportsFloat16ColorBufferBlending = FALSE; bool supportsFloat16TextureFiltering = FALSE; // 32 bit/component Floating Point Blend/Filter Support? bool supportsFloat32ColorBufferBlending = FALSE; bool supportsFloat32TextureFiltering = FALSE; // =============================================== // Check for floating point texture support // // * First check for full ARB_texture_float // extension and only then check for more // limited APPLE and APPLEX texture extensions // =============================================== if (extensionSupported("ARB_texture_float")) { supportsFloatTextures = TRUE; supportsFloat16TextureFiltering = TRUE; supportsFloat32TextureFiltering = TRUE; } else if (extensionSupported("APPLE_float_pixels")) { supportsFloatTextures = TRUE; if (extensionSupported("APPLEX_texture_float_16_filter")) { supportsFloat16TextureFiltering = TRUE; } } // =============================================== // Check for floating point color buffer support // // * First check for full ARB_color_buffer_float // extension and only then check for more // limited APPLE and APPLEX color buffer extensions // =============================================== if (extensionSupported("ARB_color_buffer_float")) { supportsFloatColorBuffers = TRUE; supportsFloat16ColorBufferBlending = TRUE; supportsFloat32ColorBufferBlending = TRUE; } else if (extensionSupported("APPLE_float_pixels")) { supportsFloatColorBuffers = TRUE; if (extensionSupported("APPLEX_color_buffer_float_16_blend")) { supportsFloat16ColorBufferBlending = TRUE; } } 3. Why does this extension (and the related APPLEX_*_float_* extensions) even exist, given the existence of the ARB, ATI, and NVIDIA floating point extensions? A good question. This extension was developed contemporaneously with the ATI and NVIDIA extensions and support for this extension in Mac OS X's OpenGL implementation predates the definition of the ARB extensions. In addition, this extension specification attempts to document the behavior of the APPLE extension to support use of floating point features on hardware which may not support the full feature set described by the ARB extensions. The behavior of the APPLE extension more closely matches the feature set of this class of hardware and can be used by applications to get a more accurate description of native hardware support when falling back to software rendering may not be appropriate. It is expected that as hardware renderers becomes more capable the Mac OS X OpenGL implementation will transition to supporting the ARB extensions and may deprecate and/or remove these APPLE extensions from the API. Please see issue #2 for details on how to query for floating point support in a "future-proof" manner. 4. What will happen when the ARB floating point extensions are supported? The APPLE_float_pixels and the related APPLEX_texture_float_16_filter and APPLEX_color_buffer_float_16_blend extensions are intended as a strict subset of the functionality in ARB_texture_float, ARB_color_buffer_float, and ARB_half_float_pixel. Consequently, an implementation could legally support all of these extensions simulataneously, however once the ARB extensions are supported there is no need to export the APPLE{X}_* floating point extensions. Consequently, it's possible that implementations may deprecate or remove the APPLE_float_pixels, APPLEX_texture_float_16_filter, and APPLEX_color_buffer_float_16_blend extensions when the corresponding ARB extensions are supported by the underlying hardware. Applications should pay attention to issue #2 above to prepare for this possibility. New Procedures and Functions None New Tokens Accepted by the parameters of DrawPixels, ReadPixels, TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D, and GetTexImage: HALF_APPLE 0x140B // Same as HALF_FLOAT_NV/ARB Accepted by the GetBooleanv: COLOR_FLOAT_APPLE 0x8A0F Accepted by the parameter of TexImage1D, TexImage2D, and TexImage3D: RGBA_FLOAT32_APPLE 0x8814 // Same as RGBA_FLOAT32_ATI/ARB RGB_FLOAT32_APPLE 0x8815 // Same as RGB_FLOAT32_ATI/ARB ALPHA_FLOAT32_APPLE 0x8816 // Same as ALPHA_FLOAT32_ATI/ARB INTENSITY_FLOAT32_APPLE 0x8817 // Same as INTENSITY_FLOAT32_ATI/ARB LUMINANCE_FLOAT32_APPLE 0x8818 // Same as LUMINANCE_FLOAT32_ATI/ARB LUMINANCE_ALPHA_FLOAT32_APPLE 0x8819 // Same as LUMINANCE_ALPHA_FLOAT32_ATI/ARB RGBA_FLOAT16_APPLE 0x881A // Same as RGBA_FLOAT16_ATI/ARB RGB_FLOAT16_APPLE 0x881B // Same as RGB_FLOAT16_ATI/ARB ALPHA_FLOAT16_APPLE 0x881C // Same as ALPHA_FLOAT16_ATI/ARB INTENSITY_FLOAT16_APPLE 0x881D // Same as NTENSITY_FLOAT16_ATI/ARB LUMINANCE_FLOAT16_APPLE 0x881E // Same as LUMINANCE_FLOAT16_ATI/ARB LUMINANCE_ALPHA_FLOAT16_APPLE 0x881F // Same as LUMINANCE_ALPHA_FLOAT16_ATI/ARB 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 Table 2.2, p. 9) -- add new row Minimum GL Type Bit Width Description ------- --------- ----------------------------------- half 16 half-precision floating-point value encoded in an unsigned scalar Modify Section 2.14, (Colors and Coloring), p. 59 (modify Table 2.9, p. 59) Add new row to the table: GL Type Conversion ------- ---------- half c 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. For the purposes of this specification, fragment color clamping is enabled implicitly if all enabled color buffers have fixed-point components. Modify Section 3.8.1 (Texture Image Specification), p. 150 (modify second paragraph, p. 151) The selected groups are processed exactly as for DrawPixels, stopping just before final conversion. For R, G, B, and A, if the of the texture is fixed-point, the components are clamped to [0, 1]. Otherwise, the components are not modified. The depth value so generated is clamped to [0, 1]. (modify the second paragraph, p. 152) The internal component resolution is the number of bits allocated to each value in a texture image. If is specified as a base internal format, the GL stores the resulting texture with internal component resolutions of its own choosing. If a sized internal format is specified, the mapping of the R, G, B, A, and depth values to texture components is equivalent to the mapping of the corresponding base internal format's components, as specified in table 3.15, the type (unsigned int, float, etc.) is assigned the same type specified by , and the memory allocation per texture component is assigned by the GL to match the allocations listed in table 3.16 as closely as possible. (The definition of closely is left up to the implementation. Implementations are not required to support more than one resolution of each type (unsigned int, float, etc.) for each base internal format.) If a compressed internal format is specified, the mapping of the R, G, B, A, and depth values to texture components is equivalent to the mapping of the corresponding base internal format's components, as specified in table 3.15. The specified image is compressed using a (possibly lossy) compression algorithm chosen by the GL. (add the following to table 3.16, p. 154) Sized Base R G B A L I Internal Format Internal Format bits bits bits bits bits bits --------------------------- --------------- ---- ---- ---- ---- ---- ---- RGBA32F_ARB RGBA f32 f32 f32 f32 RGB32F_ARB RGB f32 f32 f32 ALPHA32F_ARB ALPHA f32 INTENSITY32F_ARB INTENSITY f32 LUMINANCE32F_ARB LUMINANCE f32 LUMINANCE_ALPHA32F_ARB LUMINANCE_ALPHA f32 f32 RGBA16F_ARB RGBA f16 f16 f16 f16 RGB16F_ARB RGB f16 f16 f16 ALPHA16F_ARB ALPHA f16 INTENSITY16F_ARB INTENSITY f16 LUMINANCE16F_ARB LUMINANCE f16 LUMINANCE_ALPHA16F_ARB LUMINANCE_ALPHA f16 f16 Table 3.16: Correspondence of sized internal formats to base internal formats, and desired component resolutions for each sized internal format. The notation and imply 16- and 32-bit floating-point, respectively. Modify Section 3.8.4 (Texture Parameters), p. 166 (remove TEXTURE_BORDER_COLOR from end of first paragraph, p. 166) ... If the value for TEXTURE_PRIORITY is specified as an integer, the conversion for signed integers from table 2.9 is applied to convert this value to floating-point, followed by clamping the value to lie in [0, 1]. (modify last paragraph, p. 174) ... If the texture contains color components, the values of TEXTURE BORDER COLOR are interpreted as an RGBA color to match the texture's internal format in a manner consistent with table 3.15. The border values for texture components stored as fixed-point values are clamped to [0, 1] before they are used. If the texture contains depth ... Add a new section, after 3.8.9 and prior to section 3.8.10, p. 177 3.8.9.5 Floating point formats and texture filters Due to limitations in current render hardware, textures with floating point formats may not support minification or magnification filters that require LINEAR filtering in the manner described above. Specifically, if the texture filter is neither GL_NEAREST nor GL_NEAREST_MIPMAP_NEAREST, and *any* of following conditions are true: * the of the texture is a 32-bit/component floating point format and ARB_texture_float is not supported by the implementation, *or* * the of the texture is a 16-bit/component floating point format and APPLEX_texture_float_16_filter extension is not supported by the implementation, then the GL will interpret texture minification and magnification filters according to the table (xxx.1) listed below: specified filter will behave as: ---------------- -------------- LINEAR NEAREST NEAREST_MIPMAP_LINEAR NEAREST_MIPMAP_NEAREST LINEAR_MIPMAP_NEAREST NEAREST_MIPMAP_NEAREST LINEAR_MIPMAP_LINEAR NEAREST_MIPMAP_NEAREST ---------------------------------------------------- Table xxx.1 - floating point texture filter behavior Otherwise, the texture minification and magnfication filters behave as specified earlier in section 3.8.8 and 3.8.9. 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 Frame Buffer) 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. Blending is dependent on the incoming fragment's alpha value and that of the corresponding currently stored pixel. Blending applies only in RGBA mode and only one of the following conditions is true: * the format of the current color buffer is fixed-point, *or* * the format of current color buffer(s) is 16 bit floating point and the APPLEX_color_buffer_float_16_blend extension is supported by the implementation, *or* * the format of the current color buffer is floating-point and the ARB_color_buffer_float extension is supported by the implementation. Otherwise, the blending stage is bypassed. Blending is enabled or disabled using Enable or Disable with the symbolic constant BLEND. If it is disabled (or bypassed), or if logical operation on color values is enabled (section 4.1.10), proceed 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 Final Conversion, p. 222) For an index, if the type is not FLOAT or HALF_FLOAT_ARB, final conversion consists of masking the index with the value given in Table 4.6; if the type is FLOAT or HALF_FLOAT_ARB, then the integer index is converted to a GL float or half data value. For an RGBA color, if is not FLOAT or HALF, or the selected color buffer is a fixed-point buffer, each component is first clamped to [0,1]. Then the appropriate conversion... (modify Table 4.7, p. 224 -- add new row) type Parameter GL Data Type Component Conversion Formula -------------- ------------ ---------------------------- HALF_APPLE half c = f 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. Modifications to the AGL Specification Modify the values accepted by aglChoosePixelFormat and aglDescribePixelFormat. AGL_COLOR_FLOAT If true, this pixel format supports using floating point color buffers as the destination for rendering. Modifications to the CGL Specification Modify the values accepted by CGLChoosePixelFormat and CGLDescribePixelFormat. kCGLPFAColorFloat If true, this pixel format supports using floating point color buffers as the destination for rendering. 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 APPLEX_texture_float_16_filter If APPLEX_texture_float_16_filter is not supported, then all references to APPLEX_texture_float_16_filter should be removed from this extension. In this case, 16 bit floating point textures will behave as if the GL_MAG_FILTER is GL_NEAREST and as if GL_MIN_FILTER is either GL_NEAREST_MIPMAP_NEAREST (if a mipmap min filter is requested) or GL_NEAREST (if a non-mipmap min filter is requested). Dependencies on APPLEX_color_buffer_float_16_blend If APPLEX_color_buffer_float_16_blend is not supported, then all references to APPLEX_texture_float_16_filter should be removed from this extension. In this case, rendering to a 16 bit floating point color buffer will behave as if the enable state for GL_BLEND is set to FALSE. Errors None. New State (table 6.25, p. 215) Get value Type Get Cmnd Minimum Value Description Sec. Attribute ----------------- ---- ----------- ------------- --------------------------- ---- --------- COLOR_FLOAT_APPLE B GetBooleanv - True if color buffers store 2.7 - floating point components Revision History 0.1, 2003, gstahl@apple.com * preliminary draft, documents shipping behavior as of 10.2.3 0.2, 08/16/2005, jsandmel@apple.com * rewritten to account for the fact that APPLE_float_pixels doesn't support: - float 16/32 texture filtering - float 16/32 color buffer blending - controllable color clamping - texture per-component float-versus-int type queries - half float types with imaging subset routines * added interactions with the shader extensions * added interactions with the APPLEX_*_float_16_* extensions * added updates to AGL and CGL