Name

    ARB_texture_non_power_of_two

Name Strings

    GL_ARB_texture_non_power_of_two

Contributors
    Pat Brown
    Cass Everitt
    Walt Donovan
    Ken Dyke
    Evan Hart
    Bimal Poddar
    Phil Rogers
    Ian Romanick
    Geoff Stahl
    Esen Yilmaz

Contact

    Jeremy Sandmel, Apple Computer (jsandmel 'at' apple.com)
    Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)

Notice

    Copyright (c) 2003-2013 The Khronos Group Inc. Copyright terms at
        http://www.khronos.org/registry/speccopyright.html

Status

    Approved by the ARB on June 11, 2003.

Version

    Date: November 4, 2006
    Revision: 1.0

Number

    ARB Extension #34

Dependencies

    Written based on the OpenGL 1.4 specification.

    ARB_texture_mirrored_repeat (and IBM_texture_mirrored_repeat)
    affects the definition of this extension.

    ARB_texture_border_clamp affects the definition of this extension.

    EXT_texture_compression_s3tc and NV_texture_compression_vtc affect
    the definition of this extension.

Overview

    Conventional OpenGL texturing is limited to images with
    power-of-two dimensions and an optional 1-texel border.
    ARB_texture_non_power_of_two extension relaxes the size restrictions
    for the 1D, 2D, cube map, and 3D texture targets.

    There is no additional procedural or enumerant api introduced by this
    extension except that an implementation which exports the extension
    string will allow an application to pass in texture dimensions for
    the 1D, 2D, cube map, and 3D targets that may or may not be a power
    of two.

    An implementation which supports relaxing traditional GL's
    power-of-two size restrictions across all texture targets will export
    the extension string: "ARB_texture_non_power_of_two".

    When this extension is supported, mipmapping, automatic mipmap
    generation, and all the conventional wrap modes are supported for
    non-power-of-two textures

