EXT_texture_array
GL_EXT_texture_array
Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
Shipping for GeForce 8 Series (November 2006, Release 95)
Last Modified Date: 02/04/2008
Author revision: 6
329
This extension is written against the OpenGL 2.0 specification and version
1.10.59 of the OpenGL Shading Language specification.
This extension is interacts with EXT_framebuffer_object.
This extension interacts with NV_geometry_program4.
This extension interacts with NV_gpu_program4 or the OpenGL Shading
Language, which provide the mechanisms necessary to access array textures.
This extension interacts with EXT_texture_compression_s3tc and
NV_texture_compression_vtc.
This extension introduces the notion of one- and two-dimensional array
textures. An array texture is a collection of one- and two-dimensional
images of identical size and format, arranged in layers. A
one-dimensional array texture is specified using TexImage2D; a
two-dimensional array texture is specified using TexImage3D. The height
(1D array) or depth (2D array) specify the number of layers in the image.
An array texture is accessed as a single unit in a programmable shader,
using a single coordinate vector. A single layer is selected, and that
layer is then accessed as though it were a one- or two-dimensional
texture. The layer used is specified using the "t" or "r" texture
coordinate for 1D and 2D array textures, respectively. The layer
coordinate is provided as an unnormalized floating-point value in the
range [0,<n>-1], where <n> is the number of layers in the array texture.
Texture lookups do not filter between layers, though such filtering can be
achieved using programmable shaders. When mipmapping is used, each level
of an array texture has the same number of layers as the base level; the
number of layers is not reduced as the image size decreases.
Array textures can be rendered to by binding them to a framebuffer object
(EXT_framebuffer_object). A single layer of an array texture can be bound
using normal framebuffer object mechanisms, or an entire array texture can
be bound and rendered to using the layered rendering mechanisms provided
by NV_geometry_program4.
This extension does not provide for the use of array textures with
fixed-function fragment processing. Such support could be added by
providing an additional extension allowing applications to pass the new
target enumerants (TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT) to
Enable and Disable.
   New Procedures and Functions |
