| Name |
| |
| NV_float_buffer |
| |
| Name Strings |
| |
| GL_NV_float_buffer |
| WGL_NV_float_buffer |
| GLX_NV_float_buffer |
| |
| Contact |
| |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright NVIDIA Corporation. |
| |
| IP Status |
| |
| NVIDIA Proprietary. |
| |
| Status |
| |
| Implemented in CineFX (NV30) Emulation driver, August 2002. |
| Shipping in Release 40 NVIDIA driver for CineFX hardware, January 2003. |
| |
| Superseded by the more general ARB_texture_float and |
| ARB_color_buffer_float extensions. However, NV3x-based GPUs are not |
| capable enough to support the generality of the ARB extensions so |
| the NV_float_buffer extension remains available for NV3x development |
| and backward compatibility. |
| |
| Version |
| |
| Last Modified: 2006/11/03 |
| NVIDIA Revision: 20 |
| |
| Number |
| |
| 281 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 1.3 specification and the |
| WGL_ARB_pixel_format extension specification. |
| |
| The following extensions are required: |
| * NV_fragment_program |
| * NV_texture_rectangle |
| * WGL_ARB_pixel_format |
| * WGL_ARB_render_texture |
| * WGL_NV_render_texture_rectangle |
| |
| EXT_paletted_texture trivially affects the definition of this extension. |
| |
| SGIX_depth_texture trivially affects the definition of this extension. |
| |
| NV_texture_shader trivially affects the definition of this extension. |
| |
| NV_half_float trivially affects the definition of this extension. |
| |
| ARB_color_buffer_float and ATI_pixel_format_float affect the definition of |
| this extension. |
| |
| ARB_texture_float and ATI_texture_float affect the definition of this |
| extension. |
| |
| This extension modifies EXT_framebuffer_object. |
| |
| Overview |
| |
| This extension builds upon NV_fragment_program to provide a framebuffer |
| and texture format that allows fragment programs to read and write |
| unconstrained floating point data. |
| |
| In unextended OpenGL, most computations dealing with color or depth |
| buffers are typically constrained to operate on values in the range [0,1]. |
| Computational results are also typically clamped to the range [0,1]. |
| Color, texture, and depth buffers themselves also hold values mapped to |
| the range [0,1]. |
| |
| The NV_fragment_program extension provides a general computational model |
| that supports floating-point numbers constrained only by the precision of |
| the underlying data types. The quantites computed by fragment programs do |
| not necessarily correspond in number or in range to conventional |
| attributes such as RGBA colors or depth values. Because of the range and |
| precision constraints imposed by conventional fixed-point color buffers, |
| it may be difficult (if not impossible) to use them to implement certain |
| multi-pass algorithms. |
| |
| To enhance the extended range and precision available through fragment |
| programs, this extension provides floating-point RGBA color buffers that |
| can be used instead of conventional fixed-point RGBA color buffers. A |
| floating-point RGBA color buffer consists of one to four floating-point |
| components stored in the 16- or 32-bit floating-point formats (fp16 or |
| fp32) defined in the NV_half_float and NV_fragment_program extensions. |
| |
| When a floating-point color buffer is used, the results of fragment |
| programs, as written to the "x", "y", "z", and "w" components of the |
| o[COLR] or o[COLH] output registers, are written directly to the color |
| buffer without any clamping or modification. Certain per-fragment |
| operations are bypassed when rendering to floating-point color buffers. |
| |
| A floating-point color buffer can also be used as a texture map, either by |
| reading back the contents and then using conventional TexImage calls, or |
| by using the buffer directly via the ARB_render_texture extension or |
| the EXT_framebuffer_object extension. |
| |
| This extension has many uses. Some possible uses include: |
| |
| (1) Multi-pass algorithms with arbitrary intermediate results that |
| don't have to be artifically forced into the range [0,1]. In |
| addition, intermediate results can be written without having to |
| worry about out-of-range values. |
| |
| (2) Deferred shading algorithms where an expensive fragment program is |
| executed only after depth testing is fully complete. Instead, a |
| simple program is executed, which stores the parameters necessary |
| to produce a final result. After the entire scene is rendered, a |
| second pass is executed over the entire frame buffer to execute |
| the complex fragment program using the results written to the |
| floating-point color buffer in the first pass. This will save the |
| cost of applying complex fragment programs to fragments that will |
| not appear in the final image. |
| |
| (3) Use floating-point texture maps to evaluate functions with |
| arbitrary ranges. Arbitrary functions with a finite domain can be |
| approximated using a texture map holding sample results and |
| piecewise linear approximation. |
| |
| There are several significant limitations on the use of floating-point |
| color buffers. First, floating-point color buffers do not support frame |
| buffer blending. Second, floating-point texture maps do not support |
| mipmapping or any texture filtering other than NEAREST. Third, |
| floating-point texture maps must be 2D, and must use the |
| NV_texture_rectangle extension. |
| |
| Issues |
| |
| Should the extension create a separate non-RGBA pixel formats or simply |
| extend existing RGBA formats? |
| |
| RESOLVED: Extend existing RGBA formats. Since fragment programs |
| generally build on RGBA semantics, it's cleaner to avoid creating a |
| separate "XYZW" mode. There are several special semantics that need |
| to be added: clear color state is now not clamped, and ReadPixels |
| will clamp to [0,1] only if the source data comes from fixed-point |
| color buffers. |
| |
| Fragment programs can be written that store data completely unrelated |
| to color into a floating-point "RGBA" buffer. |
| |
| Can floating-point color buffers be displayed? If so, how? |
| |
| RESOLVED: Not in this extension. Floating-point color buffers can be |
| used only as pbuffers. Hardware necessary to display floating-point |
| color buffers would be expensive and consume significant memory |
| bandwidth. |
| |
| Is it possible to encode more than four distinct values in a |
| floating-point color buffer? |
| |
| RESOLVED: Yes. The NV_fragment_program extension contains pack and |
| unpack instructions (PK2H, PK2US, PK4B, PK4UB, PK4UBG, UP2H, UP2US, |
| UP4B, UP4UB, UP4UBG) that allow fragment programs to encode multiple |
| values into a single 32-bit component. In particular, it is possible |
| to pack two half-precision floats, two normalized unsigned shorts, or |
| four normalized signed or unsigned bytes into a single 32-bit |
| component. |
| |
| A program can use a pack instruction to pack multiple values into a |
| single 32-bit component and then write the resulting component to a |
| floating-point color buffer with 32-bit components. On a subsequent |
| rendering pass, a program can read back the stored data (using texture |
| mapping) and use the equivalent unpack instruction to restore the |
| original values. The only data lost in this process comes from the |
| loss of precision or clamping in the packing operation, where the |
| original values are converted to data types with lower precision or a |
| smaller data range. |
| |
| What happens when rendering to an floating-point color buffer if fragment |
| program mode is disabled? Or when fragment program mode is enabled, but |
| no program is loaded? |
| |
| RESOLVED: Fragment programs are required to use floating-point color |
| buffers. An INVALID_OPERATION error is generated by any GL command |
| that generates fragments if FRAGMENT_PROGRAM_NV is disabled. The same |
| behavior already exists for conventional frame buffers if |
| FRAGMENT_PROGRAM_NV is enabled but the bound fragment program is |
| invalid. |
| |
| Should alpha test be supported with floating-point color buffers? |
| |
| RESOLVED: No. It is trivial to implement an alpha test in a fragment |
| program using the KIL instruction, which requires no dedicated frame |
| buffer logic. |
| |
| Should blending be supported with floating-point color buffers? |
| |
| RESOLVED: Not in this extension. While blending would clearly be |
| useful, full-precision floating-point blenders are expensive. In |
| addition, a computational model more general than traditional blending |
| (with its 1-x operations and clamping) is desirable. The traditional |
| OpenGL blending model would not be the most suitable computational |
| model for future blend-enabled floating-point color buffers. |
| |
| An alternative to conventional blending (operating at a coarser |
| granularity) is to (1) render a pass into the color buffer, (2) bind |
| the color buffer as a texture rectangle using this extension and |
| ARB_render_texture, (3) perform texture lookups in a fragment program |
| using the TEX instruction with f[WPOS].xy as a 2D texture coordinate, |
| and (4) perform the necessary blending between the passes using the |
| same fragment program. |
| |
| Should we provide accumulation buffers for pixel formats with |
| floating-point color buffers? |
| |
| RESOLVED: No. Accumulation operations contents can be achieved using |
| fragment programs to perform the accumulation, which requires no |
| dedicated frame buffer logic. |
| |
| Should fragment program color results be converted to match the format of |
| the frame buffer, or should an error result? For example, what if we |
| write to o[COLR] but have a 16-bit frame buffer? |
| |
| RESOLVED: Conversions can be performed simply in hardware, so no |
| error semantics are required. This mechanism also allows the same |
| programs to be shared between contexts with different pixel formats. |
| |
| Applications should be aware that if color components contain packed |
| data, a data type mismatch may result in a floating-point data |
| conversion that corrupts the packed data. |
| |
| How should floating-point color buffers interact with multisampling? For |
| normal color buffers, the multiple samples for each pixel are required to |
| be filtered down to a single pixel in the color buffer. Similar filtering |
| on floating-point color buffers does not necessarily make sense. Should |
| there even be a normal color buffer in this case? |
| |
| RESOLVED: The initial implementation of this extension does not |
| provide floating-point color buffers that support multisampling. |
| |
| Multisample fragment operations (e.g., SAMPLE_COVERAGE) are explicitly |
| not supported by extension. This extension does not modify the |
| portion of the spec where multiple samples are resolved to a single |
| color value. So if floating-point color buffers were provided, the |
| multiple samples are filtered down to a single result value, most |
| likely by computing a per-component average value. |
| |
| Conventional RGBA primitive antialiasing multiplies coverage by the alpha |
| component of the fragment's color, with the assumption that alpha blending |
| will be performed. How does antialiasing work with floating-point color |
| buffers? |
| |
| RESOLVED: It doesn't. The computed coverage is not accessible to |
| fragment programs and is discarded. Note also that conventional |
| antialiasing requires alpha blending, which does not work for |
| floating-point color buffers. |
| |
| What are the semantics for ReadPixels when using an floating-point color |
| buffer? |
| |
| RESOLVED: ReadPixels from a floating-point color buffer works like |
| any other RGBA read, except that the final results are not clamped to |
| the range [0,1]. This ensures that we can save and restore |
| floating-point color buffers using ReadPixels/DrawPixels. |
| |
| What are the semantics for Bitmap when using an floating-point color |
| buffer? |
| |
| RESOLVED: Bitmap generates fragments using the current raster |
| attributes, which are then passed to fragment programs like any other |
| fragments. Bitmaps will be drawn using the color of the current |
| raster position, whose components are clamped to [0,1] when the raster |
| position is sent. |
| |
| What are the semantics for DrawPixels when using a floating-point color |
| buffer? How about CopyPixels? |
| |
| RESOLVED: DrawPixels generates fragments with the originally |
| specified color values; components are not clamped to [0,1]. For |
| fixed-point color buffers, DrawPixels will generate fragments with |
| clamped color components. |
| |
| CopyPixels is defined in the spec as a ReadPixels followed by a |
| DrawPixels, and will operate similarly. |
| |
| This mechanism allows applications to write floating-point data |
| directly into a floating-point color buffer without any clamping. |
| Since DrawPixels and CopyPixels generate fragments and fragment |
| programs are required to render to floating-point color buffers, a |
| fragment program is still required to load a floating-point color |
| buffer using DrawPixels. |
| |
| What are the semantics for Clear when using an floating-point color |
| buffer? |
| |
| RESOLVED: Clears work as normal, except that values outside the range |
| [0,1] can be written to the color buffer. The core spec is modified |
| so that clear color values are not clamped to [0,1]. Instead, for |
| fixed-point color buffers, clear colors are clamped to [0,1] at clear |
| time. |
| |
| For compatibility with conventional OpenGL, queries of |
| CLEAR_COLOR_VALUE will clamp components to [0,1]. A separate |
| FLOAT_CLEAR_COLOR_VALUE_NV query is added to query unclamped color |
| clear values. |
| |
| Why don't floating-point textures support filtering? What can be done to |
| achieve texture filtering? |
| |
| RESOLVED: Extended OpenGL texture filtering (including mipmapping and |
| support for anisotropic filters) is very computationally expensive. |
| Even simple linear filtering for floating-point textures with large |
| components is expensive. |
| |
| Linear filters can be implemented in fragment programs by doing |
| multiple lookups into the same texture. Since fragment programs allow |
| the use of arbitrary coordinates into arbitrary texture maps, this |
| type of operation can be easily done. |
| |
| A 1D linear filter can be implemented using an nx1 texture rectangle |
| with the following (untested) fragment program, assuming the 1D |
| coordinate is in f[TEX0].x: |
| |
| ADDR H2.xy, f[TEX0].x, {0.0, 1.0}; |
| FRCH H3.x, R1.x; # compute the blend factor |
| TEX H0, H2.x, TEX0, RECT; # lookup 1st sample |
| TEX H1, H2.y, TEX0, RECT; # lookup 2nd sample |
| LRPH H0, H3.x, H1, H0; # blend |
| |
| A 2D linear filter can be implemented similarly, assuming the 2D |
| coordinate is in f[TEX0].xy: |
| |
| ADDH H2, f[TEX0].xyxy, {0.0, 0.0, 1.0, 1.0}; |
| FRCH H3.xy, H2.xyxy; # base weights |
| ADDH H3.zw, 1.0, -H3.xyxy; # 1-base weights |
| MULH H3, H3.xzxz, H3.yyww; # bilinear filter weights |
| TEX H1, R2.xyxy, TEX0, RECT; # lookup 1st sample |
| MULH H0, H1, H3.x; # blend |
| TEX H1, R2.zyzy, TEX0, RECT; # lookup 2nd sample |
| MADH H0, H1, H3.y, H0; # blend |
| TEX H0, R2.xwxw, TEX0, RECT; # lookup 3rd sample |
| MADH H0, H1, H3.z, H0; # blend |
| TEX H1, R2.zwzw, TEX0, RECT; # lookup 4th sample |
| MADH H0, H1, H3.w, H0; # blend |
| |
| Fragment programs can be used to perform more-or-less arbitrary |
| filtering using similar methods, and the DDX and DDY instructions can |
| be used to refine the shape of the filter. |
| |
| Why must the NV_texture_rectangle extension be used in order to use |
| floating-point texture maps? |
| |
| RESOLVED: On many graphics hardware platforms, texture maps are |
| stored using a special memory encodings designed to optimize rendering |
| performance. In current hardware, conventional texture maps usually |
| top out at 32 bits per texel. The logic required to encode and decode |
| 128-bit texels (and frame buffer pixels) optimally is substantially |
| more complex. |
| |
| What happens if you try to use an floating-point texture without a |
| fragment program? |
| |
| RESOLVED: No error is generated, but that texture is effectively |
| disabled. This is similar to the behavior if an application tried to |
| use a normal texture having an inconsistent set of mipmaps. |
| |
| How does NV_float_buffer interact with the OpenGL 1.2 imaging subset? |
| |
| RESOLVED: The imaging subset as specified should work properly with |
| floating-point color buffers, but is not modified by this extension. |
| There are imaging operations (e.g., color tables, histograms) that |
| expect the components they operate on to be in the range [0,1], and |
| this extension makes no attempt to extend such functionality. |
| |
| How does NV_float_buffer interact with SGIS_generate_mipmap? |
| |
| RESOLVED: Since this extension supports only texture rectangles |
| (which have no mipmaps), this issue is moot. |
| |
| In the general case, mipmaps should be generated using an appropriate |
| downsample filter, where floating-point component values are averaged. |
| Components should not be clamped during any such mipmap generation. |
| |
| What is the deal with the names of the clear color query tokens? |
| |
| RESOLVED: The "normal" OpenGL clear color (clamped to [0,1]) is |
| queried using the token COLOR_CLEAR_VALUE. This extension provides a |
| new query for unclamped values, using the token |
| FLOAT_CLEAR_COLOR_VALUE_NV. Notice that "CLEAR" and "COLOR" are |
| reversed due to a mistake made when the spec was first written. This |
| spec lists the core query token, and originally had "CLEAR" and |
| "COLOR" reversed there, too. |
| |
| Then again, the core specification is inconsistent since the queried |
| state is set by calling glClearColor(), with "Clear" before "Color". |
| |
| What performance issues exist with this functionality? |
| |
| See the "NV3x Implementation Issues" section of the |
| specification. |
| |
| How should the texture border color (values) be handled for float |
| textures? |
| |
| RESOLVED: Clamp the texture border color (values) to [0,1] |
| when sampling a float texture's border. In core OpenGL 1.0, the |
| texture border color components are clamped to the range [01,]. |
| The NV_texture_shader extension added support for signed texture |
| components. We decided to provide GL_TEXTURE_BORDER_VALUES as |
| a way of specifying a version of the texture border color whose |
| components were not clamped to [0,1] when set. This was to |
| provide a way of specifying negative texture border components. |
| |
| In practice, that has not proven particularly useful. No real |
| applications are known to have specified negative texture border |
| values components. |
| |
| Ideally, the unclamped GL_TEXTURE_BORDER_VALUES state could |
| provide an unclamped (unmassaged) set of floating-point color |
| components for the texture border color. This requires an |
| additional 96 bits of state per texture unit to support this, |
| and based on the experience with NV_texture_shader's support for |
| texture border values outside the [0,1] range, it is simply not |
| worth it. |
| |
| For compatibility with the NV_texture_shader extension, we |
| provide language saying that floating-point textures clamp |
| the components of the TEXTURE_BORDER_VALUES vector [0,1] when |
| sampling the border color. |
| |
| |
| New Procedures and Functions |
| |
| None. |
| |
| New Tokens |
| |
| Accepted by the <internalformat> parameter of TexImage2D and |
| CopyTexImage2D: |
| |
| FLOAT_R_NV 0x8880 |
| FLOAT_RG_NV 0x8881 |
| FLOAT_RGB_NV 0x8882 |
| FLOAT_RGBA_NV 0x8883 |
| FLOAT_R16_NV 0x8884 |
| FLOAT_R32_NV 0x8885 |
| FLOAT_RG16_NV 0x8886 |
| FLOAT_RG32_NV 0x8887 |
| FLOAT_RGB16_NV 0x8888 |
| FLOAT_RGB32_NV 0x8889 |
| FLOAT_RGBA16_NV 0x888A |
| FLOAT_RGBA32_NV 0x888B |
| |
| Accepted by the <pname> parameter of GetTexLevelParameterfv and |
| GetTexLevelParameteriv: |
| |
| TEXTURE_FLOAT_COMPONENTS_NV 0x888C |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, |
| and GetDoublev: |
| |
| FLOAT_CLEAR_COLOR_VALUE_NV 0x888D |
| FLOAT_RGBA_MODE_NV 0x888E |
| |
| Accepted in the <piAttributes> array of wglGetPixelFormatAttribivARB and |
| wglGetPixelFormatAttribfvARB and in the <piAttribIList> and |
| <pfAttribFList> arrays of wglChoosePixelFormatARB: |
| |
| WGL_FLOAT_COMPONENTS_NV 0x20B0 |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV 0x20B1 |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV 0x20B2 |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV 0x20B3 |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV 0x20B4 |
| |
| Accepted in the <piAttribIList> array of wglCreatePbufferARB and returned |
| in the <value> parameter of wglQueryPbufferARB when <iAttribute> is |
| WGL_TEXTURE_FORMAT_ARB: |
| |
| WGL_TEXTURE_FLOAT_R_NV 0x20B5 |
| WGL_TEXTURE_FLOAT_RG_NV 0x20B6 |
| WGL_TEXTURE_FLOAT_RGB_NV 0x20B7 |
| WGL_TEXTURE_FLOAT_RGBA_NV 0x20B8 |
| |
| Accepted in the <value> array of glXGetFBConfigAttrib (and |
| glXGetFBConfigAttribSGIX): |
| |
| GLX_FLOAT_COMPONENTS_NV 0x20B0 |
| |
| Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) |
| |
| None. |
| |
| Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) |
| |
| Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 91) |
| |
| (modify first paragraph of "Final Conversion", p. 102) ... For RGBA |
| components, the final conversion depends on the format of the color |
| buffer. If the components of the color buffer are fixed-point, each |
| element is clamped to [0,1] and converted to fixed-point according to the |
| rules given in section 2.13.9 (Final Color Processing). If the components |
| of the color buffer are floating-point, the elements are not modified. |
| |
| |
| Modify Section 3.8.1, Texture Image Specification (p. 116) |
| |
| (modify last paragaph, p. 116) The selected groups are processed exactly |
| as for DrawPixels stopping just before final conversion. For textures |
| with fixed-point RGBA internal formats, each R, G, B, A component is |
| clamped to [0,1]. |
| |
| (modify first paragraph, p. 117) Components are then selected from the |
| resulting pixel groups to obtain a texture with the base internal format |
| specified by (or derived from) <internalformat>. Table 3.15 summarizes |
| the mapping of pixel group values to texture components, ... |
| |
| (add to end of first paragraph, p. 117) Specifying a value of <format> |
| incompatible with <internalformat> produces the error INVALID_OPERATION. |
| A pixel format and texture internal format are compatible if the pixel |
| format can generate a pixel group of the type listed in the "Pixel Group |
| Type" column of Table 3.15 in the row corresponding to the base internal |
| format. |
| |
| (add between first and second paragraphs, p.117) Textures with a base |
| internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, and |
| FLOAT_RGBA_NV are known as floating-point textures. Floating-point |
| textures are only supported for the TEXTURE_RECTANGLE_NV target. |
| Specifying an floating-point texture with any other target will produce an |
| INVALID_OPERATION error. |
| |
| (modify last paragraph, p. 117) The internal component resolution is the |
| number of bits allocated to each component in a texture image. If |
| internalformat 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 memory allocation per texture |
| component is assigned by the GL to match the allocations listed in Table |
| 3.16 as closely as possible. ... |
| |
| (modify Table 3.15, p. 118 -- Respecify this table with all extensions |
| relevant to texture formats supported by NVIDIA. For this extension, add |
| four base internal formats.) |
| |
| Base Internal Pixel Component Internal |
| Format Group Type Values Components |
| --------------------- ---------- --------- --------------- |
| ALPHA RGBA A A |
| LUMINANCE RGBA R L |
| LUMINANCE_ALPHA RGBA R,A L,A |
| INTENSITY RGBA R I |
| RGB RGBA R,G,B R,G,B |
| RGBA RGBA R,G,B,A R,G,B,A |
| * COLOR_INDEX CI CI CI |
| * DEPTH_COMPONENT DEPTH DEPTH DEPTH |
| * HILO_NV HILO HI,LO HI,LO |
| * DSDT_NV TEXOFF DS,DT DS,DT |
| * DSDT_MAG_NV TEXOFF DS,DT,MAG DS,DT,MAG |
| * DSDT_MAG_INTENSITY_NV TEXOFF |
| or RGBA DS,DT,MAG,VIB DS,DT,MAG,I |
| FLOAT_R_NV RGBA R R (float) |
| FLOAT_RG_NV RGBA R,G R,G (float) |
| FLOAT_RGB_NV RGBA R,G,B R,G,B (float) |
| FLOAT_RGBA_NV RGBA R,G,B,A R,G,B,A (float) |
| |
| Table 3.15: Conversion from pixel groups to internal texture |
| components. "Pixel Group Type" defines the type of pixel group |
| required for the specified internal format. All internal components |
| are stored as unsigned-fixed point numbers, except for DS/DT (signed |
| fixed-point numbers) and floating-point R,G,B,A (signed floating-point |
| numbers). See Section 3.8.12 for a description of texture components |
| R, G, B, A, L, and I. See NV_texture_shader spec (Section 3.8.13) for |
| a description of texture components HI, LO, DS, DT, and MAG. |
| |
| * - indicates formats found in other extension specs: COLOR_INDEX in |
| EXT_paletted texture; DEPTH_COMPONENT in SGIX_depth_texture; and |
| HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV in |
| NV_texture_shader. |
| |
| (modify Table 3.16, p. 119 -- Respecify this table with all extensions |
| relevant to sized texture internal formats supported by NVIDIA. For this |
| extension, add eight sized internal formats.) |
| |
| Sized Base |
| Int. Format Int. Format Component Name / Type-Size |
| ------------------- --------------- --------------------------- |
| ALPHA4 ALPHA A/U4 |
| ALPHA8 ALPHA A/U8 |
| ALPHA12 ALPHA A/U12 |
| ALPHA16 ALPHA A/U16 |
| LUMINANCE4 LUMINANCE L/U4 |
| LUMINANCE8 LUMINANCE L/U8 |
| LUMINANCE12 LUMINANCE L/U12 |
| LUMINANCE16 LUMINANCE L/U16 |
| LUMINANCE4_ALPHA4 LUMINANCE_ALPHA A/U4 L/U4 |
| LUMINANCE6_ALPHA2 LUMINANCE_ALPHA A/U2 L/U6 |
| LUMINANCE8_ALPHA8 LUMINANCE_ALPHA A/U8 L/U8 |
| LUMINANCE12_ALPHA4 LUMINANCE_ALPHA A/U4 L/U12 |
| LUMINANCE12_ALPHA12 LUMINANCE_ALPHA A/U12 L/U12 |
| LUMINANCE16_ALPHA16 LUMINANCE_ALPHA A/U16 L/U16 |
| INTENSITY4 INTENSITY I/U4 |
| INTENSITY8 INTENSITY I/U8 |
| INTENSITY12 INTENSITY I/U12 |
| INTENSITY16 INTENSITY I/U16 |
| R3_G3_B2 RGB R/U3 G/U3 B/U2 |
| RGB4 RGB R/U4 G/U4 B/U4 |
| RGB5 RGB R/U5 G/U5 B/U5 |
| RGB8 RGB R/U8 G/U8 B/U8 |
| RGB10 RGB R/U10 G/U10 B/10 |
| RGB12 RGB R/U12 G/U12 B/U12 |
| RGB16 RGB R/U16 G/U16 B/U16 |
| RGBA2 RGBA R/U2 G/U2 B/U2 A/U2 |
| RGBA4 RGBA R/U4 G/U4 B/U4 A/U4 |
| RGB5_A1 RGBA R/U5 G/U5 B/U5 A/U1 |
| RGBA8 RGBA R/U8 G/U8 B/U8 A/U8 |
| RGB10_A2 RGBA R/U10 G/U10 B/U10 A/U2 |
| RGBA12 RGBA R/U12 G/U12 B/U12 A/U12 |
| RGBA16 RGBA R/U16 G/U16 B/U16 A/U16 |
| * COLOR_INDEX1_EXT COLOR_INDEX CI/U1 |
| * COLOR_INDEX2_EXT COLOR_INDEX CI/U2 |
| * COLOR_INDEX4_EXT COLOR_INDEX CI/U4 |
| * COLOR_INDEX8_EXT COLOR_INDEX CI/U8 |
| * COLOR_INDEX16_EXT COLOR_INDEX CI/U16 |
| * DEPTH_COMPONENT16_SGIX DEPTH_COMPONENT Z/U16 |
| * DEPTH_COMPONENT24_SGIX DEPTH_COMPONENT Z/U24 |
| * DEPTH_COMPONENT32_SGIX DEPTH_COMPONENT Z/U32 |
| * HILO16_NV HILO HI/U16 LO/U16 |
| * SIGNED_HILO16_NV HILO HI/S16 LO/S16 |
| * SIGNED_RGBA8_NV RGBA R/S8 G/S8 B/S8 A/S8 |
| * SIGNED_RGB8_ |
| UNSIGNED_ALPHA8_NV RGBA R/S8 G/S8 B/S8 A/U8 |
| * SIGNED_RGB8_NV RGB R/S8 G/S8 B/S8 |
| * SIGNED_LUMINANCE8_NV LUMINANCE L/S8 |
| * SIGNED_LUMINANCE8_ |
| ALPHA8_NV LUMINANCE_ALPHA L/S8 A/S8 |
| * SIGNED_ALPHA8_NV ALPHA A/S8 |
| * SIGNED_INTENSITY8_NV INTENSITY I/S8 |
| * DSDT8_NV DSDT_NV DS/S8 DT/S8 |
| * DSDT8_MAG8_NV DSDT_MAG_NV DS/S8 DT/S8 MAG/U8 |
| * DSDT8_MAG8_ DSDT_MAG_ |
| INTENSITY8_NV INTENSITY_NV DS/S8 DT/S8 MAG/U8 I/U8 |
| FLOAT_R16_NV FLOAT_R_NV R/F16 |
| FLOAT_R32_NV FLOAT_R_NV R/F32 |
| FLOAT_RG16_NV FLOAT_RG_NV R/F16 G/F16 |
| FLOAT_RG32_NV FLOAT_RG_NV R/F32 G/F32 |
| FLOAT_RGB16_NV FLOAT_RGB_NV R/F16 G/F16 B/F16 |
| FLOAT_RGB32_NV FLOAT_RGB_NV R/F32 G/F32 B/F32 |
| FLOAT_RGBA16_NV FLOAT_RGBA_NV R/F16 G/F16 B/F16 A/F16 |
| FLOAT_RGBA32_NV FLOAT_RGBA_NV R/F32 G/F32 B/F32 A/F32 |
| |
| Table 3.16: Sized Internal Formats. Describes the correspondence of |
| sized internal formats to base internal formats, and desired component |
| resolutions. Component resolution descriptions are of the form |
| "<NAME>/<TYPE><SIZE>", where NAME specifies the component name in |
| Table 3.15, TYPE is "U" for unsigned fixed-point, "S" for signed |
| fixed-point, and "F" for unsigned floating-point. <SIZE> is the |
| number of requested bits per component. |
| |
| * - indicates formats found in other extension specs: COLOR_INDEX in |
| EXT_paletted texture; DEPTH_COMPONENT in SGIX_depth_texture; and |
| HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV in |
| NV_texture_shader. |
| |
| Modify Section 3.8,7, Minification (p. 141) |
| |
| Change the last paragraph (as modified by the NV_texture_shader |
| extension) to read (only the last sentence changes from the |
| NV_texture_shader version): |
| |
| "If any of the selected tauijk, tauij, or taui in the above equations |
| refer to a border texel with i < -bs, j < bs, k < -bs, i >= ws-bs, j |
| >= hs-bs, or k >= ds-bs, then the border values given by the current |
| setting of TEXTURE_BORDER_VALUES is used instead of the unspecified |
| value or values. If the texture contains color components, the |
| components of the TEXTURE_BORDER_VALUES vector are interpreted as |
| an RGBA color to match the texture's internal format in a manner |
| consistent with table 3.15. If the texture contains HILO components, |
| the first and second components of the TEXTURE_BORDER_VALUES vector |
| are interpreted as the hi and lo components respectively. If the |
| texture contains texture offset group components, the first, second, |
| third, and fourth components of the TEXTURE_BORDER_VALUES vector |
| are interpreted as ds, dt, mag, and vib components respectively. |
| Additionally, the texture border values are clamped appropriately |
| depending on the signedness of each particular component. Unsigned |
| components and components of floating-point textures are clamped to |
| [0,1]; signed components (not including floating-point textures) |
| are clamped to [-1,1]." |
| |
| (Add after the last paragraph in the section) Floating-point textures |
| (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, |
| FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than |
| NEAREST. For such textures, NEAREST filtering is applied regardless of |
| the setting of TEXTURE_MIN_FILTER. |
| |
| Modify Section 3.8.8, Magnification (p. 141) |
| |
| (Add after the last paragraph in the section) Floating-point textures |
| (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, |
| FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than |
| NEAREST. For such textures, NEAREST filtering is applied regardless of |
| the setting of TEXTURE_MAG_FILTER. |
| |
| Modify Section 3.8.13, Texture Environments and Texture Functions (p. 147) |
| |
| (Add paragraph after discussion of all the values used in the |
| miscellaneous tables in this section.) If the base internal format is |
| HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV, FLOAT_R_NV, |
| FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV, the texture lookup results |
| are not supported using conventional OpenGL texture functions. In this |
| case, the corresponding texture function is NONE (Cv = Cf, Av = Af), and |
| it is as though texture mapping were disabled for that texture unit. |
| |
| Modify Section 3.11, Antialiasing Application (p. 155) |
| |
| Finally, if antialiasing is enabled for the primitive from which a |
| rasterized fragment was produced, then the computed coverage value may be |
| applied to the fragment. In RGBA mode with fixed-point frame buffers, the |
| value is multiplied by the fragment's alpha (A) value to yield a final |
| alpha value. In RGBA mode with floating-point frame buffers, the coverage |
| value is simply discarded. In color index mode, the value is used to set |
| the low order bits of the color index value as described in section 3.2. |
| |
| |
| Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| Modify Chapter 4 Introduction (p. 156) |
| |
| (replace next-to-last paragraph) |
| |
| The GL provides three types of color buffers: color index, fixed-point |
| RGBA, or floating-point RGBA. Color index buffers consist of unsigned |
| integer color indices. Fixed-point RGBA buffers consist of R, G, B, and |
| optionally, A unsigned integer values. Floating-point RGBA buffers |
| consist of R, and optionally, G, B, and A floating-point component values, |
| corresponding to the X, Y, Z, and W outputs, respectively, of a fragment |
| program. The number of bitplanes in each of the color buffers, the depth |
| buffer, ... |
| |
| Modify Section 4.1.3, Multisample Fragment Operations (p. 158) |
| |
| This step applies only for fixed-point RGBA color buffers. Otherwise, |
| proceed to the next step. ... |
| |
| Modify Section 4.1.4, Alpha Test (p. 159) |
| |
| This step applies only for fixed-point RGBA color buffers. Otherwise, |
| proceed to the next step. ... |
| |
| Modify Section 4.1.7, Blending (p. 161) |
| |
| (modify second paragraph) |
| |
| This blending is dependent on the incoming fragment's alpha value and that |
| of the corresponding currently stored pixel. Blending applies only for |
| fixed-point RGBA color buffers; otherwise, it is bypassed. ... |
| |
| Modify Section 4.1.8, Dithering (p. 165) |
| |
| Dithering selects between two color values or indices. Dithering does not |
| apply to floating-point RGBA color buffers. ... |
| |
| Modify Section 4.1.9, Logical Operation (p. 165) |
| |
| Finally, a logical operation is applied between the incoming fragment's |
| color or index values and the color or index values stored at the |
| corresponding location in the frame buffer. Logical operations do not |
| apply to floating-point color buffers. ... |
| |
| Modify Section 4.2.3, Clearing the Buffers (p. 171) |
| |
| ... |
| |
| void ClearColor(float r, float g, float b, float a); |
| |
| sets the clear value for RGBA color buffers. When a fixed-point color |
| buffer is cleared, the effective clear color is derived by clamping each |
| component to [0,1] and converting to fixed-point according to the rules in |
| section 2.13.9. When a floating-point color buffer is cleared, the |
| components of the clear value are used directly without being clamped. |
| |
| Modify Section 4.2.4, The Accumulation Buffer (p. 172) |
| |
| (modify last paragraph) ... If there is no accumulation buffer, or if |
| color buffer is not fixed-point RGBA, Accum generates the error |
| INVALID_OPERATION. |
| |
| Modify Section 4.3.2, Reading Pixels |
| |
| (modify "Conversion of RGBA Values", p. 176) This step applies only if the |
| GL is in RGBA mode, and then only if format is neither STENCIL INDEX nor |
| DEPTH COMPONENT. The R, G, B, and A values form a group of elements. If |
| the color buffer has fixed-point format, 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.13.9). |
| |
| (add to end of "Final Conversion", p. 177) ... For an RGBA color, |
| components are clamped depending on the data type of the buffer being |
| read. For fixed-point buffers, each component is clamped to [0.1]. For |
| floating-point buffers, if <type> is not FLOAT or HALF_FLOAT_NV, each |
| component is clamped to [0,1] if <type> is unsigned or [-1,1] if <type> is |
| signed and then converted according to Table 4.7. |
| |
| Modify section 4.4.4, as defined by EXT_framebuffer_object, |
| definition of color-renderable: |
| |
| * An internal format is "color-renderable" if it is RGB, RGBA, |
| FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, FLOAT_RGBA_NV, or one |
| of the formats from table 3.16 whose base internal format is |
| RGB, RGBA, FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or |
| FLOAT_RGBA_NV. No other formats, including compressed |
| internal formats, are color-renderable. |
| |
| Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) |
| |
| None. |
| |
| Additions to Chapter 6 of the OpenGL 1.3 Specification (State and |
| State Requests) |
| |
| Modify Section 6.1.4, Texture Queries (p. 200) |
| |
| Modify Table 6.1 (add new rows, corresponding to new internal formats, |
| p. 202) |
| |
| Base Internal Format R G B A |
| -------------------- --- --- --- --- |
| FLOAT_R_NV R 0 0 1 |
| FLOAT_RG_NV R G 0 1 |
| FLOAT_RGB_NV R G B 1 |
| FLOAT_RGBA_NV R G B A |
| |
| Additions to Appendix A of the OpenGL 1.3 Specification (Invariance) |
| |
| None. |
| |
| Additions to the WGL Specification |
| |
| First, close your eyes and pretend that a WGL specification actually |
| existed. Maybe if we all concentrate hard enough, one will magically |
| appear. |
| |
| Modify/add to the description of <piAttributes> in |
| wglGetPixelFormatAttribivARB and <pfAttributes> in |
| wglGetPixelFormatAttribfvARB: |
| |
| WGL_FLOAT_COMPONENTS_NV |
| True if the R, G, B, and A components of each color buffer are |
| represented as (unclamped) floating-point numbers. |
| |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV |
| True if the pixel format describes a floating-point color that can be |
| bound to a texture rectangle with internal formats of FLOAT_R_NV, |
| FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV, respectively. Currently |
| only pbuffers can be bound as textures so this attribute will only be |
| TRUE if WGL_DRAW_TO_PBUFFER is also TRUE. Additionally, |
| floating-point color buffers can not be bound to texture targets other |
| than TEXTURE_RECTANGLE_NV. |
| |
| Add new table entries for pixel format attribute matching in |
| wglChoosePixelFormatARB. |
| |
| Attribute Type Match Criteria |
| ------------------------- ------- -------------- |
| WGL_FLOAT_COMPONENTS_NV boolean exact |
| WGL_BIND_TO_TEXTURE_ boolean exact |
| RECTANGLE_FLOAT_R_NV |
| WGL_BIND_TO_TEXTURE_ boolean exact |
| RECTANGLE_FLOAT_RG_NV |
| WGL_BIND_TO_TEXTURE_ boolean exact |
| RECTANGLE_FLOAT_RGB_NV |
| WGL_BIND_TO_TEXTURE_ boolean exact |
| RECTANGLE_FLOAT_RGBA_NV |
| |
| (In the wglCreatePbufferARB section, modify the attribute list) |
| |
| WGL_TEXTURE_FORMAT_ARB |
| |
| This attribute indicates the base internal format of the texture that |
| will be created when a color buffer of a pbuffer is bound to a texture |
| map. It can be set to WGL_TEXTURE_RGB_ARB (indicating an internal |
| format of RGB), WGL_TEXTURE_RGBA_ARB (indicating a base internal |
| format of RGBA), WGL_TEXTURE_FLOAT_R_NV (indicating a base internal |
| format of FLOAT_R_NV), WGL_TEXTURE_FLOAT_RG_NV (indicating a base |
| internal format of FLOAT_RG_NV), WGL_TEXTURE_FLOAT_RGB_NV (indicating |
| a base internal format of FLOAT_RGB_NV), WGL_TEXTURE_FLOAT_RGBA_NV |
| (indicating a base internal format of FLOAT_RGBA_NV), or |
| WGL_NO_TEXTURE_ARB. The default value is WGL_NO_TEXTURE_ARB. |
| |
| |
| (In the wglCreatePbufferARB section, modify the discussion of what happens |
| to the depth/stencil/accum buffers when switching between mipmap levels or |
| cube map faces.) |
| |
| For pbuffers with a texture format of WGL_TEXTURE_RGB_ARB, |
| WGL_TEXTURE_RGBA_ARB, WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV, |
| WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, there will be a |
| separate set of color buffers for each mipmap level and cube map face in |
| the pbuffer. Otherwise, the WGL implementation is free to share a single |
| set of color, auxillary, and accumulation buffers between levels or faces. |
| |
| |
| (In the wglCreatePbufferARB section, modify the error list) |
| |
| ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is |
| WGL_TEXTURE_FLOAT_R_NV, |
| WGL_TEXTURE_FLOAT_RG_NV, |
| WGL_TEXTURE_FLOAT_RGB_NV, or |
| WGL_TEXTURE_FLOAT_RGBA_NV, and |
| WGL_TEXTURE_TARGET_ARB is not |
| WGL_TEXTURE_RECTANGLE_NV. |
| |
| ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is |
| WGL_TEXTURE_FLOAT_R_NV, |
| WGL_TEXTURE_TARGET_ARB is |
| WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV |
| attribute is not set in the pixel format. |
| |
| ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is |
| WGL_TEXTURE_FLOAT_RG_NV, |
| WGL_TEXTURE_TARGET_ARB is |
| WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV |
| attribute is not set in the pixel format. |
| |
| ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is |
| WGL_TEXTURE_FLOAT_RGB_NV, |
| WGL_TEXTURE_TARGET_ARB is |
| WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV |
| attribute is not set in the pixel format. |
| |
| ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is |
| WGL_TEXTURE_FLOAT_RGBA_NV, |
| WGL_TEXTURE_TARGET_ARB is |
| WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV |
| attribute is not set in the pixel format. |
| |
| Modify wglBindTexImageARB: |
| |
| ... |
| |
| The pbuffer attribute WGL_TEXTURE_FORMAT_ARB determines the base |
| internal format of the texture. The format-specific component sizes |
| are also determined by pbuffer attributes as shown in the table below. |
| The component sizes are dependent on the format of the texture. |
| |
| Component Size Format |
| --------- ------------------------ ---------------------------- |
| R WGL_RED_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, |
| FLOAT_RGB, FLOAT_RGBA |
| G WGL_GREEN_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, |
| FLOAT_RGB, FLOAT_RGBA |
| B WGL_BLUE_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, |
| FLOAT_RGB, FLOAT_RGBA |
| A WGL_ALPHA_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, |
| FLOAT_RGB, FLOAT_RGBA |
| |
| |
| Additions to the AGL Specification |
| |
| None |
| |
| Additions to the GLX Specification |
| |
| <very incomplete> |
| |
| The GLX_FLOAT_COMPONENTS_NV framebuffer config attribute is a |
| boolean (or GLX_DONT_CARE) indicating if floating-point components |
| are requested. |
| |
| Dependencies on EXT_paletted_texture, SGIX_depth_texture, and NV_texture_shader |
| |
| If any of these extensions are not supported, the rows in Tables 3.15 and |
| 3.16 corresponding to texture formats defined by the unsupported extension |
| should be removed. |
| |
| If NV_texture_shader is not supported, ignore the amended |
| paragraph from the NV_texture_shader specificiaton describing |
| TEXTURE_BORDER_VALUES clamping in favor of the original OpenGL |
| specification language. |
| |
| Dependencies on NV_half_float |
| |
| If GL_NV_half_float is not supported, all references to HALF_FLOAT_NV |
| should be deleted. |
| |
| Dependencies on ARB_color_buffer_float and ATI_pixel_format_float |
| |
| If ARB_color_buffer_float and ATI_pixel_format_float are also supported, |
| the GL would have two different floating-point frame buffer models with |
| different restrictions. To avoid having to carry these differences all |
| the way down the pipeline and provide two distinct sets of frame buffer |
| formats, the following limitations on rendering to floating-point color |
| buffers in this extension are removed if ARB_color_buffer_float or |
| ATI_pixel_format_float is supported: |
| |
| Modify Section 3.11, Antialiasing Application (p. 155) |
| |
| ... In RGBA mode with floating-point frame buffers, the coverage value |
| is simply discarded. ... |
| |
| Modify Section 4.1.3, Multisample Fragment Operations (p. 158) |
| |
| This step applies only for fixed-point RGBA color buffers. Otherwise, |
| proceed to the next step. ... |
| |
| Modify Section 4.1.4, Alpha Test (p. 159) |
| |
| This step applies only for fixed-point RGBA color buffers. Otherwise, |
| proceed to the next step. ... |
| |
| Modify Section 4.1.7, Blending (p. 161) |
| |
| (modify second paragraph) |
| |
| This blending is dependent on the incoming fragment's alpha value and |
| that of the corresponding currently stored pixel. Blending applies only |
| for fixed-point RGBA color buffers; otherwise, it is bypassed. ... |
| |
| Modify Section 4.2.4, The Accumulation Buffer (p. 172) |
| |
| (modify last paragraph) ..., or if color buffer is not fixed-point RGBA, |
| |
| When blending is enabled with a floating-point color buffer, the spec |
| language in ARB_color_buffer_float describes how blending is performed. |
| |
| The above restrictions remain in effect on NV3X (GeForce FX, Quadro FX) |
| hardware, where neither ARB_color_buffer_float nor ATI_pixel_format_float |
| is supported. |
| |
| Additionally, if ARB_color_buffer_float or ATI_pixel_format_float is |
| supported, the following errors are not generated: |
| |
| INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap, CopyPixels, |
| or a command that performs an explicit Begin if the color buffer has a |
| floating-point RGBA format and FRAGMENT_PROGRAM_NV is disabled. |
| |
| INVALID_OPERATION is generated by Accum if the color buffer has a color |
| index or floating-point RGBA format. |
| |
| Dependencies on ARB_texture_float and ATI_texture_float |
| |
| If ARB_texture_float or ATI_texture_float is also supported, the GL would |
| have two different sets of floating-point textures with different |
| restrictions. To avoid having to carry these differences all the way down |
| the pipeline, the following limitations on filtering of NV_float_buffer |
| textures are removed if ARB_texture_float or ATI_texture_float is |
| supported: |
| |
| Modify Section 3.8,7, Minification (p. 141) |
| |
| (Add after the last paragraph in the section) Floating-point textures |
| (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, |
| FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other |
| than NEAREST. For such textures, NEAREST filtering is applied |
| regardless of the setting of TEXTURE_MIN_FILTER. |
| |
| Modify Section 3.8.8, Magnification (p. 141) |
| |
| (Add after the last paragraph in the section) Floating-point textures |
| (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, |
| FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other |
| than NEAREST. For such textures, NEAREST filtering is applied |
| regardless of the setting of TEXTURE_MAG_FILTER. |
| |
| The above restrictions remain in effect on NV3X (GeForce FX, Quadro FX) |
| hardware, where ARB_texture_float and ATI_texture_float are not supported. |
| |
| The following restriction requiring the use of rectangle textures does |
| remain in effect for NV_float_buffer texture formats, even though |
| ARB_texture_float and ATI_texture_float provides the ability to use |
| floating-point textures with non-rectangle targets. If this capability is |
| required, use the texture formats defined in ARB_texture_float or |
| ATI_texture_float. |
| |
| (add between first and second paragraphs, p.117) Textures with a base |
| internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, and |
| FLOAT_RGBA_NV are known as floating-point textures. Floating-point |
| textures are only supported for the TEXTURE_RECTANGLE_NV target. |
| Specifying an floating-point texture with any other target will produce |
| an INVALID_OPERATION error. |
| |
| Dependencies on EXT_framebuffer_object |
| |
| If EXT_framebuffer_object is not supported, then ignore any |
| reference to EXT_framebuffer_object. |
| |
| GLX Protocol |
| |
| None. |
| |
| Errors |
| |
| INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap, CopyPixels, |
| or a command that performs an explicit Begin if the color buffer has a |
| floating-point RGBA format and FRAGMENT_PROGRAM_NV is disabled. |
| |
| INVALID_OPERATION is generated by TexImage3D, TexImage2D, TexImage1D, |
| TexSubImage3D, TexSubImage2D, or TexSubImage1D if the pixel group type |
| corresponding to <format> is not compatible with the base internal format |
| of the texture. |
| |
| INVALID_OPERATION is generated by TexImage3D, TexImage1D, or |
| CopyTexImage1D if the base internal format corresponding to |
| <internalformat> is FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or |
| FLOAT_RGBA_NV. |
| |
| INVALID_OPERATION is generated by TexImage2D or CopyTexImage2D if the base |
| internal format corresponding to <internalformat> is FLOAT_R_NV, |
| FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV and <target> is not |
| TEXTURE_RECTANGLE_NV. |
| |
| INVALID_OPERATION is generated by Accum if the color buffer has a color |
| index or floating-point RGBA format. |
| |
| ERROR_INVALID_DATA is generated by wglCreatePbufferARB if |
| WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV, |
| WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, and |
| WGL_TEXTURE_TARGET_ARB is not WGL_TEXTURE_RECTANGLE_NV. |
| |
| ERROR_INVALID_DATA is generated by wglCreatePbufferARB if |
| WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_TARGET_ARB |
| is WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV attribute is not set in the pixel |
| format. |
| |
| ERROR_INVALID_DATA is generated by wglCreatePbufferARB if |
| WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_TARGET_ARB |
| is WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV attribute is not set in the |
| pixel format. |
| |
| ERROR_INVALID_DATA is generated by wglCreatePbufferARB if |
| WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGB_NV, WGL_TEXTURE_TARGET_ARB |
| is WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV attribute is not set in the |
| pixel format. |
| |
| ERROR_INVALID_DATA is generated by wglCreatePbufferARB if |
| WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGBA_NV, |
| WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the |
| WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV attribute is not set in the |
| pixel format. |
| |
| |
| New State |
| |
| (Modify Table 6.15, Texture Objects (cont.), p. 223) |
| |
| Init. |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------------------------- ----- ------------ ----- --------------------- ----- ------------ |
| TEXTURE_FLOAT_COMPONENTS_NV n x B GetTexLevel- 0 True if texture holds 3.8 - |
| unclamped floating- |
| point values |
| |
| (Modify Table 6.19, Framebuffer Control, p. 227) |
| |
| Init. |
| Get Value Type Get Command Value Description Sec. Attribute |
| -------------------------- ---- ----------- ------- ------------------------ ----- ------------ |
| COLOR_CLEAR_VALUE C GetFloatv 0,0,0,0 Color buffer clear value 4.2.3 color-buffer |
| (RGBA mode), each value |
| clamped to [0,1]. |
| FLOAT_CLEAR_COLOR_VALUE_NV 4xR GetFloatv 0,0,0,0 Color buffer clear value 4.2.3 color-buffer |
| (RGBA mode), each value |
| unclamped. |
| |
| |
| New Implementation Dependent State |
| |
| (Modify Table 6.28, Implementation Dependent Values, p. 236) |
| |
| Init. |
| Get Value Type Get Command Value Description Sec. Attribute |
| ------------------ ---- ----------- ----- --------------------- ---- --------- |
| FLOAT_RGBA_MODE_NV B GetBooleanv - True if color buffers 4 - |
| store floating-point |
| data |
| |
| NV3x Implementation Details |
| |
| NV3x GPUs (GeForce FX, etc.) support hardware acceleration for float |
| textures with two or more components only when the repeat mode state |
| (S and T) is GL_CLAMP_TO_EDGE. If you use either the GL_CLAMP or |
| GL_CLAMP_TO_BORDER repeat modes with a float texture with two or |
| more components, the software rasterizer is used. |
| |
| However, if you use a single-component float texture (GL_FLOAT_R_NV, |
| etc.), all clamping repeat modes (GL_CLAMP, GL_CLAMP_TO_EDGE, and |
| GL_CLAMP_TO_BORDER) are available with full hardware acceleration. |
| |
| The two-, three-, and four-component texture formats all use the |
| same amount of texture memory storage (128 bits per texel for the |
| GL_FLOAT_x32 formats, and 64 bits per texel for the GL_FLOAT_x16 |
| formats). Future GPUs will likely store two and three component |
| float textures more efficiently. |
| |
| The GL_FLOAT_R32_NV and GL_FLOAT_R16_NV texture formats each use 32 |
| bits per texel. Future GPUs will likely store GL_FLOAT_R16_NV more |
| efficiently. |
| |
| NVIDIA treats the unsized internal formats GL_FLOAT_R_NV, |
| GL_FLOAT_RGBA_NV, etc. the same as GL_FLOAT_R32_NV, |
| GL_FLOAT_RGBA32_NV, etc. |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- -------------------------------------------- |
| 20 11/03/06 mjk Update Status |
| |
| 19 01/10/05 mjk Add very minimal GLX discussion |
| |
| 18 09/12/05 jjuliano Describe interaction with EXT_framebuffer_object. |
| The GL_FLOAT_*_NV texture formats are |
| color-renderable. |
| |
| 17 04/04/05 pbrown Describe interactions with ARB_texture_float and |
| ARB_color_buffer_float (as well as the ATI |
| equivalents), which remove some of the |
| restrictions of this extension, when supported. |
| |
| 16 06/16/03 pbrown Corrected the usage of WGL_TEXTURE_FLOAT_R_NV and |
| related enums in the list of enumerants. |
| |
| 15 01/23/03 mjk Document texture border color (values) behavior |
| for float textures. See issue. |
| |
| 14 01/20/03 mjk Added NV3x Implementation Details section. |
| |
| 13 11/27/02 pbrown Fixed the name of the clear color query enum in |
| the state table -- the core spec says |
| COLOR_CLEAR_VALUE. The enum in this extension is |
| FLOAT_CLEAR_COLOR_VALUE_NV. Documented this |
| inconsistency. |
| |
| 12 10/09/02 pbrown Clarified that the floating-point internal format |
| enums can not be passed TexImage1D and |
| TexImage3D. |
| |
| 11 07/19/02 pbrown Cleaned up a number of items in the issues |
| section. Removed limitation that DrawPixels and |
| CopyPixels color components are clamped to |
| [0,1]. Removed language modifying multisample |
| color filtering -- if multisample buffers are |
| supported, the color components will be filtered |
| on a componentwise basis. |
| |
| 10 07/09/02 pbrown Fixed contradictory issue resolutions. |
| |
| 9 01/31/02 pbrown Added revision history. |
| |
| 8 01/29/02 pbrown Fix spec to indicate that |
| TEXTURE_FLOAT_COMPONENTS_NV is queried by |
| GetTexLevelParameter*() calls instead of the |
| generic gets. |
| |
| 7 12/26/01 pbrown Documented limitation where DrawPixels/CopyPixels |
| data are clamped to [0,1], even when the color |
| buffer is floating-point. This is consistent |
| with the fact that pixel data is supposed to go |
| in f[COL0] (fixed-point interpolator). Changed |
| float texture to RGBA expansion to always fill in |
| with (0,0,0,1), not (0,0,0,0). This is more |
| consistent with our other texture formats. |
| |
| 6 11/30/01 pbrown Assigned WGL enumerant values. |
| |
| 5 11/27/01 pbrown Modify NV_float_buffer to eliminate the |
| dependencies on NV_render_depth_texture, now that |
| they are no longer necessary. More pedantic |
| fixes. |
| |
| 4 10/29/01 pbrown Add documentation of possible uses of |
| floating-point color buffers. |
| |
| 3 10/19/01 pbrown Assign GL enumerants. Fixed some bugs in the use |
| of #defines in the spec. Added ARB_imaging |
| and SGIS_generate_mipmap interaction issues. |
