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.
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.
…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.
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:
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:
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
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
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.
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.
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 ?
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.