| Name | |
| EXT_texture_array | |
| Name Strings | |
| GL_EXT_texture_array | |
| Contact | |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) | |
| Contributors | |
| Jon Leech, Khronos | |
| Mark Kilgard, NVIDIA | |
| Status | |
| Shipping for GeForce 8 Series (November 2006, Release 95) | |
| Version | |
| Last Modified Date: 9/16/2008 | |
| Author revision: 8 | |
| Number | |
| 329 | |
| Dependencies | |
| 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. | |
| Overview | |
| 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); | |
| New Tokens | |
| Accepted by the <target> parameter of TexParameteri, TexParameteriv, | |
| TexParameterf, TexParameterfv, GenerateMipmapEXT, 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 | |
| a 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 x h_t x 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 x 1 x 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. | |
| GLX Protocol | |
| 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.) | |
| Errors | |
| None. Some error conditions are removed, due to the ability to use the | |
| new TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT enums. | |
| New State | |
| (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_ARRAY_TEXTURE_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. | |
| Issues | |
| (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. | |
| Revision History | |
| Rev. Date Author Changes | |
| ---- -------- -------- ----------------------------------------- | |
| 8 09/16/08 mjk Document GenerateMipmapEXT allows array targets | |
| 7 08/07/08 jleech Corrected token MAX_TEXTURE_ARRAY_LAYERS_EXT in | |
| state table to MAX_ARRAY_TEXTURE_LAYERS_EXT. | |
| 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. |