Back to the OpenGL extension cross reference
GL_ARB_texture_non_power_of_two
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, ATI Research, Inc (jsandmel 'at' ati.com)
Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
Notice
Copyright to be assigned to the ARB.
Status
Approved by the ARB on June 11, 2003.
Version
Date: May 14, 2004
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.
None
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 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
Implementation Support
List of OpenGL implementations supporting the GL_ARB_texture_non_power_of_two extension
Original File
Original text file for the GL_ARB_texture_non_power_of_two extension
Page generated on Sun Nov 20 18:37:02 2005