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