Hello,
the extension non_power_of_two_ARB has first been created with the goal of relaxing the constraint of using power-of-two texture… great… then they created the texture_rectangle_ARB extension and it has the exact same goal but this time the semantic is completely different (ie: different target, different coordinates)… why ?
Why would one use the texture_rectangle extension ? Is it that the non-power-of-two extension comes with a cost of performance ?
GL_EXT_texture_rectangle or GL_NV_texture_rectangle have been there for a number of years.
Rectangular textures are supported on most hardware in contrast to NPOT textures.
I myself like to use rectangular textures when dealing with fullscreen quads because of the matching uv coordinates.
ATi does not support arb_texture_rectangle 
( which is the only one, that can be read from, in glslang shaders
ATi supports npot, but i don’t like them much, because of normalized texcoords. which are not the best for me in gpgpu.
ati supports the ext_rect version, too.
Originally posted by shelll:
[b] ATi does not support arb_texture_rectangle( which is the only one, that can be read from, in glslang shaders
ATi supports npot, but i don’t like them much, because of normalized texcoords. which are not the best for me in gpgpu. [/b]
Are you sure GLSL does not support NPOT textures ?
the extension non_power_of_two_ARB has first been created with the goal of relaxing the constraint of using power-of-two texture… great… then they created the texture_rectangle_ARB extension and it has the exact same goal but this time the semantic is completely different (ie: different target, different coordinates)… why ?
No.
The texture rectangle extension was created first. It has very strong limitations, like only no 3D textures, no mipmapping, limited filter modes and so on… This was because hardware wasn’t (and to some extent still isn’t) capable of doing better.
Then they made the NPOT extension as an improvement, it has no limitations, it just releases the power of two constraint.
So if you have hardware that is capable of using NPOT, use it. There should be no performance penalty. If you don’t have the hardware, you have no other choice but to use texture rectangle.
“Are you sure GLSL does not support NPOT textures?”
my hardware doesnt support them so i havent tested but i cant see why it wouldnt support them, for texture_rectange u use
textureRect( … )
Non-Power-Of-Two textures are exactly that: textures that are not restricted in being powers of two in size.
Rectangle textures are an entirely different kind of texture. They are as different from a 2D texture as a 2D texture is from a cube map.
A rectangle texture isn’t just an attempt to be NPOT; it is a specialized texture format that is indexed by non-normalized texture coordinates. It is uniquely useful as framebuffer render targets, as well as GPGPU programming.
OK, it’s just that the non-power-of-two extension has been approved by the ARB in june 2003, written against OpenGL 1.4. Now I thought that when an extension is approved by the ARB and is written against a given OpenGL version that means it automatically becomes part of the next OpenGL version. ? so that would mean that every graphic driver supporting OpenGL 1.5 and above would support NPOT
If so then I am confused because the rectangle extension has been approved one year later by the ARB, this time written against OpenGL 2.0 so against a version that already supports NPOT. In the spec the first thing they say is:
<<OpenGL texturing is limited to images with power-of-two dimensions and an optional 1-texel border. The ARB_texture_rectangle extension adds a new texture target that supports 2D textures without requiring power-of-two dimensions.>>
So this is why I am confused…
But if the value of the rectangle extension resides more in its support for non-normalized coordinates than in its support for NPOT then it starts to make sense…
Or maybe the non-power-of-two extension is still an extension not yet part of the standard even in OpenGL1.5, 2.0, … so NPOT might still not be supported by some drivers ?
jide: i see, i wasn’n clear enough. i meant, that the arb extension is the only one frome rectangles (NV/EXT/ARB), which adds support for glslang (sampler2Drect, texture2DRect). NPOTS are of course supported by glslang. they are “simple” texture_2d.
ATi supports only the EXT version of rectangles, so no glslang support. what brings some difficulties into gpgpu.
npot is part of ogl 2.0 core. ATi doesn’t expose the extension at all, just with saying, that the card is ogl 2.0.
ATi(maybe nVidia too) supports npots on older HW, but with same limitations as rectangles (of course, if you want them accelerated. you can use mipmaps, but it will run in SW running slow as hell )
A rectangle texture isn’t just an attempt to be NPOT; it is a specialized texture format that is indexed by non-normalized texture coordinates. It is uniquely useful as framebuffer render targets, as well as GPGPU programming.
That’s not correct. The rectangle texture was “just” made in an attempt to be NPOT. It is the way it is now because that’s how nvidia hardware at that time looked. Non-normalized texture coordinates are not intended as a feature, they are (were) a requirement of the hardware…
ATI never had that restriction, they always had to emulate the behaviour it in their drivers. From their point of view, the rectangle extension is a design error, and as soon as the real NPOT appeared, they abandoned it…
That’s why I think it’s unlikely that the ARB version of it will ever be supported by ATI. It is deprecated, and it should remain so…
I also don’t see why it would be important for GPGPU to have rectangle textures. After all, it’s just a single division to convert texture coordinates, a division that would have been inserted into the code by the ATI driver anyway…
Now I thought that when an extension is approved by the ARB and is written against a given OpenGL version that means it automatically becomes part of the next OpenGL version.
No, some ARB extensions will most likely never make it into core OpenGL (for example the texture rectangle extension). NPOT is part of core OpenGL since version 2.0.
The ARB texture rectangle extension may have been approved by the ARB later than NPOT, but NV and EXT versions are older…
nevertheless it still sucks that while rect is supported on arb_fragment_program, it isn’t in glsl
This document on Non-Programmable Additions to OpenGL, http://www.opengl.org/about/arb/notes/np20rationale.pdf , has a bit about the reasons for both extensions.
Texture rectange seems particularly suited for compositing window systems.
dave j
Thanks a lot everyone !
Your replies are very valuable.
Yeah, of course… Whatever the marketing guys of nvidia say…
It always amazes me how good marketing can turn a bug into a feature and make addititional profit out of it 
i think, that many people like non-normalized texcoords for special purposes. and ATi has poor NPOT support on pre x1000 series.
Originally posted by Overmind:
Yeah, of course… Whatever the marketing guys of nvidia say…
You know marketing people who can write documents like that!
shelll, that’s exactly what I meant with turning a bug into a feature.
The nvidia cards that are at the same technology level than the ATI cards you speak of have no NPOT support at all, while ATI has at least partial NPOT support, with the same restrictions as RECT.
Now ATI gets the blame for not supporting ARB_RECT, while normally nvidia should get the blame for not supporting partial NPOT.
When a new extension appears that can do everything the old one does with the same performance, and more, then there is no reason to keep the old one around except backwards compatibility…
Just FYI, ARB_texture_rectangle is now supported on ATI cards (Catalyst 6.8).
yay =)
