blob: 8ba9edf340d0a35608d3865f06de85ddebe5eb68 [file] [log] [blame]
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.