1Name 2 3 ARB_texture_non_power_of_two 4 5Name Strings 6 7 GL_ARB_texture_non_power_of_two 8 9Contributors 10 Pat Brown 11 Cass Everitt 12 Walt Donovan 13 Ken Dyke 14 Evan Hart 15 Bimal Poddar 16 Phil Rogers 17 Ian Romanick 18 Geoff Stahl 19 Esen Yilmaz 20 21Contact 22 23 Jeremy Sandmel, Apple Computer (jsandmel 'at' apple.com) 24 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 25 26Notice 27 28 Copyright (c) 2003-2013 The Khronos Group Inc. Copyright terms at 29 http://www.khronos.org/registry/speccopyright.html 30 31Specification Update Policy 32 33 Khronos-approved extension specifications are updated in response to 34 issues and bugs prioritized by the Khronos OpenGL Working Group. For 35 extensions which have been promoted to a core Specification, fixes will 36 first appear in the latest version of that core Specification, and will 37 eventually be backported to the extension document. This policy is 38 described in more detail at 39 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 40 41Status 42 43 Approved by the ARB on June 11, 2003. 44 45Version 46 47 Date: November 4, 2006 48 Revision: 1.0 49 50Number 51 52 ARB Extension #34 53 54Dependencies 55 56 Written based on the OpenGL 1.4 specification. 57 58 ARB_texture_mirrored_repeat (and IBM_texture_mirrored_repeat) 59 affects the definition of this extension. 60 61 ARB_texture_border_clamp affects the definition of this extension. 62 63 EXT_texture_compression_s3tc and NV_texture_compression_vtc affect 64 the definition of this extension. 65 66Overview 67 68 Conventional OpenGL texturing is limited to images with 69 power-of-two dimensions and an optional 1-texel border. 70 ARB_texture_non_power_of_two extension relaxes the size restrictions 71 for the 1D, 2D, cube map, and 3D texture targets. 72 73 There is no additional procedural or enumerant api introduced by this 74 extension except that an implementation which exports the extension 75 string will allow an application to pass in texture dimensions for 76 the 1D, 2D, cube map, and 3D targets that may or may not be a power 77 of two. 78 79 An implementation which supports relaxing traditional GL's 80 power-of-two size restrictions across all texture targets will export 81 the extension string: "ARB_texture_non_power_of_two". 82 83 When this extension is supported, mipmapping, automatic mipmap 84 generation, and all the conventional wrap modes are supported for 85 non-power-of-two textures 86 87Issues 88 89 1. What should this extension be called? 90 91 STATUS: RESOLVED 92 93 RESOLUTION: ARB_texture_non_power_of_two. Conventional OpenGL 94 textures are restricted to size dimensions that are powers of two. 95 96 The phrases POT (power of two) and NPOT (non-power of two) textures 97 are used in the Overview and Issues section of this specification, 98 but notice these terms are never required in the actual extension 99 language to amend the core specification. 100 101 2. Should any enable or other state change be required to relax 102 the texture dimension restrictions? 103 104 STATUS: RESOLVED 105 106 RESOLUTION: No. The restrictions on texture dimensions in the 107 core OpenGL specification are enforced by errors. Extensions are 108 free to make legal and defined the error behavior of extensions. 109 This extension is really no different in that respect. 110 111 The argument for having an enable to "unlock" more generalized 112 texture dimensions is that it avoids developers accidently releasing 113 applications developed on an OpenGL implementation supporting this 114 extension and unintentionally using NPOT textures. This situation 115 exists in theory with other extensions that do not require new 116 entry points or enumerants to operate (think of NV_blend_square). 117 The real responsibility falls on developers to not use extensions 118 unless the implementation advertises support for the extension 119 and do proper testing to ensure this is really the case. 120 121 An additional issue with not having an enable to "unlock" this 122 feature concerns the cases where existing apps might actually be 123 relying on the current error condition to tell them what to do, 124 but might not be able to handle the "new" success this extension 125 would create. However, this seems to be limited to apps that 126 are explicitly checking for implementation correctness (like a 127 conformance test) and this does not seem to be a typical problem 128 for "real-world" applications. The working group members agreed 129 that it is acceptable to require those few apps which fall into 130 this category to be updated in the context of this extension. 131 132 3. Should this extension be limited to a subset of conventional 133 texture targets? 134 135 STATUS: RESOLVED 136 137 SUGGESTION: No. This extension should apply to 1D, 2D, 3D, and 138 cube map textures (all supported by OpenGL 1.4) but this extension 139 does NOT extend or otherwise affect the EXT_texture_rectangle 140 extension's TEXTURE_RECTANGLE_EXT target. 141 142 One early point of debate was whether we should have a single 143 unified extension which lifted the power of two restrictions from 144 all targets, or whether we should have individual target specific 145 extensions. For example, one could imagine separate extensions for 146 ARB_texture_non_power_of_two_2d, ARB_texture_non_power_of_two_3d, 147 ARB_texture_non_power_of_two_cube_map. 148 149 The advantages of the separate extension approach are to allow IHV's 150 to choose which pieces of functionality to support independently. 151 The advantages of the single extension approach is to have a 152 simpler and more forward looking extension. 153 154 4. Are cube map texture images still required to be square when this 155 extension is supported? 156 157 STATUS: RESOLVED 158 159 RESOLUTION: Yes. But while the width and height of each level 160 must be equal, they can be NPOT. 161 162 5. How is a conventional NPOT target different from the texture 163 rectangle target? 164 165 STATUS: RESOLVED 166 167 RESOLUTION: 168 The biggest practical difference is that coventional targets use 169 normalized texture coordinates (ie, [0..1]) while the texture 170 rectangle target uses unnormalized (ie, [0..w]x[0..h]) texture 171 coordinates. 172 173 Differences include: 174 175 + In ARB_texture_non_power_of_two: 176 * mipmapping is allowed, default filter remains unchanged. 177 * all wrap modes are allowed, default wrap mode remains unchanged. 178 * borders are supported. 179 * paletted textures are not unsupported. 180 * texture coordinates are addressed parametrically [0..1],[0..1] 181 + In EXT_texture_rectangle: 182 * mipmapping is not allowed, default filter is changed to LINEAR. 183 * only CLAMP* wrap modes are allowed, default is CLAMP_TO_EDGE. 184 * borders are not supported. 185 * paletted textures are unsupported. 186 * texture coordinates are addressed non-parametrically [0..w],[0..h]. 187 188 6. What is the dimension reduction rule for each successively smaller 189 mipmap level? 190 191 STATUS: RESOLVED 192 193 RESOLUTION: Each successively smaller mipmap level is half the size 194 of the previous level, but if this half value is a fractional value, 195 you should round down to the next largest integer. Essentially: 196 197 max(1, floor(w_b / 2^i)) x 198 max(1, floor(h_b / 2^i)) x 199 max(1, floor(d_b / 2^i)) 200 201 where i is the ith level beyond the 0th level (the base level). 202 203 This is a "floor" convention. An alternative is a "ceiling" 204 convention. 205 206 The primary reason to favor the floor convention is that Direct3D 207 uses the floor convention. 208 209 Also, the "ceiling" convention potentially implies one more mipmap 210 level than the "floor" convention. 211 212 Some regard the "ceiling" convention to have nicer properties with 213 respect to making sure that each level samples at at least 2x the 214 frequency of the next level. This can reduce the chances of 215 sampling artifacts. However, it's probably not worth diverging 216 from the Direct3D convention just for this. A more sophisticated 217 downsampling algorithm (using a larger kernel perhaps) during 218 mipmap level generation can help reduce artifacts related to using 219 the "floor" convention. 220 221 The "floor" convention has a relatively straightforward way to 222 evaluate (with integer math) means to determine how many mipmap 223 levels are required for a complete pyramid: 224 225 numLevels = 1 + floor(log2(max(w, h, d))) 226 227 The "floor" convention can be evaluated incrementally with the 228 following recursion: 229 230 nextLODdim = max(1, currentLODdim >> 1) 231 232 where currentLODdim is the dimension of a level N and nextLODdim 233 is the dimension of level N+1. The recursion stops when level 234 numLevels-1 is reached. 235 236 Other compromise rules exist such as "round" (floor(x+0.5)). 237 Such a hybrid approach make it more difficult to compute how many 238 mipmap levels are required for a complete pyramid. 239 240 Note that this extension is compatible with supporting other rules 241 because it merely relaxes the error and completeness conditions 242 for mipmaps. At the same time, it makes sense to provide developers 243 a single consistent rule since developers are unlikely to want to 244 generate mipmaps for different rules unnecessarily. One reasonable 245 rule is sufficient and preferable, and the "floor" convention is 246 the best choice. 247 248 7. Should the LOD for filtering (rho) be computed differently for 249 NPOT textures? 250 251 STATUS: RESOLVED 252 253 RESOLUTION: No (though, ideally, the answer would be "yes slightly 254 somehow"). The core OpenGL specification already allows that 255 the ideal computation of rho (even for POT textures) is "often 256 impractical to implement". The "ceiling" convention adds one more 257 mipmap level for NPOT textures so at extreme minification, the 258 "ceiling" convention may be somewhat sharper than ideal (whereas 259 "floor" would be blurrier). 260 261 This excess bluriness should only be significant at the smallest 262 (blurriest) mipmap levels where it should be quite difficult to 263 notice for properly downsampled mipmap images. 264 265 8. Should there be any restrictions on the wrap modes supported for 266 NPOT textures? 267 268 STATUS: RESOLVED 269 270 RESOLUTION: No restrictions; all existing wrap modes 271 (GL_REPEAT, GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER, and 272 GL_MIRRORED_REPEAT) should "just work" with NPOT textures. 273 274 The difficult part of this requirement is to compute "mod w_i" 275 (or h_i or d_i) rather than simply "mod 2^n" (or 2^m or 2^l) for 276 the GL_REPEAT wrap mode (GL_MIRRORED_REPEAT may also be an issue, 277 but as defined by OpenGL 1.4, no "mod" math is required to implement 278 the mirrored repeat wrap mode). REPEAT is too commonly used (indeed 279 it is the default wrap mode) to exclude it for NPOT textures. 280 281 9. How does this extension interact with ARB_texture_compression? 282 283 STATUS: RESOLVED 284 285 RESOLUTION: It does not. ARB_texture_compression doesn't 286 technically require that any compressed formats be supported. 287 Implementations can choose to compress or not compress any 288 particular texture. 289 290 While implementations may choose an internal component resolution 291 and compressed format, the OpenGL 1.4 requires that the choice be 292 a function only of the TexImage parameters. If an implementation 293 chose not to compress NPOT textures, it might get into a situation 294 where a 7x7 image wasn't compressed but its 4x4, 2x2, and 1x1 295 mipmaps were compressed. The result would be an inconsistent mipmap 296 chain since the internal format of each level would not the same. 297 298 Therefore, an implementation must be able to handle the case where 299 decisions it makes during image specification can be corrected 300 appropriately at render time. This may mean that an implementation 301 such as the one described above may need to tempoarily keep 302 compressed and uncompressed images internally until the full 303 mipmap stack can be examined or may need to decompress previously 304 compressed images in order to recover. 305 306 10. How does this extension interact with specific texture compression 307 extensions such as EXT_texture_compression_s3tc? 308 309 STATUS: RESOLVED 310 311 RESOLUTION: It does not. If both this extension and 312 EXT_texture_compression_s3tc are supported, applications can safely 313 load NPOT S3TC-compressed textures. 314 315 Textures are still decomposed into an array of 4x4 blocks. 316 The compressed data for any texels outside the specified image 317 dimensions are irrelevant and are effectively ignored, just as they 318 are for the 1x1 and 2x2 mipmaps of a POT S3TC-compressed texture. 319 320 11. How is automatic mipmap generation affected by this extension? 321 322 STATUS: RESOLVED 323 324 RESOLUTION: It is not directly affected. If an implementation 325 supports automatic mipmap generation, then mipmap generation must 326 be supported even for NPOT textures. 327 328 Note however, that the OpenGL 1.4 specification recommends a 329 "2x2 box filter" for the default filter. This is typo since 330 a 2x2 box filter would be incorrect for 1D and 3D textures. 331 With support for NPOT textures, this "2x2 box filter" becomes 332 even more inappropriate. The wording should be changed to simply 333 recommend a box filter where the dimensionality and filter size is 334 assumed appropriate for the texture image dimensionality and size. 335 336 12. Are any edits required for Section 3.8.10 "Texture Completeness"? 337 338 STATUS: RESOLVED 339 340 RESOLUTION: No. This section references Section 3.8.8 for 341 the allowed sequence of dimensions for completeness (rather than 342 stating the requirements explicition in Section 3.8.10). The only 343 difference between NPOT and POT textures is the allowable sequence 344 of mipmap sizes, and in both cases, a smaller level is half the 345 size of the larger (modulo rounding). 346 347 As with POT textures, a mipmap chain is consistent only if the 348 correct sequence of sizes is found. As with POT textures, an 349 attempt to load a mipmap that could never be part of a consistent 350 mipmap chain should fail. For example, if an implementation 351 supports textures with dimensions only up to 1024, an attempt to 352 load level 2 with a 257x114 texture will fail because the smallest 353 possible corresponding level 0 texture would have to be 1028x456. 354 355 13. The WGL_ARB_render_texture extension allows creating a pbuffer 356 with the WGL_PBUFFER_LARGEST_ARB attribute. If this extension is 357 present, should this attribute potentially return a NPOT pbuffer? 358 359 STATUS: UNRESOLVED 360 361 SUGGESTION: The WGL_ARB_render_texture specification appears 362 to anticipate NPOT textures with this statement: "e.g. Both the 363 width and height will be a power of 2 if the implementation only 364 supports power of 2 textures." so I think the right thing to do 365 is allow NPOT textures (of the proper aspect ratio) to be returned. 366 367 It is not entirely clear if this behavior is "safe" for preexisting 368 applications that might not be aware of NPOT textures. The safe 369 thing would be to add a WGL_PBUFFER_LARGEST_NPOT_ARB enumerant 370 that could return NPOT textures and require that the existing 371 WGL_PBUFFER_LARGEST_ARB enumerant always return POT textures. 372 373New Procedures and Functions 374 375 None 376 377New Tokens 378 379 None 380 381Additions to Chapter 2 of the GL Specification (OpenGL Operation) 382 383 None 384 385Additions to Chapter 3 of the GL Specification (Rasterization) 386 387 -- Section 3.8.1 "Texture Image Specification" 388 389 Replace the discussion of the border parameter with: 390 391 "The border argument to TexImage3D is a border width. The 392 significance of borders is described below. The border width affect 393 the dimensions of the texture image; it must be the case that 394 395 w_s = w_i + 2 b_s (3.13) 396 397 h_s = h_i + 2 b_s (3.14) 398 399 d_s = d_i + 2 b_s (3.15) 400 401 where w_s, h_s, and d_s are the specified image width, height, and 402 depth, and w_i, h_i, and d_i are the dimensions of the texture image 403 internal to the border. If w_i, h_i, or d_i are less than zero, 404 then the error INVALID_VALUE is generated. 405 406 -- Section 3.8.8 "Texture Minification" 407 408 In the subsection "Scale Factor and Level of Detail"... 409 410 Replace the sentence defining the u, v, and w functions with: 411 412 "Let u(x,y) = w_i * s(x,y), v(x,y) = h_i * t(x,y), and w(x,y) = d_i * 413 r(x,y), where w_i, h_i, and d_i are as defined by equations 3.13, 414 3.14, and 3.15 with w_s, w_s, and d_s equal to the width, height, 415 and depth of the image array whose level is TEXTURE_BASE_LEVEL." 416 417 Replace 2^n, 2^m, and 2^l with w_i, h_i, and d_i in Equations 3.19, 418 3.20, and 3.21. 419 420 { floor(u), s < 1 421 i = { (3.19) 422 { w_i - 1, s = 1 423 424 { floor(u), t < 1 425 j = { (3.20) 426 { h_i - 1, t = 1 427 428 { floor(u), r < 1 429 k = { (3.21) 430 { d_i - 1, r = 1 431 432 Replace 2^n, 2^m, and 2^l with w_i, h_i, and d_i in the equations for 433 computing i_0, j_0, k_0, i_1, j_1, and k_1 used for LINEAR filtering. 434 435 { floor(u - 1/2) mod w_i, TEXTURE_WRAP_S is REPEAT 436 i_0 = { 437 { floor(u - 1/2), otherwise 438 439 { floor(v - 1/2) mod h_i, TEXTURE_WRAP_T is REPEAT 440 j_0 = { 441 { floor(v - 1/2), otherwise 442 443 { floor(w - 1/2) mod d_i, TEXTURE_WRAP_R is REPEAT 444 k_0 = { 445 { floor(w - 1/2), otherwise 446 447 { (i_0 + 1) mod w_i, TEXTURE_WRAP_S is REPEAT 448 i_1 = { 449 { i_0 + 1, otherwise 450 451 { (j_0 + 1) mod h_i, TEXTURE_WRAP_T is REPEAT 452 j_1 = { 453 { j_0 + 1, otherwise 454 455 { (k_0 + 1) mod d_i, TEXTURE_WRAP_R is REPEAT 456 k_1 = { 457 { k_0 + 1, otherwise 458 459 In the subsection "Mipmapping"... 460 461 Replace the last sentence of the first paragraph with: 462 463 "If the image array of level level_base, excluding its border, has 464 dimensions w_b x h_b x d_b, then there are floor(log2(max(w_b, h_b, 465 d_b))) + 1 image arrays in the mipmap. Numbering the levels such 466 that level level_base is the 0th level, the ith array has dimensions 467 468 max(1, floor(w_b / 2^i)) x 469 max(1, floor(h_b / 2^i)) x 470 max(1, floor(d_b / 2^i)) 471 472 until the last array is reached with dimension 1 x 1 x 1." 473 474 Replace the second sentence of the second paragraph with: 475 476 "Level-of-detail numbers proceed from level_base for the original 477 texture array through p = floor(log2(max(w_b, h_b, d_b))) + level_base 478 with each unit increase indicating an array of half the dimensions 479 of the previous one (rounded down to the next integer if fractional) 480 as already described." 481 482 In the subsection "Automatic Mipmap Generation"... 483 484 Replace the second sentence of the third paragraph with: 485 486 "No particular filter algorithm is required, though a box filter is 487 recommended as the default filter." 488 489 -- Section 3.8.10 "Texture Completeness" 490 491 In the subsection "Effects of Completeness on Texture Image 492 Specification"... 493 494 Replace the last sentence with: 495 496 "A mipmap complete set of arrays is equivalent to a complete set 497 of arrays where level_base = 0 and level_max = 1000, and where, 498 excluding borders, the dimensions of the image array being created are 499 understood to be half the corresponding dimensions of the next lower 500 numbered array (rounded down to the next integer if fractional)." 501 502Additions to Chapter 4 of the GL Specification (Per-Fragment Operations 503and the Framebuffer) 504 505 None 506 507Additions to Chapter 5 of the GL Specification (Special Functions) 508 509 None 510 511Additions to the GLX Specification 512 513 None 514 515Additions to the EXT_texture_compression_s3tc and 516NV_texture_compression_vtc Specification 517 518 Add this paragraph: 519 520 "For a compressed texture where w_i != 2^m OR h_i != 2^n OR d_i != 2^l 521 for some integer value of m, n, and l, the 4x4 tiles are assumed to be 522 aligned to u=0, v=0, w=0 origin in texel space. For such compressed 523 textures, this implies that texels in regions of tiles beyond the 524 edges u=w_i, v=h_i, and w=d_i will not be sampled explicitly." 525 526GLX Protocol 527 528 None 529 530Errors 531 532 Various errors are ELIMINATED when this extension is supported as 533 noted. 534 535 INVALID_VALUE is NO LONGER generated by TexImage1D or glCopyTexImage1D 536 if width is not zero or cannot be represented as 2^n+2(border) 537 for some integer value of n. 538 539 INVALID_VALUE is NO LONGER generated by TexImage2D or glCopyTexImage2D 540 if width or height is not zero or cannot be represented as 541 2^n+2(border) for some integer value of n. 542 543 INVALID_VALUE is NO LONGER generated by TexImage3D if width, height, 544 or depth is not zero or cannot be represented as 2^n+2(border) 545 for some integer value of n. 546 547New State 548 549 None 550 551New Implementation Dependent State 552 553 None 554 555Revision History 556 557 Date 11/04/2006 558 Revision: 1.0 559 - Updated contact info after ATI/AMD merger. 560 561 Date 05/14/2004 562 Revision: 1.0 563 - Formated text for 72 column convention 564 - Fixed date for last revision 565 - fix "Image2d" typo 566 567 Date: 03/23/2004 568 Revision: 1.0 569 - Formulas for computing the dimensions of mipmap sizes based 570 on the base level size should involve 2^i (not i^2) 571 572 Date: 09/11/2003 573 Revision: 1.0 574 - allow zero (instead of just positive values before) when 575 specifying the width, height, and depth of texture image 576 dimensions; this is to avoid an inconsistency with the 577 sample implementation 578 579 Date: 05/29/2003 580 Revision: 0.10 581 - removed "@" language for target specific behavior, the spec 582 now treats all targets uniformly 583 584 Date: 05/21/2003 585 Revision: 0.9 586 - fixed typo: ARB/IBM_mirrored_repeat should have been 587 ARB/IBM_texture_mirrored_repeat 588 - fixed various other minor typos, duplicated words, etc. 589 - added a line to issue #6 regarding suggesting use of a 590 larger kernel when downsampling using the floor convention 591 - coalesced the equations that used 3 2-term max equations into 592 single 3-term max equations for clarity 593 - fixed two more typos where "ceil" should have been "floor" 594 - refer to ARB_texture_rectangle as EXT_texture_rectangle 595 (this may change back when/if back extension becomes ARB'ified) 596 597 Date: 05/10/2003 598 Revision: 0.8 599 - additional additional names to contributors list 600 - clarified language describing resolution of issues #9,10,11 601 602 Date: 05/08/2003 603 Revision: 0.7 604 - very minor language update to overview section regarding 605 exporting of ARB_texture_non_power_of_two string 606 - fixed another two places where it said we should round up 607 instead of down (in section 3.8.10 "Texture Completeness", 608 and in section 3.8.8 "Texture Minification") 609 - mark the regions of the spec affected by the decision to 610 use separate strings per texture target with the "@" symbol. 611 This is temporary until issue #3 is resolved. 612 - resolved issues 9,10,11,12 613 614 Date: 05/08/2003 615 Revision: 0.6 616 - updated revision history and coalesced revision notes from 617 various specs 618 - fixed typo in issue #5 ("2d" --> "non_power_of_two") 619 - clarified the discussion in issue #3 as the langage was a 620 little confusing in parts. 621 - explicitly refer to the cube map targets in section 3.8.1 622 instead of using the "made up" target TEXTURE_CUBE_MAP. 623 624 Date: 05/06/2003 625 Revision: 0.5 626 - changed name of extension from ARB_texture_np2 to 627 ARB_texture_non_power_of_two 628 - added target specific extension strings 629 - added more discussion to several issues based on feedback from 630 the working group meetings 631 - fixed several typos where INVALID_VALUE was INVALID_VALID 632 - addressed typo in issue #6, it said you should round up, 633 but really we agreed to round down when describing the mipmap 634 stack (floor vs ceil convention). 635 - resolved issues 1 - 8. 636 637 Date: 04/24/2003 638 Revision: 0.4 (jsandmel) 639 - numbered issues list 640 - additional discussion of several issues 641 - added more explicit comparison of texture_rectangle and this 642 proposal 643 644 Date: 04/10/2003 645 Revision: 0.3 (mjk) 646 - integrates input from the ARB_texture_2d_np2 proposals. 647 648 Date: 03/25/2003 649 Revision: 0.1 (jsandmel) 650 - draft proposal 651 - deals with 2d targets only 652 - named: ARB_texture_2d_np2 653