void FramebufferTextureLayerEXT(enum target, enum attachment,
uint texture, int level, int layer);
Accepted by the <target> parameter of TexParameteri, TexParameteriv,
TexParameterf, TexParameterfv, and BindTexture:
TEXTURE_1D_ARRAY_EXT 0x8C18
TEXTURE_2D_ARRAY_EXT 0x8C1A
Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
CopyTexSubImage3D, CompressedTexImage3D, and CompressedTexSubImage3D:
TEXTURE_2D_ARRAY_EXT
PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B
Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D, and
CompressedTexSubImage2D:
TEXTURE_1D_ARRAY_EXT
PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19
Accepted by the <pname> parameter of GetBooleanv, GetDoublev, GetIntegerv
and GetFloatv:
TEXTURE_BINDING_1D_ARRAY_EXT 0x8C1C
TEXTURE_BINDING_2D_ARRAY_EXT 0x8C1D
MAX_ARRAY_TEXTURE_LAYERS_EXT 0x88FF
Accepted by the <param> parameter of TexParameterf, TexParameteri,
TexParameterfv, and TexParameteriv when the <pname> parameter is
TEXTURE_COMPARE_MODE_ARB:
COMPARE_REF_DEPTH_TO_TEXTURE_EXT 0x884E
(Note: COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
reflects the fact that the R coordinate is not always used.)
Accepted by the <internalformat> parameter of TexImage3D and
CompressedTexImage3D, and by the <format> parameter of
CompressedTexSubImage3D:
COMPRESSED_RGB_S3TC_DXT1_EXT
COMPRESSED_RGBA_S3TC_DXT1_EXT
COMPRESSED_RGBA_S3TC_DXT3_EXT
COMPRESSED_RGBA_S3TC_DXT5_EXT
Accepted by the <pname> parameter of
GetFramebufferAttachmentParameterivEXT:
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4
(Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
EXT_framebuffer_object. This extension generalizes the notion of
"<zoffset>" to include layers of an array texture.)
Returned by the <type> parameter of GetActiveUniform:
SAMPLER_1D_ARRAY_EXT 0x8DC0
SAMPLER_2D_ARRAY_EXT 0x8DC1
SAMPLER_1D_ARRAY_SHADOW_EXT 0x8DC3
SAMPLER_2D_ARRAY_SHADOW_EXT 0x8DC4
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) |
Modify section 2.15.3, "Shader Variables", page 75
Add the following new return types to the description of GetActiveUniform
on p. 81.
SAMPLER_1D_ARRAY_EXT,
SAMPLER_2D_ARRAY_EXT,
SAMPLER_1D_ARRAY_SHADOW_EXT,
SAMPLER_2D_ARRAY_SHADOW_EXT
Modify Section 2.15.4, Shader Execution (p. 84)
(modify first paragraph, p. 86 -- two simple edits:
(1) Change reference to the "r" coordinate to simply indicate that the
reference value for shadow mapping is provided in the lookup
function. It's still usually in the "r" coordinate, except for
two-dimensional array textures, where it's in "q".
(2) Add new EXT_gpu_shader4 sampler types used for array textures. )
Texture lookups involving textures with depth component data can either
return the depth data directly or return the results of a comparison with
a reference depth value specified in the coordinates passed to the texture
lookup function, as described in section 3.8.14. The comparison operation
is requested in the shader by using the shadow sampler types
(sampler1DShadow, sampler2DShadow, sampler1DArrayShadow, or
sampler2DArrayShadow) and in the texture using the TEXTURE_COMPARE_MODE
parameter. ...
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
Modify Section 3.8, Texturing (p. 149).
(add new paragraph at the top of p. 150) Six types of texture are
supported; each is a collection of images built from one-, two-, or
three-dimensional array of image elements referred to as texels. One-,
two-, and three-dimensional textures consist of a one-, two-, or
three-dimensional texel arrays. One- and two-dimensional array textures
are arrays of one- or two-dimensional images, consisting of one or more
layers. Finally, a cube map is a special two-dimensional array texture
with six layers that represent the faces of a cube. When accessing a cube
map, the texture coordinates are projected onto one of the six faces.
Modify Section 3.8.1, Texture Image Specification (p. 150).
(modify first paragraph of section, p. 150) The command
void TexImage3D( enum target, int level, int internalformat,
sizei width, sizei height, sizei depth, int border,
enum format, enum type, void *data );
is used to specify a three-dimensional texture image. target must be one
of TEXTURE_3D for a three-dimensional texture or TEXTURE_2D_ARRAY_EXT for
an two-dimensional array texture. Additionally, target may be either
PROXY_TEXTURE_3D for a three-dimensional proxy texture, or
PROXY_TEXTURE_2D_ARRAY_EXT for a two-dimensional proxy array texture. ...
(modify the fourth paragraph on p. 151) Textures with a base internal
format of DEPTH_COMPONENT are supported by texture image specification
commands only if target is TEXTURE_1D, TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
TEXTURE_2D_ARRAY_EXT, PROXY_TEXTURE_1D, PROXY_TEXTURE_2D,
PROXY_TEXTURE_1D_ARRAY_EXT, or PROXY_TEXTURE_2D_ARRAY_EXT. Using this
format in conjunction with any other target will result in an INVALID
OPERATION error.
(modify the first paragraph on p. 153 -- In particular, add new terms w_b,
h_b, and d_b to represent border width, height, or depth, instead of a
single border size term b_s. Subsequent equations referring to b_s should
be modified to refer to w_b, h_b, and d_b, as appropriate.)
... Counting from zero, each resulting Nth texel is assigned internal
integer coordinates (i, j, k), where
i = (N mod width) - w_b
j = (floor(N/width) mod height) - h_b
k = (floor(N/(width*height)) mod depth) - d_b
and w_b, h_b, and d_b are the specified border width, height, and depth.
w_b and h_b are the specified <border> value; d_b is the specified
<border> value if <target> is TEXTURE_3D or zero if <target> is
TEXTURE_2D_ARRAY_EXT. ...
(modify equations 3.15-3.17 and third paragraph of p. 155)
w_s = w_t + 2 * w_b (3.15)
h_s = h_t + 2 * h_b (3.16)
d_s = d_t + 2 * d_b (3.17)
... If <border> is less than zero, or greater than b_t, then the error
INVALID_VALUE is generated.
(modify the last paragraph on p. 155 on to p. 156)
The maximum allowable width, height, or depth of a texel array for a
three-dimensional texture is an implementation dependent function of the
level-of-detail and internal format of the resulting image array. It must
be at least 2^(k-lod) + 2 * b_t for image arrays of level-of-detail 0
through k, where k is the log base 2 of MAX_3D_TEXTURE_SIZE, lod is the
level-of-detail of the image array, and b_t is the maximum border width.
It may be zero for image arrays of any level-of-detail greater than k. The
error INVALID VALUE is generated if the specified image is too large to be
stored under any conditions.
In a similar fashion, the maximum allowable width of a texel array for a
one- or two-dimensional, or one- or two-dimensional array texture, and the
maximum allowable height of a two-dimensional or two-dimensional array
texture, must be at least 2^(k-lod) + 2 * b_t for image arrays of level 0
through k, where k is the log base 2 of MAX_TEXTURE_SIZE. The maximum
allowable width and height of a cube map texture must be the same, and
must be at least 2^(k-lod) + 2 * b_t for image arrays level 0 through k,
where k is the log base 2 of MAX_CUBE_MAP_TEXTURE_SIZE. The maximum
number of layers for one- and two-dimensional array textures (height or
depth, respectively) must be at least MAX_ARRAY_TEXTURE_LAYERS_EXT for all
levels.
(modify the fourth paragraph on p. 156) The command
void TexImage2D( enum target, int level,
int internalformat, sizei width, sizei height,
int border, enum format, enum type, void *data );
is used to specify a two-dimensional texture image. target must be one of
TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally, target
may be either PROXY_TEXTURE_2D for a two-dimensional proxy texture,
PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array texture, or
PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the special case
discussed in section 3.8.11. The other parameters match the corresponding
parameters of TexImage3D.
For the purposes of decoding the texture image, TexImage2D is equivalent
to calling TexImage3D with corresponding arguments and depth of 1, except
that
* The border depth, d_b, is zero, and the depth of the image is always 1
regardless of the value of border.
* The border height, h_b, is zero if <target> is TEXTURE_1D_ARRAY_EXT,
and <border> otherwise.
* Convolution will be performed on the image (possibly changing its width
and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
* UNPACK SKIP IMAGES is ignored.
(modify the fourth paragraph on p. 157) For the purposes of decoding the
texture image, TexImage1D is equivalent to calling TexImage2D with
corresponding arguments and height of 1, except that
* The border height and depth (h_b and d_b) are always zero, regardless
of the value of <border>.
* Convolution will be performed on the image (possibly changing its
width) only if CONVOLUTION 1D is enabled.
(modify the last paragraph on p. 157 and the first paragraph of p. 158 --
changing the phrase "texture array" to "texel array" to avoid confusion
with array textures. All subsequent references to "texture array" in the
specification should also be changed to "texel array".)
We shall refer to the (possibly border augmented) decoded image as the
texel array. A three-dimensional texel array has width, height, and depth
ws, hs, and ds as defined respectively in equations 3.15, 3.16, and
3.17. A two-dimensional texel array has depth ds = 1, with height hs and
width ws as above, and a one-dimensional texel array has depth ds = 1,
height hs = 1, and width ws as above.
An element (i,j,k) of the texel array is called a texel (for a
two-dimensional texture or one-dimensional array texture, k is irrelevant;
for a one-dimensional texture, j and k are both irrelevant). The texture
value used in texturing a fragment is determined by that fragment’s
associated (s,t,r) coordinates, but may not correspond to any actual
texel. See figure 3.10.
Modify Section 3.8.2, Alternate Texture Image Specification Commands
(p. 159)
(modify second paragraph, p. 159 -- allow 1D array textures) The command
void CopyTexImage2D( enum target, int level,
enum internalformat, int x, int y, sizei width,
sizei height, int border );
defines a two-dimensional texture image in exactly the manner of
TexImage2D, except that the image data are taken from the framebuffer
rather than from client memory. Currently, target must be one of
TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
TEXTURE_CUBE_MAP_NEGATIVE_Z.
(modify last paragraph, p. 160) ... Currently the target arguments of
TexSubImage1D and CopyTexSubImage1D must be TEXTURE_1D, the target
arguments of TexSubImage2D and CopyTexSubImage2D must be one of
TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
TEXTURE_CUBE_MAP_NEGATIVE_Z, and the target arguments of TexSubImage3D and
CopyTexSubImage3D must be TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ...
(modify last paragraph, p. 161 and subsequent inequalities)
Negative values of xoffset, yoffset, and zoffset correspond to the
coordinates of border texels, addressed as in figure 3.10. Taking w_s,
h_s, d_s, w_b, h_b, and d_b to be the specified width, height, depth, and
border width, height, and depth of the texture array, and taking x, y, z,
w, h, and d to be the xoffset, yoffset, zoffset, width, height, and depth
argument values, any of the following relationships generates the error
INVALID VALUE:
x < -w_b
x + w > w_s - w_b
y < -h_b
y + h > h_s - h_b
z < -d_b
z + d > d_s - d_b
Modify Section 3.8.4, Texture Parameters (p. 166)
(modify first paragraph of section, p. 166) Various parameters control how
the texel 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 );
target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT.
Modify Section 3.8.8, Texture Minification (p. 170)
(modify first paragraph, p. 172) ... For a one-dimensional or
one-dimensional array texture, define v(x, y) == 0 and w(x, y) == 0; for a
two-dimensional, two-dimensional array, or cube map texture, define w(x,
y) == 0. ...
(modify second paragraph, p. 173) For one-dimensional or one-dimensional
array textures, j and k are irrelevant; the texel at location i becomes
the texture value. For two-dimensional, two-dimensional array, or cube map
textures, k is irrelevant; the texel at location (i, j) becomes the
texture value. For one- and two-dimensional array textures, the texel is
obtained from image layer l, where
l = clamp(floor(t + 0.5), 0, h_t-1), for one-dimensional array textures,
clamp(floor(r + 0.5), 0, d_t-1), for two-dimensional array textures.
(modify third paragraph, p. 174) For a two-dimensional, two-dimensional
array, or cube map texture,
tau = ...
where tau_ij is the texel at location (i, j) in the two-dimensional
texture image. For two-dimensional array textures, all texels are
obtained from layer l, where
l = clamp(floor(r + 0.5), 0, d_t-1).
And for a one-dimensional or one-dimensional array texture,
tau = ...
where tau_i is the texel at location i in the one-dimensional texture.
For one-dimensional array textures, both texels are obtained from layer l,
where
l = clamp(floor(t + 0.5), 0, h_t-1).
(modify first two paragraphs of "Mipmapping", p. 175) TEXTURE_MIN_FILTER
values NEAREST_MIPMAP_NEAREST, NEAREST_MIPMAP_LINEAR,
LINEAR_MIPMAP_NEAREST, and LINEAR_MIPMAP_LINEAR each require the use of a
mipmap. A mipmap is an ordered set of arrays representing the same image;
each array has a resolution lower than the previous one.
If the image array of level level_base, excluding its border, has
dimensions, w_t × h_t × d_t, then there are floor(log2(maxsize)) + 1
levels in the mipmap, where
maxsize = w_t, for one-dimensional and one-dimensional
array textures,
max(w_t, h_t), for two-dimensional, two-dimensional
array, and cube map textures
max(w_t, h_t, d_t), for three dimensional textures.
Numbering the levels such that level level_base is the 0th level, the ith
array has dimensions
max(1, floor(w_t/w_d)) x max(1, floor(h_t/h_d)) x max(1, floor(d_t/d_d))
where
w_d = 2 ^ i;
h_d = 1, for one-dimensional array textures and
2 ^ i, otherwise; and
d_d = 1, for two-dimensional array textures and
2 ^ i, otherwise,
until the last array is reached with dimension 1 × 1 × 1.
Each array in a mipmap is defined using TexImage3D, TexImage2D,
CopyTexImage2D, TexImage1D, or CopyTexImage1D; the array being set is
indicated with the level-of-detail argument level. Level-of-detail numbers
proceed from level_base for the original texture array through p =
floor(log2(maxsize)) + level_base with each unit increase indicating an
array of half the dimensions of the previous one (rounded down to the next
integer if fractional) as already described. All arrays from level_base
through q = min{p, level_max} must be defined, as discussed in section
3.8.10.
(modify third paragraph in the "Mipmap Generation" section, p. 176)
The contents of the derived arrays are computed by repeated, filtered
reduction of the level_base array. For one- and two-dimensional array
textures, each layer is filtered independently. ...
Modify Section 3.8.10, Texture Completeness (p. 177)
(modify second paragaph of section, p. 177) For one-, two-, or
three-dimensional textures and one- or two-dimensional array textures, a
texture is complete if the following conditions all hold true: ...
Modify Section 3.8.11, Texture State and Proxy State (p. 178)
(modify second and third paragraphs, p. 179, adding array textures and
making minor wording changes)
In addition to image arrays for one-, two-, and three-dimensional
textures, one- and two-dimensional array textures, and the six image
arrays for the cube map texture, partially instantiated image arrays are
maintained for one-, two-, and three-dimensional textures and one- and
two-dimensional array textures. Additionally, a single proxy image array
is maintained for the cube map texture. Each proxy image array includes
width, height, depth, border width, and internal format state values, as
well as state for the red, green, blue, alpha, luminance, and intensity
component resolutions. Proxy image arrays do not include image data, nor
do they include texture properties. When TexImage3D is executed with
target specified as PROXY_TEXTURE_3D, the three-dimensional proxy state
values of the specified level-of-detail are recomputed and updated. If the
image array would not be supported by TexImage3D called with target set to
TEXTURE 3D, no error is generated, but the proxy width, height, depth,
border width, and component resolutions are set to zero. If the image
array would be supported by such a call to TexImage3D, the proxy state
values are set exactly as though the actual image array were being
specified. No pixel data are transferred or processed in either case.
Proxy arrays for one- and two-dimensional textures and one- and
two-dimensional array textures are operated on in the same way when
TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
specified as PROXY_TETXURE_2D_ARRAY_EXT.
Modify Section 3.8.12, Texture Objects (p. 180)
(update most of the beginning of the section to allow array textures)
In addition to the default textures TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT, named one-,
two-, and three-dimensional, cube map, and one- and two-dimensional array
texture objects can be created and operated upon. The name space for
texture objects is the unsigned integers, with zero reserved by the GL.
A texture object is created by binding an unused name to TEXTURE_1D,
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
void BindTexture( enum target, uint texture );
with <target> set to the desired texture target and <texture> set to the
unused name. The resulting texture object is a new state vector,
comprising all the state values listed in section 3.8.11, set to the same
initial values. If the new texture object is bound to TEXTURE_1D,
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-, three-dimensional,
cube map, one- or two-dimensional array texture respectively until it is
deleted.
BindTexture may also be used to bind an existing texture object to either
TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error INVALID_OPERATION
is generated if an attempt is made to bind a texture object of different
dimensionality than the specified target. If the bind is successful no
change is made to the state of the bound texture object, and any previous
binding to target is broken.
While a texture object is bound, GL operations on the target to which it
is bound affect the bound object, and queries of the target to which it is
bound return state from the bound object. If texture mapping of the
dimensionality of the target to which a texture object is bound is
enabled, the state of the bound texture object directs the texturing
operation.
In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
one-, two-, three-dimensional, cube map, and one- and two-dimensional
array texture state vectors respectively associated with them. In order
that access to these initial textures not be lost, they are treated as
texture objects all of whose names are 0. The initial one-, two-,
three-dimensional, cube map, one- and two-dimensional array textures are
therefore operated upon, queried, and applied as TEXTURE_1D, TEXTURE_2D,
TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
targets.
(modify second paragraph, p. 181) ... If a texture that is currently
bound to one of the targets TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is
deleted, it is as though BindTexture had been executed with the same
target and texture zero. ...
(modify second paragraph, p. 182) The texture object name space, including
the initial one-, two-, and three dimensional, cube map, and one- and
two-dimensional array texture objects, is shared among all texture
units. ...
Modify Section 3.8.14, Texture Comparison Modes (p. 185)
(modify second through fourth paragraphs, p. 188, reflecting that the
texture coordinate used for depth comparisons varies, including a new enum
name)
Let D_t be the depth texture value, in the range [0, 1]. For
fixed-function texture lookups, let R be the interpolated <r> texture
coordinate, clamped to the range [0, 1]. For texture lookups generated by
a program instruction, let R be the reference value for depth comparisons
provided in the instruction, also clamped to [0, 1]. Then the effective
texture value L_t, I_t, or A_t is computed as follows: ...
If the value of TEXTURE_COMPARE_MODE is NONE, then
r = Dt
If the value of TEXTURE_COMPARE_MODE is COMPARE_REF_DEPTH_TO_TEXTURE_EXT),
then r depends on the texture comparison function as shown in table 3.27.
Modify Section 3.11.2, Shader Execution (p. 194)
(modify second paragraph, p. 195 -- two simple edits:
(1) Change reference to the "r" coordinate to simply indicate that the
reference value for shadow mapping is provided in the lookup
function. It's still usually in the "r" coordinate, except for
two-dimensional array textures, where it's in "q".
(2) Add new EXT_gpu_shader4 sampler types used for array textures. )
Texture lookups involving textures with depth component data can either
return the depth data directly or return the results of a comparison with
a reference depth value specified in the coordinates passed to the texture
lookup function. The comparison operation is requested in the shader by
using the shadow sampler types (sampler1DShadow, sampler2DShadow,
sampler1DArrayShadow, and sampler2DArrayShadow) and in the texture using
the TEXTURE COMPARE MODE parameter. ...
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations and the Frame Buffer) |
None.
| Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) |
Modify Section 5.4, Display Lists (p. 237)
(modify first paragraph, p. 242) TexImage3D, TexImage2D, TexImage1D,
Histogram, and ColorTable are executed immediately when called with the
corresponding proxy arguments PROXY_TEXTURE_3D or
PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D, PROXY_TEXTURE_CUBE_MAP, or
PROXY_TEXTURE_1D_ARRAY_EXT; PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and
PROXY_COLOR_TABLE, PROXY_POST_CONVOLUTION_COLOR_TABLE, or
PROXY_POST_COLOR_MATRIX_COLOR_TABLE.
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests) |
Modify Section 6.1.3, Enumerated Queries (p. 246)
(modify second paragraph, p. 247)
GetTexParameter parameter <target> may be one of TEXTURE_1D, TEXTURE_2D,
TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
TEXTURE_2D_ARRAY_EXT, indicating the currently bound one-, two-,
three-dimensional, cube map, or one- or two-dimensional array texture.
GetTexLevelParameter parameter target may be one of TEXTURE_1D,
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP_POSITIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z,
TEXTURE_CUBE_MAP_NEGATIVE_Z, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_3D,
PROXY_TEXTURE_CUBE_MAP, PROXY_TEXTURE_1D_ARRAY, or PROXY_TEXTURE_2D_ARRAY,
indicating the one-, two-, or three-dimensional texture, one of the six
distinct 2D images making up the cube map texture, the one- or
two-dimensional array texture, or the one-, two-, three-dimensional, cube
map, or one- or two-dimensional array proxy state vector. ...
Modify Section 6.1.4, Texture Queries (p. 248)
(modify first three paragraphs of section, p. 248) The command
void GetTexImage( enum tex, int lod, enum format,
enum type, void *img );
is used to obtain texture images. It is somewhat different from the other
get commands; tex is a symbolic value indicating which texture (or texture
face in the case of a cube map texture target name) is to be obtained.
TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT, and
TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional texture,
or one- or two-dimensional array texture, respectively.
TEXTURE_CUBE_MAP_POSITIVE_X, ...
GetTexImage obtains... from the first image to the last for
three-dimensional textures. One- and two-dimensional array textures are
treated as two- and three-dimensional images, respectively, where the
layers are treated as rows or images. These groups are then...
For three-dimensional and two-dimensional array textures, pixel storage
operations are applied as if the image were two-dimensional, except that
the additional pixel storage state values PACK_IMAGE_HEIGHT and
PACK_SKIP_IMAGES are applied. ...
| Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) |
None.
| Additions to the AGL/GLX/WGL Specifications |
None.
None.
| Dependencies on EXT_framebuffer_object |
If EXT_framebuffer_object is supported, a single layer of an array texture
can be bound to a framebuffer attachment point, and manual mipmap
generation support is extended to include array textures.
Several modifications are made to the EXT_framebuffer_object
specification. First, the token identifying the attached layer of a 3D
texture, FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT, is renamed to
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT. This is done because this
extension generalizes the "z offset" concept to become notion of attaching
a layer of a multi-layer texture, which is applicable for both
three-dimensional and array textures. All references to this token in
EXT_framebuffer_object should be changed to the new token, and references
to "z offset" in the specification text should be replaced with "layer" as
appropriate. Additional edits follow.
(modify "Manual Mipmap Generation" in edits to Section 3.8.8)
Mipmaps can be generated manually with the command
void GenerateMipmapEXT(enum target);
where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY. Mipmap generation
affects the texture image attached to <target>. ...
(modify Section 4.4.2.3, Attaching Texture Images to a Framebuffer -- add
to the end of the section)
The command
void FramebufferTextureLayerEXT(enum target, enum attachment,
uint texture, int level, int layer);
operates identically to FramebufferTexture3DEXT, except that it attaches a
single layer of a three-dimensional texture or a one- or two-dimensional
array texture. <layer> is an integer indicating the layer number, and is
treated identically to the <zoffset> parameter in FramebufferTexture3DEXT.
The error INVALID_VALUE is generated if <layer> is negative. The error
INVALID_OPERATION is generated if <texture> is non-zero and is not the
name of a three dimensional texture or one- or two-dimensional array
texture. Unlike FramebufferTexture3D, no <textarget> parameter is
accepted.
If <texture> is non-zero and the command does not result in an error, the
framebuffer attachment state corresponding to <attachment> is updated as
in the other FramebufferTexture commands, except that
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>.
(modify Section 4.4.4.1, Framebuffer Attachment Completeness)
The framebuffer attachment point <attachment> is said to be "framebuffer
attachment complete" if ...:
...
* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or two-dimensional
array texture, then FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be
smaller than the number of layers in the texture.
(modify Section 6.1.3, Enumerated Queries)
...
If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the texture
object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
three-dimensional texture or a one- or two-dimensional array texture,
then <params> will contain the number of texture layer attached to the
attachment point. Otherwise, <params> will contain the value zero.
| Dependencies on NV_geometry_program4 |
NV_geometry_program4 provides additional modifications to
EXT_framebuffer_object to support layered rendering, which allows
applications to bind entire three-dimensional, cube map, or array textures
to a single attachment point, and select a layer to render to according to
a layer number written by the geometry program.
The framebuffer object modifications provided in NV_geometry_program4 are
more extensive than the more limited support provided for array textures.
The edits in this spec are a functional subset of the edits in
NV_geometry_program4. All of the modifications that this extension makes
to EXT_framebuffer_object are superseded by NV_geometry_program4, except
for the minor language changes made to GenerateMipmapsEXT().
| Dependencies on NV_gpu_program4 and the OpenGL Shading Language (GLSL) |
If NV_gpu_program4, EXT_gpu_shader4, and the OpenGL Shading Language
(GLSL) are not supported, and no other mechanism is provided to perform
texture lookups into array textures, this extension is pointless, given
that it provides no fixed-function mechanism to access texture arrays.
If GLSL is supported, the language below describes the modifications to
the shading language to support array textures. The extension
EXT_gpu_shader4 provides a broader set of shading language modifications
that include array texture lookup functions described here, plus a number
of additional functions.
If GLSL is not supported, the shading language below and references to the
SAMPLER_{1D,2D}_ARRAY_EXT and SAMPLER_{1D,2D}_ARRAY_SHADOW_EXT tokens
should be removed.
| Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc |
S3TC texture compression is supported for two-dimensional array textures.
When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
as a compressed two-dimensional textures. When specifying or querying
compressed images using one of the S3TC formats, the images are provided
and/or returned as a series of two-dimensional textures stored
consecutively in memory, with the layer closest to zero specified first.
For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
the three-dimensional compression format provided in the
EXT_texture_compression_vtc extension. Pixel store parameters, including
those specific to three-dimensional images, are ignored when compressed
image data are provided or returned, as in the
EXT_texture_compression_s3tc extension.
S3TC compression is not supported for one-dimensional texture targets in
EXT_texture_compression_s3tc, and is not supported for one-dimensional
array textures in this extension. If compressed one-dimensional arrays
are needed, use a two-dimensional texture with a height of one.
As with NV_texture_compression_vtc, this extension allows the use of the
four S3TC internal format types in TexImage3D, CompressedTexImage3D, and
CompressedTexSubImage3D calls. Unlike NV_texture_compression_vtc (for 3D
textures), compressed sub-image updates are allowed at arbitrary locations
along the Z axis. The language describing CompressedTexSubImage* APIs,
edited by EXT_texture_compression_s3tc (allowing updates at 4x4 boundaries
for 2D textures) and NV_texture_compression_vtc (allowing updates at 4x4x4
boundaries for 3D textures) is updated as follows:
"If the internal format of the texture image being modified is
COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the
texture is stored using one of several S3TC or VTC compressed texture
image formats. Since these algorithms support only 2D and 3D images,
CompressedTexSubImage1DARB produces an INVALID_ENUM error if <format> is
an S3TC/VTC format. Since S3TC/VTC images are easily edited along 4x4,
4x4x1, or 4x4x4 texel boundaries, the limitations on
CompressedTexSubImage2D and CompressedTexSubImage3D are relaxed.
CompressedTexSubImage2D and CompressedTexSubImage3D will result in an
INVALID_OPERATION error only if one of the following conditions occurs:
* <width> is not a multiple of four or equal to TEXTURE_WIDTH.
* <height> is not a multiple of four or equal to TEXTURE_HEIGHT.
* <xoffset> or <yoffset> is not a multiple of four.
* <depth> is not a multiple of four or equal to TEXTURE_DEPTH, and
<target> is TEXTURE_3D.
* <zoffset> is not a multiple of four and <target> is TEXTURE_3D."
(Note: The original version of this specification incorrectly failed to
allow compressed subimage updates of array textures via
CompressedTexSubImage3D, except at 4x4x4 boundaries/sizes. This
undesirable behavior was also implemented by all NVIDIA OpenGL drivers
published prior to February 2008.)
None. Some error conditions are removed, due to the ability to use the
new TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT enums.
(add to table 6.15, p. 276)
Initial
Get Value Type Get Command Value Description Sec. Attribute
---------------------------- ----- ----------- ----- -------------------- ------ ---------
TEXTURE_BINDING_1D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture
to TEXTURE_1D_ARRAY
TEXTURE_BINDING_2D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture
to TEXTURE_2D_ARRAY
| New Implementation Dependent State |
(add to Table 6.32, p. 293)
Minimum
Get Value Type Get Command Value Description Sec. Attribute
---------------------------- ---- ----------- ------- ------------------ ----- ---------
MAX_TEXTURE_ARRAY_LAYERS_EXT Z+ GetIntegerv 64 maximum number of 3.8.1 -
layers for texture
arrays
| Modifications to The OpenGL Shading Language Specification, Version 1.10.59 |
(This section describes additions to GLSL to allow shaders to access array
textures. This is a subset of the new shading language provided by the
EXT_gpu_shader4 extension, limited to array texture support. It is
provided here in case implementations choose to support EXT_texture_array
without supporting EXT_gpu_shader4 or equivalent functionality.
Note that if the EXT_gpu_shader4 extension is enabled in a shader via an
"#extension" line, there is no need to separately enable
EXT_texture_array.)
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_texture_array : <behavior>
where <behavior> is as specified in section 3.3.
A new preprocessor #define is added to the OpenGL Shading Language:
#define GL_EXT_texture_array 1
Add to section 3.6 "Keywords"
The following new sampler types are added:
sampler1DArray, sampler2DArray, sampler1DArrayShadow,
sampler2DArrayShadow
Add to section 4.1 "Basic Types"
Add the following entries to the type table:
sampler1DArray handle for accessing a 1D array texture
sampler2DArray handle for accessing a 2D array texture
sampler1DArrayShadow handle for accessing a 1D array depth texture
with comparison
sampler2DArrayShadow handle for accessing a 2D array depth texture
with comparison
Add to section 8.7 "Texture Lookup Functions"
Add new functions to the set of allowed texture lookup functions:
Syntax:
vec4 texture1DArray(sampler1DArray sampler, vec2 coord
[, float bias])
vec4 texture1DArrayLod(sampler1DArray sampler, vec2 coord,
float lod)
Description:
Use the first element (coord.s) of texture coordinate coord to do a
texture lookup in the layer indicated by the second coordinate coord.t of
the 1D texture array currently bound to sampler. The layer to access is
computed by layer = max (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is
the depth of the texture array.
Syntax:
vec4 texture2DArray(sampler2DArray sampler, vec3 coord
[, float bias])
vec4 texture2DArrayLod(sampler2DArray sampler, vec3 coord,
float lod)
Description:
Use the first two elements (coord.s, coord.t) of texture coordinate coord
to do a texture lookup in the layer indicated by the third coordinate
coord.p of the 2D texture array currently bound to sampler. The layer to
access is computed by layer = max (0, min(d - 1, floor (coord.p + 0.5))
where 'd' is the depth of the texture array.
Syntax:
vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord,
[float bias])
vec4 shadow1DArrayLod(sampler1DArrayShadow sampler,
vec3 coord, float lod)
Description:
Use texture coordinate coord.s to do a depth comparison lookup on an array
layer of the depth texture bound to sampler, as described in section
3.8.14 of version 2.0 of the OpenGL specification. The layer to access is
indicated by the second coordinate coord.t and is computed by layer = max
(0, min(d - 1, floor (coord.t + 0.5)) where 'd' is the depth of the
texture array. The third component of coord (coord.p) is used as the R
value. The texture bound to sampler must be a depth texture, or results
are undefined.
Syntax:
vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord)
Description:
Use texture coordinate (coord.s, coord.t) to do a depth comparison lookup
on an array layer of the depth texture bound to sampler, as described in
section 3.8.14 of version 2.0 of the OpenGL specification. The layer to
access is indicated by the third coordinate coord.p and is computed by
layer = max (0, min(d - 1, floor (coord.p + 0.5)) where 'd' is the depth
of the texture array. The fourth component of coord (coord.q) is used as
the R value. The texture bound to sampler must be a depth texture, or
results are undefined.
(1) Should this extension generalize the notion of 1D and 2D textures to
be arrays of 1D or 2D images, or simply introduce new targets?
RESOLVED: Introduce new targets.
It would have been possible to simply extend the notion of 1D and 2D
textures, and allow applications to pass TEXTURE_1D to TexImage2D (1D
arrays) or TEXTURE_2D to TexImage3D (2D arrays). This would have
avoided introducing a new set of texture targets (and proxy targets),
and a "default texture" (object zero) for each new target.
It is desirable to have a distinction between array and non-array
textures in programmable shaders, so compilers can generate code
appropriate to the texture type. For "normal" textures, a 2D texture
requires two component texture coordinates, while a 2D array texture
requires three. Without a distinction between array and non-array
textures, implementations must choose between compiling shaders to the
most general form (2D arrays) or recompiling shaders based on texture
usage. Texture lookups with shadow mapping, LOD bias, or per-pixel LOD
have additional complexity, and the interpretation of a coordinate
vector may need to depend on whether the texture was an array or
non-array texture.
It would be possible to limit the distinction between array and
non-array textures to the shaders, but it could then become the
responsibility of the application developer to ensure that a texture
with multiple layers is used when an "array lookup" is performed, and
that a single-layer texture is used when a "non-array lookup" is
performed. That begs the question of what the distinction between an
"array texture" and a "non-array texture" is. At least two possible
distinctions have been identified: one vs. multiple layers, or the API
call used to specify the texture (TexImage3D with TEXTURE_2D == array
texture, TexImage2D == non-array texture). The former does not allow
for the possibility of single-layer array textures; it may be the case
that application developers want to use a general shader supporting
array textures, but there may be cases where only a single layer might
be provided. The latter approach allows for single-layer array
textures, but the distinction is now based on the API call.
Adding separate targets eliminates the need for such a distinction.
"Array lookups" refer to the TEXTURE_1D_ARRAY_EXT or
TEXTURE_2D_ARRAY_EXT targets; "non-array lookups" refer to TEXTURE_1D or
TEXTURE_2D. There is never a case where the wrong kind of texture can
be used, as TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT textures are
always arrays by definition.
This distinction should also be helpful if and when fixed-function
fragment processing is supported; the enabled texture target is used to
generate an internal fragment shader using the proper "array lookup".
There would be no need to recompile shaders depending on whether an
enabled texture is an "array texture" or not.
(2) Should texture arrays be supported for fixed-function fragment
processing?
RESOLVED: No; it's not believed to be worth the effort. Fixed-function
fragment processing could be easily supported by allowing applications
to enable or disable TEXTURE_1D_ARRAY_EXT or TEXTURE_2D_ARRAY_EXT.
Note that for fixed-function fragment processing, there would be issues
with texture lookups of two-dimensional array textures with shadow
mapping. Given that all texture lookups are projective, a total of five
coordinate components would be required (s, t, layer, depth, q).
(3) If fixed-function were supported, should the layer number (T or R) be
divided by Q in projective texture lookups?
RESOLVED: It doesn't need to be resolved in this extension, but it
would be a problem. There are probably cases where an application would
want the divide (handle R more-or-less like S/T); there are probably
other cases where the divide would not be wanted. Many developers won't
care, and may not even know what the Q coordinate is used for! The
default of 1.0 allows applications that don't care about projective
lookups to simply ignore that fact.
For programmable fragment shading, an application can code it either way
and use non-projective lookups. To the extent that the divide by Q for
projective lookups is "free" or "cheap" on OpenGL hardware, compilers
may be able to recognize a projective pattern in the computed
coordinates and generate code appropriately.
(4) Should DEPTH_COMPONENT textures be supported for texture arrays?
RESOLVED: Yes; multi-layer shadow maps are useful.
(5) How should shadow mapping in texture arrays work with programmable
shaders, and fixed-function shaders (if ever supported)?
RESOLVED: The layer number is in the "next" coordinate following the
normal 1D or 2D coordinate. That's the "t" coordinate for 1D arrays and
the "r" coordinate for 2D arrays. For shadow maps, this is a problem,
as the "r" coordinate is generally used as the depth reference value.
This is resolved by instead taking the depth reference value from the
"q" coordinate.
For some programmable texture lookups (explicit LOD, LOD bias,
projective), "too many" coordinates are required. Such lookups are not
possible with four-component vectors; it would require at least two
parameters to perform such operations.
For fixed-function shading, it is recommended that shadow mapping
lookups in two-dimensional array textures be treated as non-projective,
even though all other lookups would be projective. Additionally, the
"q" coordinate should be used for the depth reference value in this
case.
(6) How do texture borders interact with array textures?
RESOLVED: Each individual layer of an array texture can have a border,
as though it were a normal one- or two-dimensional texture. However,
there are no "border layers".
(7) How does mipmapping work with array textures?
RESOLVED: Level <N+1> is half the size of level <N> in width and/or
height, but the number of layers is always the same for each level --
layer <M> of level <N+1> is expected to be a filtered version of layer
<M> of the higher mipmap levels. This behavior impacts the texture
consistency rules for array textures.
(8) Are compressed textures supported for array textures?
RESOLVED: Yes; they may be loaded via normal TexImage APIs, as well as
CompressedTexImage2D and CompressedTexImage3D. Compressed array
textures are treated as arrays of compressed 1D or 2D images.
(9) Should these things be called "array textures" or "texture arrays"?
RESOLVED: "Array textures", mostly because it was easier spec wording.
Calling them "array textures" also seems like better disambiguation;
there are several different things that can be thought of as "texture
arrays":
* the array of texture levels (mipmapping)
* the array of texture layers (array textures)
* the array of texels in each image
This spec changes the use of "texture array" in the core specification
(which means the array of texels) to instead refer to "texel array".
(10) If they're called "array textures", why does the extension name
include "texture_array"?
RESOLVED: Because this is primarily a texture extension, and all such
extensions start with "texture".
(11) Should new functions be provided for loading or modifying array
textures?
RESOLVED: No. Existing TexImage2D (1D arrays) and TexImage3D (2D
arrays), plus corresponding TexSubImage, CopyTexImage, and
CopyTexSubImage calls are sufficient.
(12) Should ARB_imaging functionality to be extended to support
two-dimensional array textures?
RESOLVED: No. Convolution is rarely used when texture images are
defined, and is even less likely for array teture images. This could be
addressed via a separate extension if the need were identified, and such
operations could be defined for 3D textures as well at that time.
Note that with the API chosen, one-dimensional array textures do have
convolution applied (if enabled), because image data is treated as a
normal two-dimensional image.
(13) What if an application wants to populate an array texture using
separate mipmap chains a layer at a time rather than specifying all
layers of a given mipmap level at once?
RESOLVED: For 2D array textures, call TexImage3D once with a NULL image
pointer for each level to establish the texel array sizes. Then, call
TexSubImage3D for each layer/mipmap level to define individual images.
(14) Should we provide a way to query a single layer of an array texture?
RESOLVED: No; we don't expect this to be an issue in practice.
GetTexImage() will return a two- or three-dimensional image for one- and
two-dimensional arrays, including all levels. If this were identified
as an important need, a follow-on extension could be added in the
future.
(15) How is the LOD (lambda) computed for array textures?
RESOLVED: LOD is computed in the same manner for 1D and 2D array
textures as it is for normal 1D and 2D textures. The layer coordinate
has no effect on LOD computations.
(16) What's the deal with this new "COMPARE_REF_DEPTH_TO_TEXTURE_EXT"?
RESOLVED: It's a new name for the existing enumerant
"COMPARE_R_TO_TEXTURE". This alternate name is provided to reflect the
fact that it's not always the R coordinate that is used for depth
comparisons.
(17) How do array textures work with framebuffer objects
(EXT_framebuffer_object extension, also known as "FBO")?
RESOLVED: A new function, FramebufferTextureLayerEXT(), is provided to
attach a single layer of a one- or two-dimensional array texture to an
framebuffer attachment point. That new function can also be used to
attach a layer of a three-dimensional texture.
In addition to supporting FBO attachments, the manual mipmap generation
support provided by glGenerateMipmapEXT is extended to array textures.
Mipmap generation applies to each layer of the array texture
independently, as is the case with the GENERATE_MIPMAPS texture
parameter.
This support provided here a limited subset of the FBO support added by
NV_geometry_program4, which additionally provides the ability to attach
an entire level of a three-dimensional, cube map, or array texture.
When such attachments are performed, a geometry program can be used to
select a layer to render each emitted primitive to.
(18) Should array texture targets be supported for creation of "render
buffers"?
RESOLVED: No. These are inherently two-dimensional images.
(19) Should we provide a mipmap generation function to generate mipmaps
for only a single layer of an array texture?
RESOLVED: Not in this extension. We considered adding this toward the
end of the development of this extension, but decided not to add it
because this mipmap generation function would have very different
requirements from the GenerateMipmapEXT function provided by
EXT_framebuffer_object.
The existing GenerateMipmapEXT function replaces all levels of detail
below the base level with generated mipmaps. If those mipmap levels are
unpopulated or inconsistent with the base level, they are completely
overwritten with a generated image that is consistent with the base
level. If we were to provide a function to generate mipmaps for only a
single layer, all other layers of non-base levels would need to be
preserved. However, since there are not separate formats or sizes per
level, this form of mipmap generation would require that all non-base
levels be present and consistent with the base level, or mipmap
generation wouldn't work.
We expect that future revisions of the GL will change the specification
of mipmapped textures in
(20) This extension allows the use of S3TC texture internal formats in
TexImage3D and CompressedTexImage3D. Does this mean that they are
now supported for 3D textures?
RESOLVED: No. With this extension alone, TexImage3D and
CompressedTexImage3D only support S3TC compressed formats with a target
of TEXTURE_2D_ARRAY_EXT. The S3TC tokens were added to the list of
internal formats supported by TexImage3D and friends because
two-dimensional array textures are specified using the three-dimensional
TexImage functions.
The existing extension NV_texture_compression_vtc does provides support
for S3TC-style compressed 3D textures.
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
6 02/04/08 pbrown Added a missing interaction with the VTC texture
compression spec allowing updates of compressed
2D array textures along 4x4x1 boundaries (we
previously inherited the VTC restriction of
4x4x4).
5 12/15/06 pbrown Documented that the '#extension' token
for this extension should begin with "GL_",
as apparently called for per convention.
4 -- Pre-release revisions.
4 -- Pre-release revisions.
 |  | Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.
|
