PDA

View Full Version : NPOT: difference between non_power_of_two_ARB vs texture_rectangle_ARB ?



speedy gonzalez
03-12-2006, 07:21 AM
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 ?

def
03-12-2006, 07:47 AM
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.

shelll
03-12-2006, 08:49 AM
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.

CrazyButcher
03-12-2006, 10:10 AM
ati supports the ext_rect version, too.

jide
03-12-2006, 10:37 AM
Originally posted by shelll:
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. Are you sure GLSL does not support NPOT textures ?

Overmind
03-12-2006, 12:52 PM
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.

zed
03-12-2006, 04:19 PM
"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( .. )

+ im assuming for NPOT u just use the standard texture2D( .. )

Korval
03-12-2006, 04:29 PM
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.

speedy gonzalez
03-12-2006, 06:20 PM
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 ?

shelll
03-12-2006, 08:47 PM
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 :( )

Overmind
03-12-2006, 11:59 PM
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...

CrazyButcher
03-13-2006, 12:26 AM
nevertheless it still sucks that while rect is supported on arb_fragment_program, it isn't in glsl

davej
03-13-2006, 03:20 AM
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

speedy gonzalez
03-13-2006, 04:42 AM
Thanks a lot everyone !

Your replies are very valuable.

Overmind
03-16-2006, 11:27 AM
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 ;)

shelll
03-16-2006, 11:33 AM
i think, that many people like non-normalized texcoords for special purposes. and ATi has poor NPOT support on pre x1000 series.

davej
03-16-2006, 12:34 PM
Originally posted by Overmind:
Yeah, of course... Whatever the marketing guys of nvidia say...
You know marketing people who can write documents like that! :)

Overmind
03-17-2006, 12:33 AM
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...

spasi
08-19-2006, 08:46 AM
Just FYI, ARB_texture_rectangle is now supported on ATI cards (Catalyst 6.8).

CrazyButcher
08-19-2006, 09:50 AM
yay =)

arekkusu
08-19-2006, 10:13 AM
Originally posted by davej:
Texture rectange seems particularly suited for compositing window systems.Precisely.


Originally posted by Overmind:
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... Perhaps you should try benchmarking texture upload speed, between for example 1024x1024 2D and RECT.

In other words, you don't know what the driver is twiddling the internal layout of the texture into in VRAM. The performance could be very different.

And, some people might actually depend on that performance difference. For example in a composited windowing system, it might be nice to allow the GPU direct DMA access from a CPU-side allocation, with no intermediate copies or twiddles.

Overmind
08-21-2006, 01:11 AM
The performance could be very different.What do you mean with *could* be different? Have you tested this?

If yes, have you tested this on a nVidia card only, or on an ATI card, too? I'm fairly certain that ATI implements RECT textures with regular NPOT textures, patching the shader to include a texcoord division.

I don't know how nVidia implements it, they always tend to favour special hardware over reusing programmable hardware. Still it would surprise me if there were any difference in upload speed between NPOT and RECT, at least on modern cards (I know RECT is a lot faster on GFFX cards, that's what I meant with backwards compatibility).

Btw.: Why would I want 1024 RECT? That's a POT format ;)

Jackis
08-21-2006, 07:02 AM
About the perfomance diff between RECT and 2D.

In our application for post-effects and some screen-effects and smooth depth-test we had to deal with uplarged 2D-screen and depth textures (for example, for 1280x1024 it was 2048x1024), and we had to do weird etxture coords remapping, also we had to deal with sub-pixel precision to get exact quad-to-screen textel mapping, all these half-texel offsets an so on. Also we had to clamp texture coordinates in the shader to not to get into black unfilled texture area.

When we migrated to texture rectangle, everything became much more easier and clearer. Clamping, exact texture mapping (using WPOS.xy semantics, for exmaple).

Also we did a perfomance test (nVidia cards only). We didn't find any resolution, where perfomance difference was noticeable. So, for our needs, the speed is quite the same.