1Name 2 3 EXT_texture_array 4 5Name Strings 6 7 GL_EXT_texture_array 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Contributors 14 15 Jon Leech, Khronos 16 Mark Kilgard, NVIDIA 17 18Status 19 20 Shipping for GeForce 8 Series (November 2006, Release 95) 21 22Version 23 24 Last Modified Date: 9/16/2008 25 Author revision: 8 26 27Number 28 29 329 30 31Dependencies 32 33 This extension is written against the OpenGL 2.0 specification and version 34 1.10.59 of the OpenGL Shading Language specification. 35 36 This extension is interacts with EXT_framebuffer_object. 37 38 This extension interacts with NV_geometry_program4. 39 40 This extension interacts with NV_gpu_program4 or the OpenGL Shading 41 Language, which provide the mechanisms necessary to access array textures. 42 43 This extension interacts with EXT_texture_compression_s3tc and 44 NV_texture_compression_vtc. 45 46Overview 47 48 This extension introduces the notion of one- and two-dimensional array 49 textures. An array texture is a collection of one- and two-dimensional 50 images of identical size and format, arranged in layers. A 51 one-dimensional array texture is specified using TexImage2D; a 52 two-dimensional array texture is specified using TexImage3D. The height 53 (1D array) or depth (2D array) specify the number of layers in the image. 54 55 An array texture is accessed as a single unit in a programmable shader, 56 using a single coordinate vector. A single layer is selected, and that 57 layer is then accessed as though it were a one- or two-dimensional 58 texture. The layer used is specified using the "t" or "r" texture 59 coordinate for 1D and 2D array textures, respectively. The layer 60 coordinate is provided as an unnormalized floating-point value in the 61 range [0,<n>-1], where <n> is the number of layers in the array texture. 62 Texture lookups do not filter between layers, though such filtering can be 63 achieved using programmable shaders. When mipmapping is used, each level 64 of an array texture has the same number of layers as the base level; the 65 number of layers is not reduced as the image size decreases. 66 67 Array textures can be rendered to by binding them to a framebuffer object 68 (EXT_framebuffer_object). A single layer of an array texture can be bound 69 using normal framebuffer object mechanisms, or an entire array texture can 70 be bound and rendered to using the layered rendering mechanisms provided 71 by NV_geometry_program4. 72 73 This extension does not provide for the use of array textures with 74 fixed-function fragment processing. Such support could be added by 75 providing an additional extension allowing applications to pass the new 76 target enumerants (TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT) to 77 Enable and Disable. 78 79New Procedures and Functions 80 81 void FramebufferTextureLayerEXT(enum target, enum attachment, 82 uint texture, int level, int layer); 83 84New Tokens 85 86 Accepted by the <target> parameter of TexParameteri, TexParameteriv, 87 TexParameterf, TexParameterfv, GenerateMipmapEXT, and BindTexture: 88 89 TEXTURE_1D_ARRAY_EXT 0x8C18 90 TEXTURE_2D_ARRAY_EXT 0x8C1A 91 92 Accepted by the <target> parameter of TexImage3D, TexSubImage3D, 93 CopyTexSubImage3D, CompressedTexImage3D, and CompressedTexSubImage3D: 94 95 TEXTURE_2D_ARRAY_EXT 96 PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B 97 98 Accepted by the <target> parameter of TexImage2D, TexSubImage2D, 99 CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D, and 100 CompressedTexSubImage2D: 101 102 TEXTURE_1D_ARRAY_EXT 103 PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19 104 105 Accepted by the <pname> parameter of GetBooleanv, GetDoublev, GetIntegerv 106 and GetFloatv: 107 108 TEXTURE_BINDING_1D_ARRAY_EXT 0x8C1C 109 TEXTURE_BINDING_2D_ARRAY_EXT 0x8C1D 110 MAX_ARRAY_TEXTURE_LAYERS_EXT 0x88FF 111 112 Accepted by the <param> parameter of TexParameterf, TexParameteri, 113 TexParameterfv, and TexParameteriv when the <pname> parameter is 114 TEXTURE_COMPARE_MODE_ARB: 115 116 COMPARE_REF_DEPTH_TO_TEXTURE_EXT 0x884E 117 118 (Note: COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the 119 existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name 120 reflects the fact that the R coordinate is not always used.) 121 122 Accepted by the <internalformat> parameter of TexImage3D and 123 CompressedTexImage3D, and by the <format> parameter of 124 CompressedTexSubImage3D: 125 126 COMPRESSED_RGB_S3TC_DXT1_EXT 127 COMPRESSED_RGBA_S3TC_DXT1_EXT 128 COMPRESSED_RGBA_S3TC_DXT3_EXT 129 COMPRESSED_RGBA_S3TC_DXT5_EXT 130 131 Accepted by the <pname> parameter of 132 GetFramebufferAttachmentParameterivEXT: 133 134 FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4 135 136 (Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the 137 FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in 138 EXT_framebuffer_object. This extension generalizes the notion of 139 "<zoffset>" to include layers of an array texture.) 140 141 Returned by the <type> parameter of GetActiveUniform: 142 143 SAMPLER_1D_ARRAY_EXT 0x8DC0 144 SAMPLER_2D_ARRAY_EXT 0x8DC1 145 SAMPLER_1D_ARRAY_SHADOW_EXT 0x8DC3 146 SAMPLER_2D_ARRAY_SHADOW_EXT 0x8DC4 147 148Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 149 150 Modify section 2.15.3, "Shader Variables", page 75 151 152 Add the following new return types to the description of GetActiveUniform 153 on p. 81. 154 155 SAMPLER_1D_ARRAY_EXT, 156 SAMPLER_2D_ARRAY_EXT, 157 SAMPLER_1D_ARRAY_SHADOW_EXT, 158 SAMPLER_2D_ARRAY_SHADOW_EXT 159 160 Modify Section 2.15.4, Shader Execution (p. 84) 161 162 (modify first paragraph, p. 86 -- two simple edits: 163 164 (1) Change reference to the "r" coordinate to simply indicate that the 165 reference value for shadow mapping is provided in the lookup 166 function. It's still usually in the "r" coordinate, except for 167 two-dimensional array textures, where it's in "q". 168 (2) Add new EXT_gpu_shader4 sampler types used for array textures. ) 169 170 Texture lookups involving textures with depth component data can either 171 return the depth data directly or return the results of a comparison with 172 a reference depth value specified in the coordinates passed to the texture 173 lookup function, as described in section 3.8.14. The comparison operation 174 is requested in the shader by using the shadow sampler types 175 (sampler1DShadow, sampler2DShadow, sampler1DArrayShadow, or 176 sampler2DArrayShadow) and in the texture using the TEXTURE_COMPARE_MODE 177 parameter. ... 178 179Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 180 181 Modify Section 3.8, Texturing (p. 149). 182 183 (add new paragraph at the top of p. 150) Six types of texture are 184 supported; each is a collection of images built from one-, two-, or 185 three-dimensional array of image elements referred to as texels. One-, 186 two-, and three-dimensional textures consist of a one-, two-, or 187 three-dimensional texel arrays. One- and two-dimensional array textures 188 are arrays of one- or two-dimensional images, consisting of one or more 189 layers. Finally, a cube map is a special two-dimensional array texture 190 with six layers that represent the faces of a cube. When accessing a cube 191 map, the texture coordinates are projected onto one of the six faces. 192 193 Modify Section 3.8.1, Texture Image Specification (p. 150). 194 195 (modify first paragraph of section, p. 150) The command 196 197 void TexImage3D( enum target, int level, int internalformat, 198 sizei width, sizei height, sizei depth, int border, 199 enum format, enum type, void *data ); 200 201 is used to specify a three-dimensional texture image. target must be one 202 of TEXTURE_3D for a three-dimensional texture or TEXTURE_2D_ARRAY_EXT for 203 a two-dimensional array texture. Additionally, target may be either 204 PROXY_TEXTURE_3D for a three-dimensional proxy texture, or 205 PROXY_TEXTURE_2D_ARRAY_EXT for a two-dimensional proxy array texture. ... 206 207 (modify the fourth paragraph on p. 151) Textures with a base internal 208 format of DEPTH_COMPONENT are supported by texture image specification 209 commands only if target is TEXTURE_1D, TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, 210 TEXTURE_2D_ARRAY_EXT, PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, 211 PROXY_TEXTURE_1D_ARRAY_EXT, or PROXY_TEXTURE_2D_ARRAY_EXT. Using this 212 format in conjunction with any other target will result in an INVALID 213 OPERATION error. 214 215 (modify the first paragraph on p. 153 -- In particular, add new terms w_b, 216 h_b, and d_b to represent border width, height, or depth, instead of a 217 single border size term b_s. Subsequent equations referring to b_s should 218 be modified to refer to w_b, h_b, and d_b, as appropriate.) 219 220 ... Counting from zero, each resulting Nth texel is assigned internal 221 integer coordinates (i, j, k), where 222 223 i = (N mod width) - w_b 224 j = (floor(N/width) mod height) - h_b 225 k = (floor(N/(width*height)) mod depth) - d_b 226 227 and w_b, h_b, and d_b are the specified border width, height, and depth. 228 w_b and h_b are the specified <border> value; d_b is the specified 229 <border> value if <target> is TEXTURE_3D or zero if <target> is 230 TEXTURE_2D_ARRAY_EXT. ... 231 232 (modify equations 3.15-3.17 and third paragraph of p. 155) 233 234 w_s = w_t + 2 * w_b (3.15) 235 h_s = h_t + 2 * h_b (3.16) 236 d_s = d_t + 2 * d_b (3.17) 237 238 ... If <border> is less than zero, or greater than b_t, then the error 239 INVALID_VALUE is generated. 240 241 (modify the last paragraph on p. 155 on to p. 156) 242 243 The maximum allowable width, height, or depth of a texel array for a 244 three-dimensional texture is an implementation dependent function of the 245 level-of-detail and internal format of the resulting image array. It must 246 be at least 2^(k-lod) + 2 * b_t for image arrays of level-of-detail 0 247 through k, where k is the log base 2 of MAX_3D_TEXTURE_SIZE, lod is the 248 level-of-detail of the image array, and b_t is the maximum border width. 249 It may be zero for image arrays of any level-of-detail greater than k. The 250 error INVALID VALUE is generated if the specified image is too large to be 251 stored under any conditions. 252 253 In a similar fashion, the maximum allowable width of a texel array for a 254 one- or two-dimensional, or one- or two-dimensional array texture, and the 255 maximum allowable height of a two-dimensional or two-dimensional array 256 texture, must be at least 2^(k-lod) + 2 * b_t for image arrays of level 0 257 through k, where k is the log base 2 of MAX_TEXTURE_SIZE. The maximum 258 allowable width and height of a cube map texture must be the same, and 259 must be at least 2^(k-lod) + 2 * b_t for image arrays level 0 through k, 260 where k is the log base 2 of MAX_CUBE_MAP_TEXTURE_SIZE. The maximum 261 number of layers for one- and two-dimensional array textures (height or 262 depth, respectively) must be at least MAX_ARRAY_TEXTURE_LAYERS_EXT for all 263 levels. 264 265 (modify the fourth paragraph on p. 156) The command 266 267 void TexImage2D( enum target, int level, 268 int internalformat, sizei width, sizei height, 269 int border, enum format, enum type, void *data ); 270 271 is used to specify a two-dimensional texture image. target must be one of 272 TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a 273 one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X, 274 TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y, 275 TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or 276 TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally, target 277 may be either PROXY_TEXTURE_2D for a two-dimensional proxy texture, 278 PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array texture, or 279 PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the special case 280 discussed in section 3.8.11. The other parameters match the corresponding 281 parameters of TexImage3D. 282 283 For the purposes of decoding the texture image, TexImage2D is equivalent 284 to calling TexImage3D with corresponding arguments and depth of 1, except 285 that 286 287 * The border depth, d_b, is zero, and the depth of the image is always 1 288 regardless of the value of border. 289 290 * The border height, h_b, is zero if <target> is TEXTURE_1D_ARRAY_EXT, 291 and <border> otherwise. 292 293 * Convolution will be performed on the image (possibly changing its width 294 and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled. 295 296 * UNPACK SKIP IMAGES is ignored. 297 298 (modify the fourth paragraph on p. 157) For the purposes of decoding the 299 texture image, TexImage1D is equivalent to calling TexImage2D with 300 corresponding arguments and height of 1, except that 301 302 * The border height and depth (h_b and d_b) are always zero, regardless 303 of the value of <border>. 304 305 * Convolution will be performed on the image (possibly changing its 306 width) only if CONVOLUTION 1D is enabled. 307 308 (modify the last paragraph on p. 157 and the first paragraph of p. 158 -- 309 changing the phrase "texture array" to "texel array" to avoid confusion 310 with array textures. All subsequent references to "texture array" in the 311 specification should also be changed to "texel array".) 312 313 We shall refer to the (possibly border augmented) decoded image as the 314 texel array. A three-dimensional texel array has width, height, and depth 315 ws, hs, and ds as defined respectively in equations 3.15, 3.16, and 316 3.17. A two-dimensional texel array has depth ds = 1, with height hs and 317 width ws as above, and a one-dimensional texel array has depth ds = 1, 318 height hs = 1, and width ws as above. 319 320 An element (i,j,k) of the texel array is called a texel (for a 321 two-dimensional texture or one-dimensional array texture, k is irrelevant; 322 for a one-dimensional texture, j and k are both irrelevant). The texture 323 value used in texturing a fragment is determined by that fragment's 324 associated (s,t,r) coordinates, but may not correspond to any actual 325 texel. See figure 3.10. 326 327 Modify Section 3.8.2, Alternate Texture Image Specification Commands 328 (p. 159) 329 330 (modify second paragraph, p. 159 -- allow 1D array textures) The command 331 332 void CopyTexImage2D( enum target, int level, 333 enum internalformat, int x, int y, sizei width, 334 sizei height, int border ); 335 336 defines a two-dimensional texture image in exactly the manner of 337 TexImage2D, except that the image data are taken from the framebuffer 338 rather than from client memory. Currently, target must be one of 339 TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X, 340 TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y, 341 TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or 342 TEXTURE_CUBE_MAP_NEGATIVE_Z. 343 344 (modify last paragraph, p. 160) ... Currently the target arguments of 345 TexSubImage1D and CopyTexSubImage1D must be TEXTURE_1D, the target 346 arguments of TexSubImage2D and CopyTexSubImage2D must be one of 347 TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X, 348 TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y, 349 TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or 350 TEXTURE_CUBE_MAP_NEGATIVE_Z, and the target arguments of TexSubImage3D and 351 CopyTexSubImage3D must be TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ... 352 353 (modify last paragraph, p. 161 and subsequent inequalities) 354 355 Negative values of xoffset, yoffset, and zoffset correspond to the 356 coordinates of border texels, addressed as in figure 3.10. Taking w_s, 357 h_s, d_s, w_b, h_b, and d_b to be the specified width, height, depth, and 358 border width, height, and depth of the texture array, and taking x, y, z, 359 w, h, and d to be the xoffset, yoffset, zoffset, width, height, and depth 360 argument values, any of the following relationships generates the error 361 INVALID VALUE: 362 363 x < -w_b 364 x + w > w_s - w_b 365 y < -h_b 366 y + h > h_s - h_b 367 z < -d_b 368 z + d > d_s - d_b 369 370 Modify Section 3.8.4, Texture Parameters (p. 166) 371 372 (modify first paragraph of section, p. 166) Various parameters control how 373 the texel array is treated when specified or changed, and when applied to 374 a fragment. Each parameter is set by calling 375 376 void TexParameter{if}( enum target, enum pname, T param ); 377 void TexParameter{if}v( enum target, enum pname, T params ); 378 379 target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, 380 TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. 381 382 Modify Section 3.8.8, Texture Minification (p. 170) 383 384 (modify first paragraph, p. 172) ... For a one-dimensional or 385 one-dimensional array texture, define v(x, y) == 0 and w(x, y) == 0; for a 386 two-dimensional, two-dimensional array, or cube map texture, define w(x, 387 y) == 0. ... 388 389 (modify second paragraph, p. 173) For one-dimensional or one-dimensional 390 array textures, j and k are irrelevant; the texel at location i becomes 391 the texture value. For two-dimensional, two-dimensional array, or cube map 392 textures, k is irrelevant; the texel at location (i, j) becomes the 393 texture value. For one- and two-dimensional array textures, the texel is 394 obtained from image layer l, where 395 396 l = clamp(floor(t + 0.5), 0, h_t-1), for one-dimensional array textures, 397 clamp(floor(r + 0.5), 0, d_t-1), for two-dimensional array textures. 398 399 (modify third paragraph, p. 174) For a two-dimensional, two-dimensional 400 array, or cube map texture, 401 402 tau = ... 403 404 where tau_ij is the texel at location (i, j) in the two-dimensional 405 texture image. For two-dimensional array textures, all texels are 406 obtained from layer l, where 407 408 l = clamp(floor(r + 0.5), 0, d_t-1). 409 410 And for a one-dimensional or one-dimensional array texture, 411 412 tau = ... 413 414 where tau_i is the texel at location i in the one-dimensional texture. 415 For one-dimensional array textures, both texels are obtained from layer l, 416 where 417 418 l = clamp(floor(t + 0.5), 0, h_t-1). 419 420 (modify first two paragraphs of "Mipmapping", p. 175) TEXTURE_MIN_FILTER 421 values NEAREST_MIPMAP_NEAREST, NEAREST_MIPMAP_LINEAR, 422 LINEAR_MIPMAP_NEAREST, and LINEAR_MIPMAP_LINEAR each require the use of a 423 mipmap. A mipmap is an ordered set of arrays representing the same image; 424 each array has a resolution lower than the previous one. 425 426 If the image array of level level_base, excluding its border, has 427 dimensions, w_t x h_t x d_t, then there are floor(log2(maxsize)) + 1 428 levels in the mipmap, where 429 430 maxsize = w_t, for one-dimensional and one-dimensional 431 array textures, 432 max(w_t, h_t), for two-dimensional, two-dimensional 433 array, and cube map textures 434 max(w_t, h_t, d_t), for three dimensional textures. 435 436 Numbering the levels such that level level_base is the 0th level, the ith 437 array has dimensions 438 439 max(1, floor(w_t/w_d)) x max(1, floor(h_t/h_d)) x max(1, floor(d_t/d_d)) 440 441 where 442 443 w_d = 2 ^ i; 444 h_d = 1, for one-dimensional array textures and 445 2 ^ i, otherwise; and 446 d_d = 1, for two-dimensional array textures and 447 2 ^ i, otherwise, 448 449 until the last array is reached with dimension 1 x 1 x 1. 450 451 Each array in a mipmap is defined using TexImage3D, TexImage2D, 452 CopyTexImage2D, TexImage1D, or CopyTexImage1D; the array being set is 453 indicated with the level-of-detail argument level. Level-of-detail numbers 454 proceed from level_base for the original texture array through p = 455 floor(log2(maxsize)) + level_base with each unit increase indicating an 456 array of half the dimensions of the previous one (rounded down to the next 457 integer if fractional) as already described. All arrays from level_base 458 through q = min{p, level_max} must be defined, as discussed in section 459 3.8.10. 460 461 (modify third paragraph in the "Mipmap Generation" section, p. 176) 462 463 The contents of the derived arrays are computed by repeated, filtered 464 reduction of the level_base array. For one- and two-dimensional array 465 textures, each layer is filtered independently. ... 466 467 Modify Section 3.8.10, Texture Completeness (p. 177) 468 469 (modify second paragaph of section, p. 177) For one-, two-, or 470 three-dimensional textures and one- or two-dimensional array textures, a 471 texture is complete if the following conditions all hold true: ... 472 473 Modify Section 3.8.11, Texture State and Proxy State (p. 178) 474 475 (modify second and third paragraphs, p. 179, adding array textures and 476 making minor wording changes) 477 478 In addition to image arrays for one-, two-, and three-dimensional 479 textures, one- and two-dimensional array textures, and the six image 480 arrays for the cube map texture, partially instantiated image arrays are 481 maintained for one-, two-, and three-dimensional textures and one- and 482 two-dimensional array textures. Additionally, a single proxy image array 483 is maintained for the cube map texture. Each proxy image array includes 484 width, height, depth, border width, and internal format state values, as 485 well as state for the red, green, blue, alpha, luminance, and intensity 486 component resolutions. Proxy image arrays do not include image data, nor 487 do they include texture properties. When TexImage3D is executed with 488 target specified as PROXY_TEXTURE_3D, the three-dimensional proxy state 489 values of the specified level-of-detail are recomputed and updated. If the 490 image array would not be supported by TexImage3D called with target set to 491 TEXTURE 3D, no error is generated, but the proxy width, height, depth, 492 border width, and component resolutions are set to zero. If the image 493 array would be supported by such a call to TexImage3D, the proxy state 494 values are set exactly as though the actual image array were being 495 specified. No pixel data are transferred or processed in either case. 496 497 Proxy arrays for one- and two-dimensional textures and one- and 498 two-dimensional array textures are operated on in the same way when 499 TexImage1D is executed with target specified as PROXY_TEXTURE_1D, 500 TexImage2D is executed with target specified as PROXY_TEXTURE_2D or 501 PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target 502 specified as PROXY_TETXURE_2D_ARRAY_EXT. 503 504 Modify Section 3.8.12, Texture Objects (p. 180) 505 506 (update most of the beginning of the section to allow array textures) 507 508 In addition to the default textures TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, 509 TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT, named one-, 510 two-, and three-dimensional, cube map, and one- and two-dimensional array 511 texture objects can be created and operated upon. The name space for 512 texture objects is the unsigned integers, with zero reserved by the GL. 513 514 A texture object is created by binding an unused name to TEXTURE_1D, 515 TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or 516 TEXTURE_2D_ARRAY_EXT. The binding is effected by calling 517 518 void BindTexture( enum target, uint texture ); 519 520 with <target> set to the desired texture target and <texture> set to the 521 unused name. The resulting texture object is a new state vector, 522 comprising all the state values listed in section 3.8.11, set to the same 523 initial values. If the new texture object is bound to TEXTURE_1D, 524 TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or 525 TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-, three-dimensional, 526 cube map, one- or two-dimensional array texture respectively until it is 527 deleted. 528 529 BindTexture may also be used to bind an existing texture object to either 530 TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, 531 TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error INVALID_OPERATION 532 is generated if an attempt is made to bind a texture object of different 533 dimensionality than the specified target. If the bind is successful no 534 change is made to the state of the bound texture object, and any previous 535 binding to target is broken. 536 537 While a texture object is bound, GL operations on the target to which it 538 is bound affect the bound object, and queries of the target to which it is 539 bound return state from the bound object. If texture mapping of the 540 dimensionality of the target to which a texture object is bound is 541 enabled, the state of the bound texture object directs the texturing 542 operation. 543 544 In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, 545 TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have 546 one-, two-, three-dimensional, cube map, and one- and two-dimensional 547 array texture state vectors respectively associated with them. In order 548 that access to these initial textures not be lost, they are treated as 549 texture objects all of whose names are 0. The initial one-, two-, 550 three-dimensional, cube map, one- and two-dimensional array textures are 551 therefore operated upon, queried, and applied as TEXTURE_1D, TEXTURE_2D, 552 TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and 553 TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding 554 targets. 555 556 (modify second paragraph, p. 181) ... If a texture that is currently 557 bound to one of the targets TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, 558 TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is 559 deleted, it is as though BindTexture had been executed with the same 560 target and texture zero. ... 561 562 (modify second paragraph, p. 182) The texture object name space, including 563 the initial one-, two-, and three dimensional, cube map, and one- and 564 two-dimensional array texture objects, is shared among all texture 565 units. ... 566 567 Modify Section 3.8.14, Texture Comparison Modes (p. 185) 568 569 (modify second through fourth paragraphs, p. 188, reflecting that the 570 texture coordinate used for depth comparisons varies, including a new enum 571 name) 572 573 Let D_t be the depth texture value, in the range [0, 1]. For 574 fixed-function texture lookups, let R be the interpolated <r> texture 575 coordinate, clamped to the range [0, 1]. For texture lookups generated by 576 a program instruction, let R be the reference value for depth comparisons 577 provided in the instruction, also clamped to [0, 1]. Then the effective 578 texture value L_t, I_t, or A_t is computed as follows: ... 579 580 If the value of TEXTURE_COMPARE_MODE is NONE, then 581 582 r = Dt 583 584 If the value of TEXTURE_COMPARE_MODE is COMPARE_REF_DEPTH_TO_TEXTURE_EXT), 585 then r depends on the texture comparison function as shown in table 3.27. 586 587 Modify Section 3.11.2, Shader Execution (p. 194) 588 589 (modify second paragraph, p. 195 -- two simple edits: 590 591 (1) Change reference to the "r" coordinate to simply indicate that the 592 reference value for shadow mapping is provided in the lookup 593 function. It's still usually in the "r" coordinate, except for 594 two-dimensional array textures, where it's in "q". 595 (2) Add new EXT_gpu_shader4 sampler types used for array textures. ) 596 597 Texture lookups involving textures with depth component data can either 598 return the depth data directly or return the results of a comparison with 599 a reference depth value specified in the coordinates passed to the texture 600 lookup function. The comparison operation is requested in the shader by 601 using the shadow sampler types (sampler1DShadow, sampler2DShadow, 602 sampler1DArrayShadow, and sampler2DArrayShadow) and in the texture using 603 the TEXTURE COMPARE MODE parameter. ... 604 605Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 606Operations and the Frame Buffer) 607 608 None. 609 610Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 611 612 Modify Section 5.4, Display Lists (p. 237) 613 614 (modify first paragraph, p. 242) TexImage3D, TexImage2D, TexImage1D, 615 Histogram, and ColorTable are executed immediately when called with the 616 corresponding proxy arguments PROXY_TEXTURE_3D or 617 PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D, PROXY_TEXTURE_CUBE_MAP, or 618 PROXY_TEXTURE_1D_ARRAY_EXT; PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and 619 PROXY_COLOR_TABLE, PROXY_POST_CONVOLUTION_COLOR_TABLE, or 620 PROXY_POST_COLOR_MATRIX_COLOR_TABLE. 621 622Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 623State Requests) 624 625 Modify Section 6.1.3, Enumerated Queries (p. 246) 626 627 (modify second paragraph, p. 247) 628 629 GetTexParameter parameter <target> may be one of TEXTURE_1D, TEXTURE_2D, 630 TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or 631 TEXTURE_2D_ARRAY_EXT, indicating the currently bound one-, two-, 632 three-dimensional, cube map, or one- or two-dimensional array texture. 633 GetTexLevelParameter parameter target may be one of TEXTURE_1D, 634 TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP_POSITIVE_X, 635 TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y, 636 TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, 637 TEXTURE_CUBE_MAP_NEGATIVE_Z, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT, 638 PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_3D, 639 PROXY_TEXTURE_CUBE_MAP, PROXY_TEXTURE_1D_ARRAY, or PROXY_TEXTURE_2D_ARRAY, 640 indicating the one-, two-, or three-dimensional texture, one of the six 641 distinct 2D images making up the cube map texture, the one- or 642 two-dimensional array texture, or the one-, two-, three-dimensional, cube 643 map, or one- or two-dimensional array proxy state vector. ... 644 645 Modify Section 6.1.4, Texture Queries (p. 248) 646 647 (modify first three paragraphs of section, p. 248) The command 648 649 void GetTexImage( enum tex, int lod, enum format, 650 enum type, void *img ); 651 652 is used to obtain texture images. It is somewhat different from the other 653 get commands; tex is a symbolic value indicating which texture (or texture 654 face in the case of a cube map texture target name) is to be obtained. 655 TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT, and 656 TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional texture, 657 or one- or two-dimensional array texture, respectively. 658 TEXTURE_CUBE_MAP_POSITIVE_X, ... 659 660 GetTexImage obtains... from the first image to the last for 661 three-dimensional textures. One- and two-dimensional array textures are 662 treated as two- and three-dimensional images, respectively, where the 663 layers are treated as rows or images. These groups are then... 664 665 For three-dimensional and two-dimensional array textures, pixel storage 666 operations are applied as if the image were two-dimensional, except that 667 the additional pixel storage state values PACK_IMAGE_HEIGHT and 668 PACK_SKIP_IMAGES are applied. ... 669 670Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 671 672 None. 673 674Additions to the AGL/GLX/WGL Specifications 675 676 None. 677 678GLX Protocol 679 680 None. 681 682Dependencies on EXT_framebuffer_object 683 684 If EXT_framebuffer_object is supported, a single layer of an array texture 685 can be bound to a framebuffer attachment point, and manual mipmap 686 generation support is extended to include array textures. 687 688 Several modifications are made to the EXT_framebuffer_object 689 specification. First, the token identifying the attached layer of a 3D 690 texture, FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT, is renamed to 691 FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT. This is done because this 692 extension generalizes the "z offset" concept to become notion of attaching 693 a layer of a multi-layer texture, which is applicable for both 694 three-dimensional and array textures. All references to this token in 695 EXT_framebuffer_object should be changed to the new token, and references 696 to "z offset" in the specification text should be replaced with "layer" as 697 appropriate. Additional edits follow. 698 699 (modify "Manual Mipmap Generation" in edits to Section 3.8.8) 700 701 Mipmaps can be generated manually with the command 702 703 void GenerateMipmapEXT(enum target); 704 705 where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP, 706 TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY. Mipmap generation 707 affects the texture image attached to <target>. ... 708 709 (modify Section 4.4.2.3, Attaching Texture Images to a Framebuffer -- add 710 to the end of the section) 711 712 The command 713 714 void FramebufferTextureLayerEXT(enum target, enum attachment, 715 uint texture, int level, int layer); 716 717 operates identically to FramebufferTexture3DEXT, except that it attaches a 718 single layer of a three-dimensional texture or a one- or two-dimensional 719 array texture. <layer> is an integer indicating the layer number, and is 720 treated identically to the <zoffset> parameter in FramebufferTexture3DEXT. 721 The error INVALID_VALUE is generated if <layer> is negative. The error 722 INVALID_OPERATION is generated if <texture> is non-zero and is not the 723 name of a three dimensional texture or one- or two-dimensional array 724 texture. Unlike FramebufferTexture3D, no <textarget> parameter is 725 accepted. 726 727 If <texture> is non-zero and the command does not result in an error, the 728 framebuffer attachment state corresponding to <attachment> is updated as 729 in the other FramebufferTexture commands, except that 730 FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>. 731 732 (modify Section 4.4.4.1, Framebuffer Attachment Completeness) 733 734 The framebuffer attachment point <attachment> is said to be "framebuffer 735 attachment complete" if ...: 736 737 ... 738 739 * If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and 740 FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or two-dimensional 741 array texture, then FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be 742 smaller than the number of layers in the texture. 743 744 745 (modify Section 6.1.3, Enumerated Queries) 746 747 ... 748 749 If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the texture 750 object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a 751 three-dimensional texture or a one- or two-dimensional array texture, 752 then <params> will contain the number of texture layer attached to the 753 attachment point. Otherwise, <params> will contain the value zero. 754 755Dependencies on NV_geometry_program4 756 757 NV_geometry_program4 provides additional modifications to 758 EXT_framebuffer_object to support layered rendering, which allows 759 applications to bind entire three-dimensional, cube map, or array textures 760 to a single attachment point, and select a layer to render to according to 761 a layer number written by the geometry program. 762 763 The framebuffer object modifications provided in NV_geometry_program4 are 764 more extensive than the more limited support provided for array textures. 765 The edits in this spec are a functional subset of the edits in 766 NV_geometry_program4. All of the modifications that this extension makes 767 to EXT_framebuffer_object are superseded by NV_geometry_program4, except 768 for the minor language changes made to GenerateMipmapsEXT(). 769 770Dependencies on NV_gpu_program4 and the OpenGL Shading Language (GLSL) 771 772 If NV_gpu_program4, EXT_gpu_shader4, and the OpenGL Shading Language 773 (GLSL) are not supported, and no other mechanism is provided to perform 774 texture lookups into array textures, this extension is pointless, given 775 that it provides no fixed-function mechanism to access texture arrays. 776 777 If GLSL is supported, the language below describes the modifications to 778 the shading language to support array textures. The extension 779 EXT_gpu_shader4 provides a broader set of shading language modifications 780 that include array texture lookup functions described here, plus a number 781 of additional functions. 782 783 If GLSL is not supported, the shading language below and references to the 784 SAMPLER_{1D,2D}_ARRAY_EXT and SAMPLER_{1D,2D}_ARRAY_SHADOW_EXT tokens 785 should be removed. 786 787Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc 788 789 S3TC texture compression is supported for two-dimensional array textures. 790 When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently 791 as a compressed two-dimensional textures. When specifying or querying 792 compressed images using one of the S3TC formats, the images are provided 793 and/or returned as a series of two-dimensional textures stored 794 consecutively in memory, with the layer closest to zero specified first. 795 For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in 796 the three-dimensional compression format provided in the 797 EXT_texture_compression_vtc extension. Pixel store parameters, including 798 those specific to three-dimensional images, are ignored when compressed 799 image data are provided or returned, as in the 800 EXT_texture_compression_s3tc extension. 801 802 S3TC compression is not supported for one-dimensional texture targets in 803 EXT_texture_compression_s3tc, and is not supported for one-dimensional 804 array textures in this extension. If compressed one-dimensional arrays 805 are needed, use a two-dimensional texture with a height of one. 806 807 As with NV_texture_compression_vtc, this extension allows the use of the 808 four S3TC internal format types in TexImage3D, CompressedTexImage3D, and 809 CompressedTexSubImage3D calls. Unlike NV_texture_compression_vtc (for 3D 810 textures), compressed sub-image updates are allowed at arbitrary locations 811 along the Z axis. The language describing CompressedTexSubImage* APIs, 812 edited by EXT_texture_compression_s3tc (allowing updates at 4x4 boundaries 813 for 2D textures) and NV_texture_compression_vtc (allowing updates at 4x4x4 814 boundaries for 3D textures) is updated as follows: 815 816 "If the internal format of the texture image being modified is 817 COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, 818 COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the 819 texture is stored using one of several S3TC or VTC compressed texture 820 image formats. Since these algorithms support only 2D and 3D images, 821 CompressedTexSubImage1DARB produces an INVALID_ENUM error if <format> is 822 an S3TC/VTC format. Since S3TC/VTC images are easily edited along 4x4, 823 4x4x1, or 4x4x4 texel boundaries, the limitations on 824 CompressedTexSubImage2D and CompressedTexSubImage3D are relaxed. 825 CompressedTexSubImage2D and CompressedTexSubImage3D will result in an 826 INVALID_OPERATION error only if one of the following conditions occurs: 827 828 * <width> is not a multiple of four or equal to TEXTURE_WIDTH. 829 * <height> is not a multiple of four or equal to TEXTURE_HEIGHT. 830 * <xoffset> or <yoffset> is not a multiple of four. 831 * <depth> is not a multiple of four or equal to TEXTURE_DEPTH, and 832 <target> is TEXTURE_3D. 833 * <zoffset> is not a multiple of four and <target> is TEXTURE_3D." 834 835 (Note: The original version of this specification incorrectly failed to 836 allow compressed subimage updates of array textures via 837 CompressedTexSubImage3D, except at 4x4x4 boundaries/sizes. This 838 undesirable behavior was also implemented by all NVIDIA OpenGL drivers 839 published prior to February 2008.) 840 841Errors 842 843 None. Some error conditions are removed, due to the ability to use the 844 new TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT enums. 845 846New State 847 848 (add to table 6.15, p. 276) 849 850 Initial 851 Get Value Type Get Command Value Description Sec. Attribute 852 ---------------------------- ----- ----------- ----- -------------------- ------ --------- 853 TEXTURE_BINDING_1D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture 854 to TEXTURE_1D_ARRAY 855 TEXTURE_BINDING_2D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture 856 to TEXTURE_2D_ARRAY 857New Implementation Dependent State 858 859 (add to Table 6.32, p. 293) 860 861 Minimum 862 Get Value Type Get Command Value Description Sec. Attribute 863 ---------------------------- ---- ----------- ------- ------------------ ----- --------- 864 MAX_ARRAY_TEXTURE_LAYERS_EXT Z+ GetIntegerv 64 maximum number of 3.8.1 - 865 layers for texture 866 arrays 867 868Modifications to The OpenGL Shading Language Specification, Version 1.10.59 869 870 (This section describes additions to GLSL to allow shaders to access array 871 textures. This is a subset of the new shading language provided by the 872 EXT_gpu_shader4 extension, limited to array texture support. It is 873 provided here in case implementations choose to support EXT_texture_array 874 without supporting EXT_gpu_shader4 or equivalent functionality. 875 876 Note that if the EXT_gpu_shader4 extension is enabled in a shader via an 877 "#extension" line, there is no need to separately enable 878 EXT_texture_array.) 879 880 Including the following line in a shader can be used to control the 881 language features described in this extension: 882 883 #extension GL_EXT_texture_array : <behavior> 884 885 where <behavior> is as specified in section 3.3. 886 887 A new preprocessor #define is added to the OpenGL Shading Language: 888 889 #define GL_EXT_texture_array 1 890 891 Add to section 3.6 "Keywords" 892 893 The following new sampler types are added: 894 895 sampler1DArray, sampler2DArray, sampler1DArrayShadow, 896 sampler2DArrayShadow 897 898 Add to section 4.1 "Basic Types" 899 900 Add the following entries to the type table: 901 902 sampler1DArray handle for accessing a 1D array texture 903 sampler2DArray handle for accessing a 2D array texture 904 sampler1DArrayShadow handle for accessing a 1D array depth texture 905 with comparison 906 sampler2DArrayShadow handle for accessing a 2D array depth texture 907 with comparison 908 909 Add to section 8.7 "Texture Lookup Functions" 910 911 Add new functions to the set of allowed texture lookup functions: 912 913 Syntax: 914 915 vec4 texture1DArray(sampler1DArray sampler, vec2 coord 916 [, float bias]) 917 vec4 texture1DArrayLod(sampler1DArray sampler, vec2 coord, 918 float lod) 919 920 Description: 921 922 Use the first element (coord.s) of texture coordinate coord to do a 923 texture lookup in the layer indicated by the second coordinate coord.t of 924 the 1D texture array currently bound to sampler. The layer to access is 925 computed by layer = max (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is 926 the depth of the texture array. 927 928 Syntax: 929 930 vec4 texture2DArray(sampler2DArray sampler, vec3 coord 931 [, float bias]) 932 vec4 texture2DArrayLod(sampler2DArray sampler, vec3 coord, 933 float lod) 934 Description: 935 936 Use the first two elements (coord.s, coord.t) of texture coordinate coord 937 to do a texture lookup in the layer indicated by the third coordinate 938 coord.p of the 2D texture array currently bound to sampler. The layer to 939 access is computed by layer = max (0, min(d - 1, floor (coord.p + 0.5)) 940 where 'd' is the depth of the texture array. 941 942 Syntax: 943 944 vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord, 945 [float bias]) 946 vec4 shadow1DArrayLod(sampler1DArrayShadow sampler, 947 vec3 coord, float lod) 948 Description: 949 950 Use texture coordinate coord.s to do a depth comparison lookup on an array 951 layer of the depth texture bound to sampler, as described in section 952 3.8.14 of version 2.0 of the OpenGL specification. The layer to access is 953 indicated by the second coordinate coord.t and is computed by layer = max 954 (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is the depth of the 955 texture array. The third component of coord (coord.p) is used as the R 956 value. The texture bound to sampler must be a depth texture, or results 957 are undefined. 958 959 Syntax: 960 961 vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord) 962 963 Description: 964 965 Use texture coordinate (coord.s, coord.t) to do a depth comparison lookup 966 on an array layer of the depth texture bound to sampler, as described in 967 section 3.8.14 of version 2.0 of the OpenGL specification. The layer to 968 access is indicated by the third coordinate coord.p and is computed by 969 layer = max (0, min(d - 1, floor (coord.p + 0.5)) where 'd' is the depth 970 of the texture array. The fourth component of coord (coord.q) is used as 971 the R value. The texture bound to sampler must be a depth texture, or 972 results are undefined. 973 974Issues 975 976 (1) Should this extension generalize the notion of 1D and 2D textures to 977 be arrays of 1D or 2D images, or simply introduce new targets? 978 979 RESOLVED: Introduce new targets. 980 981 It would have been possible to simply extend the notion of 1D and 2D 982 textures, and allow applications to pass TEXTURE_1D to TexImage2D (1D 983 arrays) or TEXTURE_2D to TexImage3D (2D arrays). This would have 984 avoided introducing a new set of texture targets (and proxy targets), 985 and a "default texture" (object zero) for each new target. 986 987 It is desirable to have a distinction between array and non-array 988 textures in programmable shaders, so compilers can generate code 989 appropriate to the texture type. For "normal" textures, a 2D texture 990 requires two component texture coordinates, while a 2D array texture 991 requires three. Without a distinction between array and non-array 992 textures, implementations must choose between compiling shaders to the 993 most general form (2D arrays) or recompiling shaders based on texture 994 usage. Texture lookups with shadow mapping, LOD bias, or per-pixel LOD 995 have additional complexity, and the interpretation of a coordinate 996 vector may need to depend on whether the texture was an array or 997 non-array texture. 998 999 It would be possible to limit the distinction between array and 1000 non-array textures to the shaders, but it could then become the 1001 responsibility of the application developer to ensure that a texture 1002 with multiple layers is used when an "array lookup" is performed, and 1003 that a single-layer texture is used when a "non-array lookup" is 1004 performed. That begs the question of what the distinction between an 1005 "array texture" and a "non-array texture" is. At least two possible 1006 distinctions have been identified: one vs. multiple layers, or the API 1007 call used to specify the texture (TexImage3D with TEXTURE_2D == array 1008 texture, TexImage2D == non-array texture). The former does not allow 1009 for the possibility of single-layer array textures; it may be the case 1010 that application developers want to use a general shader supporting 1011 array textures, but there may be cases where only a single layer might 1012 be provided. The latter approach allows for single-layer array 1013 textures, but the distinction is now based on the API call. 1014 1015 Adding separate targets eliminates the need for such a distinction. 1016 "Array lookups" refer to the TEXTURE_1D_ARRAY_EXT or 1017 TEXTURE_2D_ARRAY_EXT targets; "non-array lookups" refer to TEXTURE_1D or 1018 TEXTURE_2D. There is never a case where the wrong kind of texture can 1019 be used, as TEXTURE_1D_ARRAY_EXT and TEXTURE_2D_ARRAY_EXT textures are 1020 always arrays by definition. 1021 1022 This distinction should also be helpful if and when fixed-function 1023 fragment processing is supported; the enabled texture target is used to 1024 generate an internal fragment shader using the proper "array lookup". 1025 There would be no need to recompile shaders depending on whether an 1026 enabled texture is an "array texture" or not. 1027 1028 (2) Should texture arrays be supported for fixed-function fragment 1029 processing? 1030 1031 RESOLVED: No; it's not believed to be worth the effort. Fixed-function 1032 fragment processing could be easily supported by allowing applications 1033 to enable or disable TEXTURE_1D_ARRAY_EXT or TEXTURE_2D_ARRAY_EXT. 1034 1035 Note that for fixed-function fragment processing, there would be issues 1036 with texture lookups of two-dimensional array textures with shadow 1037 mapping. Given that all texture lookups are projective, a total of five 1038 coordinate components would be required (s, t, layer, depth, q). 1039 1040 (3) If fixed-function were supported, should the layer number (T or R) be 1041 divided by Q in projective texture lookups? 1042 1043 RESOLVED: It doesn't need to be resolved in this extension, but it 1044 would be a problem. There are probably cases where an application would 1045 want the divide (handle R more-or-less like S/T); there are probably 1046 other cases where the divide would not be wanted. Many developers won't 1047 care, and may not even know what the Q coordinate is used for! The 1048 default of 1.0 allows applications that don't care about projective 1049 lookups to simply ignore that fact. 1050 1051 For programmable fragment shading, an application can code it either way 1052 and use non-projective lookups. To the extent that the divide by Q for 1053 projective lookups is "free" or "cheap" on OpenGL hardware, compilers 1054 may be able to recognize a projective pattern in the computed 1055 coordinates and generate code appropriately. 1056 1057 (4) Should DEPTH_COMPONENT textures be supported for texture arrays? 1058 1059 RESOLVED: Yes; multi-layer shadow maps are useful. 1060 1061 (5) How should shadow mapping in texture arrays work with programmable 1062 shaders, and fixed-function shaders (if ever supported)? 1063 1064 RESOLVED: The layer number is in the "next" coordinate following the 1065 normal 1D or 2D coordinate. That's the "t" coordinate for 1D arrays and 1066 the "r" coordinate for 2D arrays. For shadow maps, this is a problem, 1067 as the "r" coordinate is generally used as the depth reference value. 1068 This is resolved by instead taking the depth reference value from the 1069 "q" coordinate. 1070 1071 For some programmable texture lookups (explicit LOD, LOD bias, 1072 projective), "too many" coordinates are required. Such lookups are not 1073 possible with four-component vectors; it would require at least two 1074 parameters to perform such operations. 1075 1076 For fixed-function shading, it is recommended that shadow mapping 1077 lookups in two-dimensional array textures be treated as non-projective, 1078 even though all other lookups would be projective. Additionally, the 1079 "q" coordinate should be used for the depth reference value in this 1080 case. 1081 1082 (6) How do texture borders interact with array textures? 1083 1084 RESOLVED: Each individual layer of an array texture can have a border, 1085 as though it were a normal one- or two-dimensional texture. However, 1086 there are no "border layers". 1087 1088 (7) How does mipmapping work with array textures? 1089 1090 RESOLVED: Level <N+1> is half the size of level <N> in width and/or 1091 height, but the number of layers is always the same for each level -- 1092 layer <M> of level <N+1> is expected to be a filtered version of layer 1093 <M> of the higher mipmap levels. This behavior impacts the texture 1094 consistency rules for array textures. 1095 1096 (8) Are compressed textures supported for array textures? 1097 1098 RESOLVED: Yes; they may be loaded via normal TexImage APIs, as well as 1099 CompressedTexImage2D and CompressedTexImage3D. Compressed array 1100 textures are treated as arrays of compressed 1D or 2D images. 1101 1102 (9) Should these things be called "array textures" or "texture arrays"? 1103 1104 RESOLVED: "Array textures", mostly because it was easier spec wording. 1105 Calling them "array textures" also seems like better disambiguation; 1106 there are several different things that can be thought of as "texture 1107 arrays": 1108 1109 * the array of texture levels (mipmapping) 1110 * the array of texture layers (array textures) 1111 * the array of texels in each image 1112 1113 This spec changes the use of "texture array" in the core specification 1114 (which means the array of texels) to instead refer to "texel array". 1115 1116 (10) If they're called "array textures", why does the extension name 1117 include "texture_array"? 1118 1119 RESOLVED: Because this is primarily a texture extension, and all such 1120 extensions start with "texture". 1121 1122 (11) Should new functions be provided for loading or modifying array 1123 textures? 1124 1125 RESOLVED: No. Existing TexImage2D (1D arrays) and TexImage3D (2D 1126 arrays), plus corresponding TexSubImage, CopyTexImage, and 1127 CopyTexSubImage calls are sufficient. 1128 1129 (12) Should ARB_imaging functionality to be extended to support 1130 two-dimensional array textures? 1131 1132 RESOLVED: No. Convolution is rarely used when texture images are 1133 defined, and is even less likely for array teture images. This could be 1134 addressed via a separate extension if the need were identified, and such 1135 operations could be defined for 3D textures as well at that time. 1136 1137 Note that with the API chosen, one-dimensional array textures do have 1138 convolution applied (if enabled), because image data is treated as a 1139 normal two-dimensional image. 1140 1141 (13) What if an application wants to populate an array texture using 1142 separate mipmap chains a layer at a time rather than specifying all 1143 layers of a given mipmap level at once? 1144 1145 RESOLVED: For 2D array textures, call TexImage3D once with a NULL image 1146 pointer for each level to establish the texel array sizes. Then, call 1147 TexSubImage3D for each layer/mipmap level to define individual images. 1148 1149 (14) Should we provide a way to query a single layer of an array texture? 1150 1151 RESOLVED: No; we don't expect this to be an issue in practice. 1152 GetTexImage() will return a two- or three-dimensional image for one- and 1153 two-dimensional arrays, including all levels. If this were identified 1154 as an important need, a follow-on extension could be added in the 1155 future. 1156 1157 (15) How is the LOD (lambda) computed for array textures? 1158 1159 RESOLVED: LOD is computed in the same manner for 1D and 2D array 1160 textures as it is for normal 1D and 2D textures. The layer coordinate 1161 has no effect on LOD computations. 1162 1163 (16) What's the deal with this new "COMPARE_REF_DEPTH_TO_TEXTURE_EXT"? 1164 1165 RESOLVED: It's a new name for the existing enumerant 1166 "COMPARE_R_TO_TEXTURE". This alternate name is provided to reflect the 1167 fact that it's not always the R coordinate that is used for depth 1168 comparisons. 1169 1170 (17) How do array textures work with framebuffer objects 1171 (EXT_framebuffer_object extension, also known as "FBO")? 1172 1173 RESOLVED: A new function, FramebufferTextureLayerEXT(), is provided to 1174 attach a single layer of a one- or two-dimensional array texture to an 1175 framebuffer attachment point. That new function can also be used to 1176 attach a layer of a three-dimensional texture. 1177 1178 In addition to supporting FBO attachments, the manual mipmap generation 1179 support provided by glGenerateMipmapEXT is extended to array textures. 1180 Mipmap generation applies to each layer of the array texture 1181 independently, as is the case with the GENERATE_MIPMAPS texture 1182 parameter. 1183 1184 This support provided here a limited subset of the FBO support added by 1185 NV_geometry_program4, which additionally provides the ability to attach 1186 an entire level of a three-dimensional, cube map, or array texture. 1187 When such attachments are performed, a geometry program can be used to 1188 select a layer to render each emitted primitive to. 1189 1190 (18) Should array texture targets be supported for creation of "render 1191 buffers"? 1192 1193 RESOLVED: No. These are inherently two-dimensional images. 1194 1195 (19) Should we provide a mipmap generation function to generate mipmaps 1196 for only a single layer of an array texture? 1197 1198 RESOLVED: Not in this extension. We considered adding this toward the 1199 end of the development of this extension, but decided not to add it 1200 because this mipmap generation function would have very different 1201 requirements from the GenerateMipmapEXT function provided by 1202 EXT_framebuffer_object. 1203 1204 The existing GenerateMipmapEXT function replaces all levels of detail 1205 below the base level with generated mipmaps. If those mipmap levels are 1206 unpopulated or inconsistent with the base level, they are completely 1207 overwritten with a generated image that is consistent with the base 1208 level. If we were to provide a function to generate mipmaps for only a 1209 single layer, all other layers of non-base levels would need to be 1210 preserved. However, since there are not separate formats or sizes per 1211 level, this form of mipmap generation would require that all non-base 1212 levels be present and consistent with the base level, or mipmap 1213 generation wouldn't work. 1214 1215 We expect that future revisions of the GL will change the specification 1216 of mipmapped textures in 1217 1218 (20) This extension allows the use of S3TC texture internal formats in 1219 TexImage3D and CompressedTexImage3D. Does this mean that they are 1220 now supported for 3D textures? 1221 1222 RESOLVED: No. With this extension alone, TexImage3D and 1223 CompressedTexImage3D only support S3TC compressed formats with a target 1224 of TEXTURE_2D_ARRAY_EXT. The S3TC tokens were added to the list of 1225 internal formats supported by TexImage3D and friends because 1226 two-dimensional array textures are specified using the three-dimensional 1227 TexImage functions. 1228 1229 The existing extension NV_texture_compression_vtc does provides support 1230 for S3TC-style compressed 3D textures. 1231 1232Revision History 1233 1234 Rev. Date Author Changes 1235 ---- -------- -------- ----------------------------------------- 1236 8 09/16/08 mjk Document GenerateMipmapEXT allows array targets 1237 7 08/07/08 jleech Corrected token MAX_TEXTURE_ARRAY_LAYERS_EXT in 1238 state table to MAX_ARRAY_TEXTURE_LAYERS_EXT. 1239 1240 6 02/04/08 pbrown Added a missing interaction with the VTC texture 1241 compression spec allowing updates of compressed 1242 2D array textures along 4x4x1 boundaries (we 1243 previously inherited the VTC restriction of 1244 4x4x4). 1245 1246 5 12/15/06 pbrown Documented that the '#extension' token 1247 for this extension should begin with "GL_", 1248 as apparently called for per convention. 1249 1250 4 -- Pre-release revisions. 1251