Issues

    1. What should this extension be called?

      STATUS: RESOLVED

      RESOLUTION:  ARB_texture_non_power_of_two.  Conventional OpenGL
      textures are restricted to size dimensions that are powers of two.

      The phrases POT (power of two) and NPOT (non-power of two) textures
      are used in the Overview and Issues section of this specification,
      but notice these terms are never required in the actual extension
      language to amend the core specification.

    2. Should any enable or other state change be required to relax
    the texture dimension restrictions?

      STATUS: RESOLVED

      RESOLUTION:  No.  The restrictions on texture dimensions in the
      core OpenGL specification are enforced by errors.  Extensions are
      free to make legal and defined the error behavior of extensions.
      This extension is really no different in that respect.

      The argument for having an enable to "unlock" more generalized
      texture dimensions is that it avoids developers accidently releasing
      applications developed on an OpenGL implementation supporting this
      extension and unintentionally using NPOT textures.  This situation
      exists in theory with other extensions that do not require new
      entry points or enumerants to operate (think of NV_blend_square).
      The real responsibility falls on developers to not use extensions
      unless the implementation advertises support for the extension
      and do proper testing to ensure this is really the case.

      An additional issue with not having an enable to "unlock" this
      feature concerns the cases where existing apps might actually be
      relying on the current error condition to tell them what to do,
      but might not be able to handle the "new" success this extension
      would create.  However, this seems to be limited to apps that
      are explicitly checking for implementation correctness (like a
      conformance test) and this does not seem to be a typical problem
      for "real-world" applications.  The working group members agreed
      that it is acceptable to require those few apps which fall into
      this category to be updated in the context of this extension.

    3. Should this extension be limited to a subset of conventional
    texture targets?

      STATUS: RESOLVED

      SUGGESTION:  No.  This extension should apply to 1D, 2D, 3D, and
      cube map textures (all supported by OpenGL 1.4) but this extension
      does NOT extend or otherwise affect the EXT_texture_rectangle
      extension's TEXTURE_RECTANGLE_EXT target.
 
      One early point of debate was whether we should have a single
      unified extension which lifted the power of two restrictions from
      all targets, or whether we should have individual target specific
      extensions.   For example, one could imagine separate extensions for
      ARB_texture_non_power_of_two_2d, ARB_texture_non_power_of_two_3d,
      ARB_texture_non_power_of_two_cube_map.

      The advantages of the separate extension approach are to allow IHV's
      to choose which pieces of functionality to support independently.
      The advantages of the single extension approach is to have a
      simpler and more forward looking extension.
      
    4. Are cube map texture images still required to be square when this
    extension is supported?

      STATUS: RESOLVED

      RESOLUTION:  Yes.  But while the width and height of each level
      must be equal, they can be NPOT.

    5. How is a conventional NPOT target different from the texture
    rectangle target?

      STATUS: RESOLVED

      RESOLUTION:
      The biggest practical difference is that coventional targets use
      normalized texture coordinates (ie, [0..1]) while the texture
      rectangle target uses unnormalized (ie, [0..w]x[0..h]) texture
      coordinates.

      Differences include:

      + In ARB_texture_non_power_of_two:
        * mipmapping is allowed, default filter remains unchanged.
        * all wrap modes are allowed, default wrap mode remains unchanged.
        * borders are supported.
        * paletted textures are not unsupported.
        * texture coordinates are addressed parametrically [0..1],[0..1]
      + In EXT_texture_rectangle:
        * mipmapping is not allowed, default filter is changed to LINEAR.
        * only CLAMP* wrap modes are allowed, default is CLAMP_TO_EDGE.
        * borders are not supported.
        * paletted textures are unsupported.
        * texture coordinates are addressed non-parametrically [0..w],[0..h].

    6. What is the dimension reduction rule for each successively smaller
    mipmap level?

      STATUS: RESOLVED

      RESOLUTION:  Each successively smaller mipmap level is half the size
      of the previous level, but if this half value is a fractional value,
      you should round down to the next largest integer.  Essentially:

        max(1, floor(w_b / 2^i)) x
           max(1, floor(h_b / 2^i)) x
              max(1, floor(d_b / 2^i))

      where i is the ith level beyond the 0th level (the base level).

      This is a "floor" convention.  An alternative is a "ceiling"
      convention.

      The primary reason to favor the floor convention is that Direct3D
      uses the floor convention.

      Also, the "ceiling" convention potentially implies one more mipmap
      level than the "floor" convention.

      Some regard the "ceiling" convention to have nicer properties with
      respect to making sure that each level samples at at least 2x the
      frequency of the next level.  This can reduce the chances of
      sampling artifacts.  However, it's probably not worth diverging
      from the Direct3D convention just for this.  A more sophisticated
      downsampling algorithm (using a larger kernel perhaps) during
      mipmap level generation can help reduce artifacts related to using 
      the "floor" convention.

      The "floor" convention has a relatively straightforward way to
      evaluate (with integer math) means to determine how many mipmap
      levels are required for a complete pyramid:

        numLevels = 1 + floor(log2(max(w, h, d)))

      The "floor" convention can be evaluated incrementally with the
      following recursion:

         nextLODdim = max(1, currentLODdim >> 1)

      where currentLODdim is the dimension of a level N and nextLODdim
      is the dimension of level N+1.  The recursion stops when level
      numLevels-1 is reached.

      Other compromise rules exist such as "round" (floor(x+0.5)).
      Such a hybrid approach make it more difficult to compute how many
      mipmap levels are required for a complete pyramid.

      Note that this extension is compatible with supporting other rules
      because it merely relaxes the error and completeness conditions
      for mipmaps.  At the same time, it makes sense to provide developers
      a single consistent rule since developers are unlikely to want to
      generate mipmaps for different rules unnecessarily.  One reasonable
      rule is sufficient and preferable, and the "floor" convention is
      the best choice.

    7. Should the LOD for filtering (rho) be computed differently for
    NPOT textures?

      STATUS: RESOLVED

      RESOLUTION:  No (though, ideally, the answer would be "yes slightly
      somehow").  The core OpenGL specification already allows that
      the ideal computation of rho (even for POT textures) is "often
      impractical to implement".  The "ceiling" convention adds one more
      mipmap level for NPOT textures so at extreme minification, the
      "ceiling" convention may be somewhat sharper than ideal (whereas
      "floor" would be blurrier).

      This excess bluriness should only be significant at the smallest
      (blurriest) mipmap levels where it should be quite difficult to
      notice for properly downsampled mipmap images.

    8. Should there be any restrictions on the wrap modes supported for
    NPOT textures?

      STATUS: RESOLVED

      RESOLUTION:  No restrictions; all existing wrap modes
      (GL_REPEAT, GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER, and
      GL_MIRRORED_REPEAT) should "just work" with NPOT textures.

      The difficult part of this requirement is to compute "mod w_i"
      (or h_i or d_i) rather than simply "mod 2^n" (or 2^m or 2^l) for
      the GL_REPEAT wrap mode (GL_MIRRORED_REPEAT may also be an issue,
      but as defined by OpenGL 1.4, no "mod" math is required to implement
      the mirrored repeat wrap mode).  REPEAT is too commonly used (indeed
      it is the default wrap mode) to exclude it for NPOT textures.

    9. How does this extension interact with ARB_texture_compression?

      STATUS: RESOLVED

      RESOLUTION:  It does not.  ARB_texture_compression doesn't
      technically require that any compressed formats be supported.
      Implementations can choose to compress or not compress any
      particular texture.

      While implementations may choose an internal component resolution
      and compressed format, the OpenGL 1.4 requires that the choice be
      a function only of the TexImage parameters.  If an implementation
      chose not to compress NPOT textures, it might get into a situation
      where a 7x7 image wasn't compressed but its 4x4, 2x2, and 1x1
      mipmaps were compressed.  The result would be an inconsistent mipmap
      chain since the internal format of each level would not the same.

      Therefore, an implementation must be able to handle the case where
      decisions it makes during image specification can be corrected
      appropriately at render time.  This may mean that an implementation
      such as the one described above may need to tempoarily keep
      compressed and uncompressed images internally until the full
      mipmap stack can be examined or may need to decompress previously
      compressed images in order to recover.

    10. How does this extension interact with specific texture compression
    extensions such as EXT_texture_compression_s3tc?

      STATUS: RESOLVED

      RESOLUTION:  It does not.  If both this extension and
      EXT_texture_compression_s3tc are supported, applications can safely
      load NPOT S3TC-compressed textures.
      
      Textures are still decomposed into an array of 4x4 blocks.
      The compressed data for any texels outside the specified image
      dimensions are irrelevant and are effectively ignored, just as they
      are for the 1x1 and 2x2 mipmaps of a POT S3TC-compressed texture.

    11. How is automatic mipmap generation affected by this extension?

      STATUS: RESOLVED

      RESOLUTION:  It is not directly affected.   If an implementation
      supports automatic mipmap generation, then mipmap generation must
      be supported even for NPOT textures.  

      Note however, that the OpenGL 1.4 specification recommends a
      "2x2 box filter" for the default filter.  This is typo since
      a 2x2 box filter would be incorrect for 1D and 3D textures.
      With support for NPOT textures, this "2x2 box filter" becomes
      even more inappropriate.  The wording should be changed to simply
      recommend a box filter where the dimensionality and filter size is
      assumed appropriate for the texture image dimensionality and size.

    12. Are any edits required for Section 3.8.10 "Texture Completeness"?

      STATUS: RESOLVED

      RESOLUTION:  No.  This section references Section 3.8.8 for
      the allowed sequence of dimensions for completeness (rather than
      stating the requirements explicition in Section 3.8.10).  The only
      difference between NPOT and POT textures is the allowable sequence
      of mipmap sizes, and in both cases, a smaller level is half the
      size of the larger (modulo rounding).

      As with POT textures, a mipmap chain is consistent only if the
      correct sequence of sizes is found.  As with POT textures, an
      attempt to load a mipmap that could never be part of a consistent
      mipmap chain should fail.  For example, if an implementation
      supports textures with dimensions only up to 1024, an attempt to
      load level 2 with a 257x114 texture will fail because the smallest
      possible corresponding level 0 texture would have to be 1028x456.

    13. The WGL_ARB_render_texture extension allows creating a pbuffer
    with the WGL_PBUFFER_LARGEST_ARB attribute.  If this extension is
    present, should this attribute potentially return a NPOT pbuffer?

      STATUS: UNRESOLVED

      SUGGESTION:  The WGL_ARB_render_texture specification appears
      to anticipate NPOT textures with this statement: "e.g. Both the
      width and height will be a power of 2 if the implementation only
      supports power of 2 textures." so I think the right thing to do
      is allow NPOT textures (of the proper aspect ratio) to be returned.

      It is not entirely clear if this behavior is "safe" for preexisting
      applications that might not be aware of NPOT textures.  The safe
      thing would be to add a WGL_PBUFFER_LARGEST_NPOT_ARB enumerant
      that could return NPOT textures and require that the existing
      WGL_PBUFFER_LARGEST_ARB enumerant always return POT textures.

New Procedures and Functions

    None

New Tokens

    None

Additions to Chapter 2 of the GL Specification (OpenGL Operation)

    None

Additions to Chapter 3 of the GL Specification (Rasterization)

 -- Section 3.8.1 "Texture Image Specification"

    Replace the discussion of the border parameter with:

    "The border argument to TexImage3D is a border width.  The
    significance of borders is described below.  The border width affect
    the dimensions of the texture image; it must be the case that

      w_s = w_i + 2 b_s             (3.13)

      h_s = h_i + 2 b_s             (3.14)

      d_s = d_i + 2 b_s             (3.15)

    where w_s, h_s, and d_s are the specified image width, height, and
    depth, and w_i, h_i, and d_i are the dimensions of the texture image
    internal to the border.  If w_i, h_i, or d_i are less than zero,
    then the error INVALID_VALUE is generated.

 -- Section 3.8.8 "Texture Minification"

    In the subsection "Scale Factor and Level of Detail"...

    Replace the sentence defining the u, v, and w functions with:

    "Let u(x,y) = w_i * s(x,y), v(x,y) = h_i * t(x,y), and w(x,y) = d_i *
    r(x,y), where w_i, h_i, and d_i are as defined by equations 3.13,
    3.14, and 3.15 with w_s, w_s, and d_s equal to the width, height,
    and depth of the image array whose level is TEXTURE_BASE_LEVEL."

    Replace 2^n, 2^m, and 2^l with w_i, h_i, and d_i in Equations 3.19,
    3.20, and 3.21.

          { floor(u),   s < 1
      i = {                              (3.19)
          { w_i - 1,    s = 1

          { floor(u),   t < 1
      j = {                              (3.20)
          { h_i - 1,    t = 1

          { floor(u),   r < 1
      k = {                              (3.21)
          { d_i - 1,    r = 1

    Replace 2^n, 2^m, and 2^l with w_i, h_i, and d_i in the equations for
    computing i_0, j_0, k_0, i_1, j_1, and k_1 used for LINEAR filtering.

            { floor(u - 1/2) mod w_i,   TEXTURE_WRAP_S is REPEAT
      i_0 = {
            { floor(u - 1/2),           otherwise

            { floor(v - 1/2) mod h_i,   TEXTURE_WRAP_T is REPEAT
      j_0 = {
            { floor(v - 1/2),           otherwise

            { floor(w - 1/2) mod d_i,   TEXTURE_WRAP_R is REPEAT
      k_0 = {
            { floor(w - 1/2),           otherwise

            { (i_0 + 1) mod w_i,        TEXTURE_WRAP_S is REPEAT
      i_1 = {
            { i_0 + 1,                  otherwise

            { (j_0 + 1) mod h_i,        TEXTURE_WRAP_T is REPEAT
      j_1 = {
            { j_0 + 1,                  otherwise

            { (k_0 + 1) mod d_i,        TEXTURE_WRAP_R is REPEAT
      k_1 = {
            { k_0 + 1,                  otherwise

    In the subsection "Mipmapping"...

    Replace the last sentence of the first paragraph with:

    "If the image array of level level_base, excluding its border, has
    dimensions w_b x h_b x d_b, then there are floor(log2(max(w_b, h_b,
    d_b))) + 1 image arrays in the mipmap.  Numbering the levels such
    that level level_base is the 0th level, the ith array has dimensions

      max(1, floor(w_b / 2^i)) x
        max(1, floor(h_b / 2^i)) x
          max(1, floor(d_b / 2^i))

    until the last array is reached with dimension 1 x 1 x 1."

    Replace the second sentence of the second paragraph with:

    "Level-of-detail numbers proceed from level_base for the original
    texture array through p = floor(log2(max(w_b, h_b, d_b))) + 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."

    In the subsection "Automatic Mipmap Generation"...

    Replace the second sentence of the third paragraph with:

    "No particular filter algorithm is required, though a box filter is
    recommended as the default filter."

 -- Section 3.8.10 "Texture Completeness"

    In the subsection "Effects of Completeness on Texture Image
    Specification"...

    Replace the last sentence with:

    "A mipmap complete set of arrays is equivalent to a complete set
    of arrays where level_base = 0 and level_max = 1000, and where,
    excluding borders, the dimensions of the image array being created are
    understood to be half the corresponding dimensions of the next lower
    numbered array (rounded down to the next integer if fractional)."

Additions to Chapter 4 of the GL Specification (Per-Fragment Operations
and the Framebuffer)

    None

Additions to Chapter 5 of the GL Specification (Special Functions)

    None

Additions to the GLX Specification

    None

Additions to the EXT_texture_compression_s3tc and
NV_texture_compression_vtc Specification

    Add this paragraph:

    "For a compressed texture where w_i != 2^m OR h_i != 2^n OR d_i != 2^l
    for some integer value of m, n, and l, the 4x4 tiles are assumed to be
    aligned to u=0, v=0, w=0 origin in texel space.  For such compressed
    textures, this implies that texels in regions of tiles beyond the
    edges u=w_i, v=h_i, and w=d_i will not be sampled explicitly."

GLX Protocol

    None

Errors

    Various errors are ELIMINATED when this extension is supported as
    noted.

    INVALID_VALUE is NO LONGER generated by TexImage1D or glCopyTexImage1D
    if width is not zero or cannot be represented as 2^n+2(border)
    for some integer value of n.

    INVALID_VALUE is NO LONGER generated by TexImage2D or glCopyTexImage2D
    if width or height is not zero or cannot be represented as
    2^n+2(border) for some integer value of n.

    INVALID_VALUE is NO LONGER generated by TexImage3D if width, height,
    or depth is not zero or cannot be represented as 2^n+2(border)
    for some integer value of n.

New State

    None

New Implementation Dependent State

    None

Revision History

    Date 11/04/2006
    Revision: 1.0
       -  Updated contact info after ATI/AMD merger.

    Date 05/14/2004
    Revision: 1.0
       -  Formated text for 72 column convention
       -  Fixed date for last revision
       -  fix "Image2d" typo

    Date: 03/23/2004
    Revision: 1.0
        - Formulas for computing the dimensions of mipmap sizes based
          on the base level size should involve 2^i (not i^2)

    Date: 09/11/2003
    Revision: 1.0
        - allow zero (instead of just positive values before) when
          specifying the width, height, and depth of texture image
          dimensions; this is to avoid an inconsistency with the
          sample implementation

    Date: 05/29/2003
    Revision: 0.10
        - removed "@" language for target specific behavior, the spec
          now treats all targets uniformly

    Date: 05/21/2003
    Revision: 0.9
        - fixed typo: ARB/IBM_mirrored_repeat should have been 
          ARB/IBM_texture_mirrored_repeat
        - fixed various other minor typos, duplicated words, etc.
        - added a line to issue #6 regarding suggesting use of a
          larger kernel when downsampling using the floor convention
        - coalesced the equations that used 3 2-term max equations into
          single 3-term max equations for clarity
        - fixed two more typos where "ceil" should have been "floor"
        - refer to ARB_texture_rectangle as EXT_texture_rectangle
          (this may change back when/if back extension becomes ARB'ified)

    Date: 05/10/2003
    Revision: 0.8
        - additional additional names to contributors list
        - clarified language describing resolution of issues #9,10,11

    Date: 05/08/2003
    Revision: 0.7
        - very minor language update to overview section regarding
          exporting of ARB_texture_non_power_of_two string
        - fixed another two places where it said we should round up
          instead of down (in section 3.8.10 "Texture Completeness",
          and in section 3.8.8 "Texture Minification")
        - mark the regions of the spec affected by the decision to
          use separate strings per texture target with the "@" symbol.
          This is temporary until issue #3 is resolved.
        - resolved issues 9,10,11,12

    Date: 05/08/2003
    Revision: 0.6
        - updated revision history and coalesced revision notes from
          various specs
        - fixed typo in issue #5 ("2d" --> "non_power_of_two")
        - clarified the discussion in issue #3 as the langage was a
          little confusing in parts.
        - explicitly refer to the cube map targets in section 3.8.1
          instead of using the "made up" target TEXTURE_CUBE_MAP.

    Date: 05/06/2003
    Revision: 0.5
        - changed name of extension from ARB_texture_np2 to
          ARB_texture_non_power_of_two
        - added target specific extension strings
        - added more discussion to several issues based on feedback from
          the working group meetings
        - fixed several typos where INVALID_VALUE was INVALID_VALID
        - addressed typo in issue #6, it said you should round up,
          but really we agreed to round down when describing the mipmap
          stack (floor vs ceil convention).
        - resolved issues 1 - 8.

    Date: 04/24/2003
    Revision: 0.4 (jsandmel)
        - numbered issues list
        - additional discussion of several issues
        - added more explicit comparison of texture_rectangle and this
          proposal

    Date: 04/10/2003
    Revision: 0.3 (mjk)
        - integrates input from the ARB_texture_2d_np2 proposals.

    Date: 03/25/2003
    Revision: 0.1 (jsandmel)
        - draft proposal
        - deals with 2d targets only
        - named: ARB_texture_2d_np2