| Name |
| |
| EXT_texture_integer |
| |
| Name Strings |
| |
| GL_EXT_texture_integer |
| |
| Contact |
| |
| Michael Gold, NVIDIA Corporation (gold 'at' nvidia.com) |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) |
| |
| Status |
| |
| Shipping for GeForce 8 Series (November 2006) |
| |
| Version |
| |
| Last Modified Date: 05/20/2010 |
| NVIDIA Revision: 6 |
| |
| Number |
| |
| 343 |
| |
| Dependencies |
| |
| OpenGL 2.0 is required. |
| |
| NV_gpu_program4 or EXT_gpu_shader4 is required. |
| |
| ARB_texture_float affects the definition of this extension. |
| |
| ARB_color_buffer_float affects the definition of this extension. |
| |
| EXT_framebuffer_object affects the definition of this extension. |
| |
| This extension is written against the OpenGL 2.0 specification. |
| |
| Overview |
| |
| Fixed-point textures in unextended OpenGL have integer components, |
| but those values are taken to represent floating-point values in |
| the range [0,1]. These integer components are considered |
| "normalized" integers. When such a texture is accessed by a |
| shader or by fixed-function fragment processing, floating-point |
| values are returned. |
| |
| This extension provides a set of new "unnormalized" integer texture |
| formats. Formats with both signed and unsigned integers are provided. In |
| these formats, the components are treated as true integers. When such |
| textures are accessed by a shader, actual integer values are returned. |
| |
| Pixel operations that read from or write to a texture or color |
| buffer with unnormalized integer components follow a path similar |
| to that used for color index pixel operations, except that more |
| than one component may be provided at once. Integer values flow |
| through the pixel processing pipe, and no pixel transfer |
| operations are performed. Integer format enumerants used for such |
| operations indicate unnormalized integer data. |
| |
| Textures or render buffers with unnormalized integer formats may also be |
| attached to framebuffer objects to receive fragment color values written |
| by a fragment shader. Per-fragment operations that require floating-point |
| color components, including multisample alpha operations, alpha test, |
| blending, and dithering, have no effect when the corresponding colors are |
| written to an integer color buffer. The NV_gpu_program4 and |
| EXT_gpu_shader4 extensions add the capability to fragment programs and |
| fragment shaders to write signed and unsigned integer output values. |
| |
| This extension does not enforce type consistency for texture accesses or |
| between fragment shaders and the corresponding framebuffer attachments. |
| The results of a texture lookup from an integer texture are undefined: |
| |
| * for fixed-function fragment processing, or |
| |
| * for shader texture accesses expecting floating-point return values. |
| |
| The color components used for per-fragment operations and written into a |
| color buffer are undefined: |
| |
| * for fixed-function fragment processing with an integer color buffer, |
| |
| * for fragment shaders that write floating-point color components to an |
| integer color buffer, or |
| |
| * for fragment shaders that write integer color components to a color |
| buffer with floating point or normalized integer components. |
| |
| |
| New Procedures and Functions |
| |
| void ClearColorIiEXT ( int r, int g, int b, int a ); |
| void ClearColorIuiEXT ( uint r, uint g, uint b, uint a ); |
| void TexParameterIivEXT( enum target, enum pname, int *params ); |
| void TexParameterIuivEXT( enum target, enum pname, uint *params ); |
| void GetTexParameterIivEXT ( enum target, enum pname, int *params); |
| void GetTexParameterIuivEXT ( enum target, enum pname, uint *params); |
| |
| New Tokens |
| |
| Accepted by the <pname> parameters of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| RGBA_INTEGER_MODE_EXT 0x8D9E |
| |
| Accepted by the <internalFormat> parameter of TexImage1D, |
| TexImage2D, and TexImage3D: |
| |
| RGBA32UI_EXT 0x8D70 |
| RGB32UI_EXT 0x8D71 |
| ALPHA32UI_EXT 0x8D72 |
| INTENSITY32UI_EXT 0x8D73 |
| LUMINANCE32UI_EXT 0x8D74 |
| LUMINANCE_ALPHA32UI_EXT 0x8D75 |
| |
| RGBA16UI_EXT 0x8D76 |
| RGB16UI_EXT 0x8D77 |
| ALPHA16UI_EXT 0x8D78 |
| INTENSITY16UI_EXT 0x8D79 |
| LUMINANCE16UI_EXT 0x8D7A |
| LUMINANCE_ALPHA16UI_EXT 0x8D7B |
| |
| RGBA8UI_EXT 0x8D7C |
| RGB8UI_EXT 0x8D7D |
| ALPHA8UI_EXT 0x8D7E |
| INTENSITY8UI_EXT 0x8D7F |
| LUMINANCE8UI_EXT 0x8D80 |
| LUMINANCE_ALPHA8UI_EXT 0x8D81 |
| |
| RGBA32I_EXT 0x8D82 |
| RGB32I_EXT 0x8D83 |
| ALPHA32I_EXT 0x8D84 |
| INTENSITY32I_EXT 0x8D85 |
| LUMINANCE32I_EXT 0x8D86 |
| LUMINANCE_ALPHA32I_EXT 0x8D87 |
| |
| RGBA16I_EXT 0x8D88 |
| RGB16I_EXT 0x8D89 |
| ALPHA16I_EXT 0x8D8A |
| INTENSITY16I_EXT 0x8D8B |
| LUMINANCE16I_EXT 0x8D8C |
| LUMINANCE_ALPHA16I_EXT 0x8D8D |
| |
| RGBA8I_EXT 0x8D8E |
| RGB8I_EXT 0x8D8F |
| ALPHA8I_EXT 0x8D90 |
| INTENSITY8I_EXT 0x8D91 |
| LUMINANCE8I_EXT 0x8D92 |
| LUMINANCE_ALPHA8I_EXT 0x8D93 |
| |
| Accepted by the <format> parameter of TexImage1D, TexImage2D, |
| TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D, |
| DrawPixels and ReadPixels: |
| |
| RED_INTEGER_EXT 0x8D94 |
| GREEN_INTEGER_EXT 0x8D95 |
| BLUE_INTEGER_EXT 0x8D96 |
| ALPHA_INTEGER_EXT 0x8D97 |
| RGB_INTEGER_EXT 0x8D98 |
| RGBA_INTEGER_EXT 0x8D99 |
| BGR_INTEGER_EXT 0x8D9A |
| BGRA_INTEGER_EXT 0x8D9B |
| LUMINANCE_INTEGER_EXT 0x8D9C |
| LUMINANCE_ALPHA_INTEGER_EXT 0x8D9D |
| |
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
| |
| Modify Section 3.6.4 (Rasterization of Pixel Rectangles), p. 126: |
| |
| (modify the last paragraph, p. 126) |
| Pixels are drawn using |
| |
| void DrawPixels( sizei width, sizei height, enum format, |
| enum type, void *data ); |
| |
| <format> is a symbolic constant indicating what the values in |
| memory represent. <width> and <height> are the width and height, |
| respectively, of the pixel rectangle to be drawn. <data> is a |
| pointer to the data to be drawn. These data are represented with |
| one of seven GL data types, specified by <type>. The |
| correspondence between the twenty type token values and the GL |
| data types they indicate is given in table 3.5. If the GL is in |
| color index mode and <format> is not one of COLOR_INDEX, |
| STENCIL_INDEX, or DEPTH_COMPONENT, then the error |
| INVALID_OPERATION occurs. If the GL is in RGBA mode and the color |
| buffer is an integer format and no fragment shader is active, the |
| error INVALID_OPERATION occurs. If <type> is BITMAP and <format> |
| is not COLOR_INDEX or STENCIL_INDEX then the error INVALID_ENUM |
| occurs. If <format> is one of the integer component formats as |
| defined in table 3.6, and <type> is FLOAT, then the error |
| INVALID_ENUM occurs. Some additional constraints on the |
| combinations of format and type values that are accepted is |
| discussed below. |
| |
| (add the following to table 3.6, p. 129) |
| Format Name Element Meaning and Order Target Buffer |
| ------ ---- ------- ------- --- ----- ------ ------ |
| RED_INTEGER_EXT iR Color |
| GREEN_INTEGER_EXT iG Color |
| BLUE_INTEGER_EXT iB Color |
| ALPHA_INTEGER_EXT iA Color |
| RGB_INTEGER_EXT iR, iG, iB Color |
| RGBA_INTEGER_EXT iR, iG, iB, iA Color |
| BGR_INTEGER_EXT iB, iG, iR Color |
| BGRA_INTEGER_EXT iB, iG, iR, iA Color |
| LUMINANCE_INTEGER_EXT iLuminance Color |
| LUMINANCE_ALPHA_INTEGER_EXT iLuminance, iA Color |
| |
| Table 3.6: DrawPixels and ReadPixels formats. The second column |
| gives a description of and the number and order of elements in a |
| group. Unless specified as an index, formats yield components. |
| Components are floating-point unless prefixed with the letter 'i' |
| which indicates they are integer. |
| |
| (modify first paragraph, p. 129) |
| Data are taken from host memory as a sequence of signed or |
| unsigned bytes (GL data types byte and ubyte), signed or unsigned |
| short integers (GL data types short and ushort), signed or |
| unsigned integers (GL data types int and uint), or floating point |
| values (GL data type float). These elements are grouped into sets |
| of one, two, three, or four values, depending on the format, to |
| form a group. Table 3.6 summarizes the format of groups obtained |
| from memory; it also indicates those formats that yield indices |
| and those that yield floating-point or integer components. |
| |
| (modify the last paragraph, p. 135) |
| |
| Conversion to floating-point |
| |
| This step applies only to groups of floating-point components. It |
| is not performed on indices or integer components. |
| |
| (modify the third paragraph, p. 136) |
| Final Expansion to RGBA |
| |
| This step is performed only for non-depth component groups. Each |
| group is converted to a group of 4 elements as follows: if a group |
| does not contain an A element, then A is added and set to 1 for |
| integer components or 1.0 for floating-point components. If any of |
| R, G, or B is missing from the group, each missing element is |
| added and assigned a value of 0 for integer components or 0.0 for |
| floating-point components. |
| |
| (modify the last paragraph, p. 136) |
| Final Conversion |
| |
| For a color index, final conversion consists of masking the bits |
| of the index to the left of the binary point by 2^n - 1, where n is |
| the number of bits in an index buffer. For floating-point RGBA |
| components, each element is clamped to [0, 1]. The resulting |
| values are converted to fixed-point according to the rules given |
| in section 2.14.9 (Final Color Processing). For integer RGBA |
| components, no conversion is applied. For a depth component, an |
| element is first clamped to [0, 1] and then converted to |
| fixed-point as if it were a window z value (see section 2.11.1, |
| Controlling the Viewport). Stencil indices are masked by 2^n - 1, |
| where n is the number of bits in the stencil buffer. |
| |
| Modify Section 3.6.5 (Pixel Transfer Operations), p. 137 |
| |
| (modify last paragraph, p. 137) |
| The GL defines five kinds of pixel groups: |
| |
| 1. Floating-point RGBA component: Each group comprises four color |
| components in floating point format: red, green, blue, and |
| alpha. |
| |
| 2. Integer RGBA component: Each group comprises four color |
| components in integer format: red, green, blue, and alpha. |
| |
| 3. Depth component: Each group comprises a single depth component. |
| |
| 4. Color index: Each group comprises a single color index. |
| |
| 5. Stencil index: Each group comprises a single stencil index. |
| |
| (modify second paragraph, p. 138) |
| Each operation described in this section is applied sequentially |
| to each pixel group in an image. Many operations are applied only |
| to pixel groups of certain kinds; if an operation is not |
| applicable to a given group, it is skipped. None of the |
| operations defined in this section affect integer RGBA component |
| pixel groups. |
| |
| Modify Section 3.8 (Texturing), p. 149 |
| |
| (insert between the first and second paragraphs, p. 150) |
| The internal data type of a texture may be fixed-point, |
| floating-point, signed integer or unsigned integer, depending on |
| the internalformat of the texture. The correspondence between |
| internalformat and the internal data type is given in table 3.16. |
| Fixed-point and floating-point textures return a floating-point |
| value and integer textures return signed or unsigned integer |
| values. When a fragment shader is active, the shader is |
| responsible for interpreting the result of a texture lookup as the |
| correct data type, otherwise the result is undefined. Fixed |
| functionality assumes floating-point data, hence the result of |
| using fixed functionality with integer textures is undefined. |
| |
| 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. If the <internalformat> of the texture is integer, |
| the components are clamped to the representable range of the |
| internal format: for signed formats, this is [-2^(n-1), 2^(n-1)-1] |
| where n is the number of bits per component; for unsigned formats, |
| the range is [0, 2^n-1]. For R, G, B, and A, if the |
| <internalformat> of the texture is fixed-point, the components are |
| clamped to [0, 1]. Otherwise, the components are not modified. |
| |
| (insert between paragraphs five and six, p. 151) |
| Textures with integer internal formats (table 3.16) require |
| integer data. The error INVALID_OPERATION is generated if the |
| internal format is integer and <format> is not one of the integer |
| formats listed in table 3.6, or if the internal format is not |
| integer and <format> is an integer format, or if <format> is an |
| integer format and <type> is FLOAT. |
| |
| (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 |
| ----------------------- --------------- ---- ---- ---- ---- ---- ---- |
| ALPHA8I_EXT ALPHA i8 |
| ALPHA8UI_EXT ALPHA ui8 |
| ALPHA16I_EXT ALPHA i16 |
| ALPHA16UI_EXT ALPHA ui16 |
| ALPHA32I_EXT ALPHA i32 |
| ALPHA32UI_EXT ALPHA ui32 |
| LUMINANCE8I_EXT LUMINANCE i8 |
| LUMINANCE8UI_EXT LUMINANCE ui8 |
| LUMINANCE16I_EXT LUMINANCE i16 |
| LUMINANCE16UI_EXT LUMINANCE ui16 |
| LUMINANCE32I_EXT LUMINANCE i32 |
| LUMINANCE32UI_EXT LUMINANCE ui32 |
| LUMINANCE_ALPHA8I_EXT LUMINANCE_ALPHA i8 i8 |
| LUMINANCE_ALPHA8UI_EXT LUMINANCE_ALPHA ui8 ui8 |
| LUMINANCE_ALPHA16I_EXT LUMINANCE_ALPHA i16 i16 |
| LUMINANCE_ALPHA16UI_EXT LUMINANCE_ALPHA ui16 ui16 |
| LUMINANCE_ALPHA32I_EXT LUMINANCE_ALPHA i32 i32 |
| LUMINANCE_ALPHA32UI_EXT LUMINANCE_ALPHA ui32 ui32 |
| INTENSITY8I_EXT INTENSITY i8 |
| INTENSITY8UI_EXT INTENSITY ui8 |
| INTENSITY16I_EXT INTENSITY i16 |
| INTENSITY16UI_EXT INTENSITY ui16 |
| INTENSITY32I_EXT INTENSITY i32 |
| INTENSITY32UI_EXT INTENSITY ui32 |
| RGB8I_EXT RGB i8 i8 i8 |
| RGB8UI_EXT RGB ui8 ui8 ui8 |
| RGB16I_EXT RGB i16 i16 i16 |
| RGB16UI_EXT RGB ui16 ui16 ui16 |
| RGB32I_EXT RGB i32 i32 i32 |
| RGB32UI_EXT RGB ui32 ui32 ui32 |
| RGBA8I_EXT RGBA i8 i8 i8 i8 |
| RGBA8UI_EXT RGBA ui8 ui8 ui8 ui8 |
| RGBA16I_EXT RGBA i16 i16 i16 i16 |
| RGBA16UI_EXT RGBA ui16 ui16 ui16 ui16 |
| RGBA32I_EXT RGBA i32 i32 i32 i32 |
| RGBA32UI_EXT RGBA ui32 ui32 ui32 ui32 |
| |
| Table 3.16: Correspondence of sized internal formats to base |
| internal formats, internal data type and desired component |
| resolutions for each sized internal format. The component |
| resolution prefix indicates the internal data type: <f> is |
| floating point, <i> is signed integer, <ui> is unsigned integer, |
| and no prefix is fixed-point. |
| |
| |
| Modify Section 3.8.2 (Alternate Texture Image Specification |
| Commands), p. 159: |
| |
| (modify the second paragraph, p. 159) |
| The error INVALID_OPERATION is generated if depth component data |
| is required and no depth buffer is present, or if integer RGBA |
| data is required and the format of the current color buffer is not |
| integer, or if floating-point or fixed-point RGBA data is required |
| and the format of the current color buffer is integer. |
| |
| Modify Section 3.8.4 (Texture Parameters), p. 166: |
| |
| Various parameters control how the texture array is treated when |
| specified or changed, and when applied to a fragment. Each |
| parameter is set by calling |
| |
| void TexParameter{if}( enum target, enum pname, T param ); |
| void TexParameter{if}v( enum target, enum pname, T params ); |
| void TexParameterIivEXT( enum target, enum pname, int *params ); |
| void TexParameterIuivEXT( enum target, enum pname, uint *params ); |
| |
| <target> is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, |
| or TEXTURE_CUBE_MAP. <pname> is a symbolic constant indicating the |
| parameter to be set; the possible constants and corresponding |
| parameters are summarized in table 3.19. In the first form of the |
| command, <param> is a value to which to set a single-valued |
| parameter; in the second and third forms of the command, <params> |
| is an array of parameters whose type depends on the parameter |
| being set. |
| |
| If the value for TEXTURE_PRIORITY is specified as an integer, the |
| conversion for signed integers from table 2.9 is applied to |
| convert the value to floating-point. The floating point value of |
| TEXTURE_PRIORITY is clamped to lie in [0, 1]. |
| |
| If the values for TEXTURE_BORDER_COLOR are specified with |
| TexParameterIivEXT or TexParameterIuivEXT, the values are |
| unmodified and stored with an internal data type of integer. If |
| specified with TexParameteriv, the conversion for signed integers |
| from table 2.9 is applied to convert these values to |
| floating-point. Otherwise the values are unmodified and stored as |
| floating-point. |
| |
| |
| |
| (modify table 3.19, p. 167) |
| Name Type Legal Values |
| ---- ---- ------------ |
| TEXTURE_BORDER_COLOR 4 floats or any 4 values |
| 4 ints or |
| 4 uints |
| |
| Table 3.19: Texture parameters and their values. |
| |
| Modify Section 3.8.8 (Texture Minification), p. 170 |
| |
| (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 internal data type of the border values must be consistent |
| with the type returned by the texture as described in section 3.8, |
| or the result is undefined. 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 components, |
| the first component of TEXTURE_BORDER_COLOR is interpreted as a |
| depth value |
| |
| Modify Section 3.8.10 (Texture Completeness), p. 177: |
| |
| (add to the requirements for one-, two-, or three-dimensional |
| textures) |
| If the internalformat is integer, TEXTURE_MAG_FILTER must be |
| NEAREST and TEXTURE_MIN_FILTER must be NEAREST or |
| NEAREST_MIPMAP_NEAREST. |
| |
| Modify Section 3.11.2 (Shader Execution), p. 194 |
| |
| (modify Shader Outputs, first paragraph, p. 196) |
| ... These are gl_FragColor, gl_FragData[n], and gl_FragDepth. If |
| fragment clamping is enabled and the color buffer has a |
| fixed-point or floating-point format, the final fragment color |
| values or the final fragment data values written by a fragment |
| shader are clamped to the range [0, 1]. If fragment clamping is |
| disabled or the color buffer has an integer format, the final |
| fragment color values or the final fragment data values are not |
| modified. The final fragment depth... |
| |
| (insert between the first paragraph and second paragraphs of |
| "Shader Outputs", p. 196) |
| Colors values written by the fragment shader may be floating- |
| point, signed integer or unsigned integer. If the color buffer |
| has a fixed-point format, the color values are assumed to be |
| floating-point and are converted to fixed-point as described in |
| section 2.14.9; otherwise no type conversion is applied. If the |
| values written by the fragment shader do not match the format(s) |
| of the corresponding color buffer(s), the result is undefined. |
| |
| |
| 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 unsigned integer color indices, R, G, B |
| and optionally A floating-point components represented as |
| fixed-point unsigned integer or floating-point values, or R, G, B |
| and optionally A integer components represented as signed or |
| unsigned integer values. The number of bitplanes... |
| |
| Modify Section 4.1.3 (Multisample Fragment Operations), p. 200 |
| |
| (modify the second paragraph in this section) |
| ... If SAMPLE_ALPHA_TO_COVERAGE is enabled and the color buffer |
| has a fixed-point or floating-point format, a temporary coverage |
| value is generated ... |
| |
| Modify Section 4.1.4 (Alpha Test), p. 201 |
| |
| (modify the first paragraph in this section) |
| This step applies only in RGBA mode and only if the color buffer |
| has a fixed-point or floating-point format. In color index mode or |
| if the color buffer has an integer format, proceed to the next |
| operation. The alpha test discards ... |
| |
| Modify Section 4.1.8 (Blending), p. 205 |
| |
| (modify the second paragraph, p. 206) |
| ... 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 if the color buffer has a |
| fixed-point or floating-point format; in color index mode or if |
| the color buffer has an integer format, it is bypassed. ... |
| |
| Modify Section 4.2.3 (Clearing the Buffers), p. 215 |
| |
| void ClearColor(float r, float g, float b, float a); |
| |
| sets the clear value for fixed-point and floating-point color |
| buffers in RGBA mode. The specified components are stored as |
| floating-point values. |
| |
| void ClearColorIiEXT(int r, int g, int b, int a); |
| void ClearColorIuiEXT(uint r, uint g, uint b, uint a); |
| |
| set the clear value for signed integer and unsigned integer color |
| buffers, respectively, in RGBA mode. The specified components are |
| stored as integer values. |
| |
| (add to the end of first partial paragraph, p. 217) ... then a |
| Clear directed at that buffer has no effect. When fixed-point |
| RGBA color buffers are cleared, the clear color values are assumed |
| to be floating-point and are clamped to [0,1] before being |
| converted to fixed-point according to the rules of section 2.14.9. |
| The result of clearing fixed-point or floating-point color buffers |
| is undefined if the clear color was specified as integer values. |
| The result of when clearing integer color buffers is undefined if |
| the clear color was specified as floating-point values. |
| |
| Modify Section 4.3.2 (Reading Pixels), p. 219 |
| |
| (append to the last paragraph, p. 221) |
| The error INVALID_OPERATION occurs if <format> is an integer |
| format and the color buffer is not an integer format, or if the |
| color buffer is an integer format and <format> is not. The error |
| INVALID_ENUM occurs if <format> is an integer format and <type> is |
| FLOAT. |
| |
| (modify the first paragraph, 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 an integer or floating-point color |
| buffer, the elements are unmodified. |
| |
| (modify the section labeled "Conversion to L", p. 222) |
| This step applies only to RGBA component groups. If the format is |
| either LUMINANCE or LUMINANCE_ALPHA, a value L is computed as |
| |
| L = R + G + B |
| |
| otherwise if the format is either LUMINANCE_INTEGER_EXT or |
| LUMINANCE_ALPHA_INTEGER_EXT, L is computed as |
| |
| L = R |
| |
| where R, G, and B are the values of the R, G, and B |
| components. The single computed L component replaces the R, G, and |
| B components in the group. |
| |
| (modify the section labeled "Final Conversion", p. 222) |
| |
| For a floating-point RGBA color, each component is first clamped |
| to [0, 1]. Then the appropriate conversion formula from table 4.7 |
| is applied to the component. For an integer RGBA color, each |
| component is clamped to the representable range of <type>. |
| |
| |
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and |
| State Requests) |
| |
| Modify Section 6.1.3 (Enumerated Queries), p. 246 |
| |
| (insert in the list of query functions, p. 246) |
| void GetTexParameterIivEXT( enum target, enum value, int *data ); |
| void GetTexParameterIuivEXT( enum target, enum value, uint *data ); |
| |
| (modify the second paragraph, p. 247) |
| ... For GetTexParameter, value must be either TEXTURE_RESIDENT, or |
| one of the symbolic values in table 3.19. Querying <value> |
| TEXTURE_BORDER_COLOR with GetTexParameterIivEXT or |
| GetTexParameterIuivEXT returns the border color values as signed |
| integers or unsigned integers, respectively; otherwise the values |
| are returned as described in section 6.1.2. If the border color |
| is queried with a type that does not match the original type with |
| which it was specified, the result is undefined. The <lod> |
| argument ... |
| |
| (add to end of third paragraph, p. 247) Queries with a <value> of |
| TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, |
| TEXTURE_ALPHA_TYPE_ARB, TEXTURE_LUMINANCE_TYPE_ARB, |
| TEXTURE_INTENSITY_TYPE_ARB, or TEXTURE_DEPTH_TYPE_ARB, return the data |
| type used to store the component. Values of NONE, |
| UNSIGNED_NORMALIZED_ARB, FLOAT, INT, or UNSIGNED_INT, indicate missing, |
| unsigned normalized integer, floating-point, signed unnormalized integer, |
| and unsigned unnormalized integer components, respectively. |
| |
| |
| GLX Protocol |
| |
| The following rendering commands are sent to the server as part of |
| a glXRender request: |
| |
| ClearColorIiEXT |
| |
| 2 20 rendering command length |
| 2 4292 rendering command opcode |
| 4 INT32 r |
| 4 INT32 g |
| 4 INT32 b |
| 4 INT32 a |
| |
| ClearColorIuiEXT |
| |
| 2 20 rendering command length |
| 2 4293 rendering command opcode |
| 4 CARD32 r |
| 4 CARD32 g |
| 4 CARD32 b |
| 4 CARD32 a |
| |
| TexParameterIivEXT |
| |
| 2 12+(4*n) rendering command length |
| 2 346 rendering command opcode |
| 4 ENUM target |
| 4 ENUM pname |
| 0x2802 n=1 GL_TEXTURE_WRAP_S |
| 0x2803 n=1 GL_TEXTURE_WRAP_T |
| 0x8072 n=1 GL_TEXTURE_WRAP_R |
| 0x2801 n=1 GL_TEXTURE_MIN_FILTER |
| 0x2800 n=1 GL_TEXTURE_MAG_FILTER |
| 0x8066 n=1 GL_TEXTURE_PRIORITY |
| 0x813A n=1 GL_TEXTURE_MIN_LOD |
| 0x813B n=1 GL_TEXTURE_MAX_LOD |
| 0x813C n=1 GL_TEXTURE_BASE_LEVEL |
| 0x813D n=1 GL_TEXTURE_MAX_LEVEL |
| 0x8501 n=1 GL_TEXTURE_LOD_BIAS |
| 0x884B n=1 GL_DEPTH_TEXTURE_MODE |
| 0x884C n=1 GL_TEXTURE_COMPARE_MODE |
| 0x884D n=1 GL_TEXTURE_COMPARE_FUNC |
| 0x8191 n=1 GL_GENERATE_MIPMAP |
| 0x1004 n=4 GL_TEXTURE_BORDER_COLOR |
| 4*n LISTofINT32 params |
| |
| TexParameterIuivEXT |
| |
| 2 12+(4*n) rendering command length |
| 2 347 rendering command opcode |
| 4 ENUM target |
| 4 ENUM pname |
| 0x2802 n=1 GL_TEXTURE_WRAP_S |
| 0x2803 n=1 GL_TEXTURE_WRAP_T |
| 0x8072 n=1 GL_TEXTURE_WRAP_R |
| 0x2801 n=1 GL_TEXTURE_MIN_FILTER |
| 0x2800 n=1 GL_TEXTURE_MAG_FILTER |
| 0x8066 n=1 GL_TEXTURE_PRIORITY |
| 0x813A n=1 GL_TEXTURE_MIN_LOD |
| 0x813B n=1 GL_TEXTURE_MAX_LOD |
| 0x813C n=1 GL_TEXTURE_BASE_LEVEL |
| 0x813D n=1 GL_TEXTURE_MAX_LEVEL |
| 0x8501 n=1 GL_TEXTURE_LOD_BIAS |
| 0x884B n=1 GL_DEPTH_TEXTURE_MODE |
| 0x884C n=1 GL_TEXTURE_COMPARE_MODE |
| 0x884D n=1 GL_TEXTURE_COMPARE_FUNC |
| 0x8191 n=1 GL_GENERATE_MIPMAP |
| 0x1004 n=4 GL_TEXTURE_BORDER_COLOR |
| 4*n LISTofCARD32 params |
| |
| The following new non-rendering commands are added: |
| |
| GetTexParameterIivEXT |
| |
| 1 CARD8 opcode(X assigned) |
| 1 203 GLX opcode |
| 2 4 request length |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 INT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofINT32 params |
| |
| GetTexParameterIuivEXT |
| |
| 1 CARD8 opcode(X assigned) |
| 1 204 GLX opcode |
| 2 4 request length |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 CARD32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofCARD32 params |
| |
| Dependencies on ARB_texture_float |
| |
| The following changes should be made if ARB_texture_float is not |
| supported: |
| |
| The references to floating-point data types in section 3.8, p. 150 |
| should be deleted. |
| |
| The language in section 3.8.1 should indicate that final |
| conversion always clamps when the internalformat is not integer. |
| |
| The description of table 3.16 should not mention the <f> |
| floating-point formats. |
| |
| Section 3.8.4 should indicate that border color values should be |
| clamped to [0,1] before being stored, if not specified with one of |
| the TexParameterI* functions. |
| |
| Section 3.8.8 should not mention clamping border color values to |
| [0,1] for fixed-point textures, since this occurs in 3.8.4 at |
| TexParameter specification. |
| |
| Dependencies on ARB_color_buffer_float |
| |
| The following changes should be made if ARB_color_buffer_float is |
| not supported: |
| |
| Section 3.11.2, subsection "Shader Outputs: p. 196 should not |
| mention fragment clamping or color buffers with floating-point |
| formats. |
| |
| Chapter 4, p. 198 should not mention components represented as |
| floating-point values. |
| |
| Section 4.1.3, p. 200, section 4.1.4 p. 205, section 4.1.8 p. 206, |
| section 4.2.3 p. 215 and section 4.3.2 p. 222 should not mention |
| color buffers with a floating-point format. |
| |
| Section 4.2.3 p. 217 should not mention clamping the clear color |
| values to [0,1]. |
| |
| Errors |
| |
| INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap, |
| CopyPixels, or a command that performs an explicit Begin if the |
| color buffer has an integer RGBA format and no fragment shader is |
| active. |
| |
| INVALID_ENUM is generated by DrawPixels, TexImage* and |
| SubTexImage* if <format> is one of the integer component formats |
| described in table 3.6 and <type> is FLOAT. |
| |
| INVALID_OPERATION is generated by TexImage* and SubTexImage* if |
| the texture internalformat is an integer format as described in |
| table 3.16 and <format> is not one of the integer component |
| formats described in table 3.6, or if the internalformat is not an |
| integer format and <format> is an integer format. |
| |
| INVALID_OPERATION is generated by CopyTexImage* and |
| CopyTexSubImage* if the texture internalformat is an integer |
| format and the read color buffer is not an integer format, or if |
| the internalformat is not an integer format and the read color |
| buffer is an integer format. |
| |
| INVALID_ENUM is generated by ReadPixels if <format> is an integer |
| format and <type> is FLOAT. |
| |
| INVALID_OPERATON is generated by ReadPixels if <format> is an |
| integer format and the color buffer is not an integer format, or |
| if <format> is not an integer format and the color buffer is an |
| integer format. |
| |
| New State |
| |
| (modify table 6.33, p. 294) |
| |
| Minimum |
| Get Value Type Get Command Value Description Sec. Attribute |
| ------------------------ ---- ----------- ------- ---------------- ---- ---------- |
| RGBA_INTEGER_MODE_EXT B GetBooleanv - True if RGBA 2.7 - |
| components are |
| integers |
| |
| Issues |
| |
| How should the integer pixel path be triggered: by the destination |
| type, new source types, or new source formats? |
| |
| RESOLVED: New source formats, based on the precedence of |
| COLOR_INDEX and STENCIL_INDEX formats which invoke distinct |
| pixel path behavior with identical data types and independent |
| of the destination. |
| |
| Should pixel transfer operations be defined for the integer pixel |
| path? |
| |
| RESOLVED: No. Fragment shaders can achieve similar results |
| with more flexibility. There is no need to aggrandize this |
| legacy mechanism. |
| |
| What happens if a shader reads a float texel from an integer |
| texture or vice-versa? |
| |
| RESOLVED: The result is undefined. The shader must have |
| knowledge of the texture internal data type. |
| |
| How do integer textures behave in fixed function fragment |
| processing? |
| |
| RESOLVED: The fixed function texture pipeline assumes textures |
| return floating-point values, hence the return value from an |
| integer texture will not be in a meaningful format. |
| |
| How does TEXTURE_BORDER_COLOR work with integer textures? |
| |
| RESOLVED: The internal storage of border values effectively |
| becomes a union, and the returned values are interpreted as |
| the same type as the texture. New versions of TexParameter |
| allow specification of signed and unsigned integer border |
| values. |
| |
| How does logic op behave with RGBA mode rendering into integer |
| color buffer? |
| |
| RESOLVED: The color logic op operates when enabled when |
| rendering into integer color buffers. |
| |
| Logic op operations make sense for integer color buffers so the |
| COLOR_LOGIC_OP enable is respected when rendering into integer |
| color buffers. |
| |
| Blending does not apply to RGBA mode rendering when rendering |
| into integer color buffers (as section 4.1.8 is updated to say). |
| The color logic op (described in section 4.1.10) is not a blending |
| operation (though it does take priority over the blending enable). |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- ----------------------------------------- |
| 6 05/20/10 srahman Add GLX protocol. |
| |
| 5 07/15/07 pbrown Fix typo in GetTexParameterIuivEXT function |
| name in "New Procedures and Functions". |
| |
| 4 -- Pre-release revisions. |
| |