rectangular and npot textures

hey everybody, sorry for raising this chestnut, but i’m new to GLSL and so much has been said about this in the past that i’m still confused.

basically, if i’m using OpenGL 2.0 or higher, and effectively targeting nvidia cards, i can simply create a texture of arbitrary dimensions using GL_TEXTURE_2D and access it in a shader using texture2D, and there is no need to use GL_TEXTURE_RECTANGLE_NV or similar, and no need to use texture2DRect or similar, and no need to worry about texture coordinates not being normalised.

and finally, there is no efficiency gain in explicitly specifying a rectangular or npot texture.

is that correct?

cheers.

No.

OpenGL implementations version 2.0 and greater require have NPOT functionality. However, any efficiency gains that texture rectangles might or might not have is an entirely different matter.

NVIDIA above all has been pushing for the retention of texture rectangles, even while supporting regular NPOT. In contrast, ATI doesn’t much care for them and prefers NPOT directly. So there may be some efficiency gains from using texture rectangles, possibly if used as render targets or the like.

thankyou Alfonse,

some more questions…

…does your ‘No’ refer to the second part of my question only, regarding efficiency?

i guess what i’m asking is whether there is any practical difference between a texture2D and a texture2DRect, and i take your comments to mean that nvidia are reserving the right to optimize the latter. (i understand there’s some concern with nvidia exerting undue influence on the standard, but i’m not really in a position to care about that.)

also, whats the difference between a ‘texture rectangle’ and a regular NPOT?

and finally, does there remain any practical difference between a default texture2D initialized with arbitrary dimensions and an npot?

… also, can i assume these limitations still hold?

NPOTD textures support only the GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_CLAMP_TO_BORDER_ARB wrap modes; POTD textures support GL_CLAMP_TO_EDGE, GL_REPEAT, GL_CLAMP, GL_MIRRORED_REPEAT_IBM, and GL_CLAMP_TO_BORDER.

See the “Overview” section of http://www.opengl.org/registry/specs/ARB/texture_rectangle.txt

A regular NPOT texture behaves like a normal POT texture. A texture rect has non-normalized texture coordinates, does not support mipmapping and only the various clamp wrap modes.

The specification is not clear to me. Difference between NPOT and GL_TEXTURERECTANGLE_ARB, can you help at this :-

From the official specification

NPOTS textures are accessed by dimension-dependent (aka
non-normalized) texture coordinates. So instead of thinking of
the texture image lying in a [0…1]x[0…1] range, the NPOTS texture
image lies in a [0…w]x[0…h] range.

Then it says:

  1. Should 1D, 2D, 3D, or cube map textures be allowed to be NPOTS by
    this extension?
 No.  The ARB_texture_non_power_of_two extension relaxes the
 power-of-two restrictions for these conventional texture targets to
 support NPOTS while maintaining the normalized texture coordinates.

In the second extract it says that NPOT maintains normalized coordinates while in first it implies non-normalized.

Second confusion:

  1. How is the image of a rectangular texture specified?
 Using the standard OpenGL API for specifying a 2D texture
 image: glTexImage2D, glSubTexImage2D, glCopyTexImage2D,
 and glCopySubTexImage2D.  The target for these commands is
 GL_TEXTURE_RECTANGLE_ARB though.
 This is similar to how the texture cube map functionality uses the 2D
 texture image specification API though with its own texture target.
 The texture target GL_TEXTURE_RECTANGLE_ARB should also
 be used for glGetTexImage, glGetTexLevelParameteriv, and
 glGetTexLevelParameterfv.

If GL_TEXTURE_RECTANGLE_ARB is used then is NPOT = GL_TEXTURE_RECTANGLE_ARB???

Frankly, I am not able to distinguish between the two.

NPOTS textures are accessed by dimension-dependent (aka
non-normalized) texture coordinates. So instead of thinking of
the texture image lying in a [0…1]x[0…1] range, the NPOTS texture
image lies in a [0…w]x[0…h] range.

