| 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. | |