if thats from the NPOT spec then its wrong + needs to be fixed
are you sure youre not looking at GL_TEXTURERECTANGLE_ARB
if you aint tell us what page number + document its on

GL_TEXTURERECTANGLE_ARB = [0…w]x[0…h]
NPOTS = [0…1]x[0…1]

OpenGL implementations version 2.0 and greater require have NPOT functionality. However, any efficiency gains that texture rectangles might or might not have is an entirely different matter.

from my testing on nv4x theres no difference between the two WRT performance, POT sized textures though are ~10% quicker

@zed: The source is http://www.opengl.org/registry/specs/ARB/texture_rectangle.txt

First extract is from “Overview” and the second one from “Issues” listed as points.

The link I took is from Lord_crc 's post, in this thread.

POT sized textures though are ~10% quicker

Agree.

Yep, NV’s perf guide points out that with RECT you can save memory and that padding and mipmap construction may be obviated on texture upload, which is clearly a win for video processing.

Specifications are clear on this. You are mixing the two extensions:

ARB_texture_rectangle
ARB_texture_non_power_of_two

The first one is the first try in npot texture hardware support. It is limited for 2D textures, does not support mipmapping and some wrapping modes. In addition, texture coordinates for GL_TEXTURE_RECTANGLE_ARB target are not normalized and depend on texture dimensions.

The second extension provides the support of all kind of npot textures with mipmapping, all wrapping modes and may be fetched with normalized texture coordinates.

In conclusion, if your hardware supports the ARB_texture_non_power_of_two extension, use it, it is completely transparent.

Thank you dletozeun for the clarification.

thanks, thats awsome. confusing but awsome.

i don’t need or want mipmapping or GL_REPEAT and i’m alreaty using texture rectangles, so i’ll leave them be but i’ll do some profiling down the track a bit.

Hi, can anybody shed some light on this sentence from ARB_texture_rectangle specification please ?

“Should anything be said about performance?
No, but developers should not be surprised if conventional POTS textures will render slightly faster than texture rectangle textures.”

Does this mean that rectangle textures are slower than POTS textures ? Does anybody has any experience with this ?

It means exactly what it says. Rectangle textures may be slower than power-of-two. The specification describes behavior, not performance.

Yeah, I’ve kind of realized that…but seriously does anyone have experience with this ? If not I guess I will have to do the testing myself…

Re: [osg-users] NPOT textures - comments (2008):
“In the olden days when I’d have a texture that wasn’t power of 2 I’d use a POT (power of two) texture, update the parts of the texture that I was interested in and fix-up the texture coordinates accordingly. Nowadays I’m more inclined to use NPOT (non-power of two) or texture rectangles. Problem is every time I try to use NPOT textures I get nailed performance wise. If I use texture rectangles no problem - performance is as you’d expect…it just works.”

Re: [osg-users] OpenGL 2.0, NPOT textures and OpenSceneGraph (2007):
“While OpenGL 2.0 drivers support NPOT, not all hardware supports it, so you end up with a software fallback. Unfortunately in OpenGL there is no mechanism for detecting when software rendering will be used - its just happens to you, suddenly your framerate drops from 60hz down to 1Hz. The OSG has ended up be very conservative about using of NPOT because of this, it by default assumes that its not support in hardware…”

NPOT Textures (OpenGL Wiki):
"The R300 and R400-based cards (Radeon 9500+ and X500+) are incapable of generic NPOT usage. You can use NPOTs, but only if the texture has no mipmaps.

NV30-based cards (GeForce FX of any kind) are incapable of NOPTs at all, despite implementing OpenGL 2.0 (which requires NPOT). It will do software rendering if you try to use it."

That’s interesting to hear. Does such a card report the ARB extension then? Maybe that can be used to enable the feature if just checking for GL 2.0 is not enough.