samplerRECT ???

there is a non power of two texture sampler in Cg, but i dont see one in GLSL…

can i use the nvidia float buffer extensions (or, for that matter, any others) with GLSL to access npot 2D texture maps…?

From ARB_texture_rectangle:

Additions to the OpenGL Shading Language specification

Add the following keywords:
  samplerRect
  samplerRectShadow
Add to section 8.7 "Texture Lookup Functions"
  vec4 textureRect(samplerRect sampler, float coord)
  vec4 textureRectProj(samplerRect sampler, float coord)
No "bias" parameter is allowed because mipmaps are not allowed for
texture rectangles.

Why a shadowRect and a shadowRectProj weren’t added as well?

ARB_texture_rectangle --> To display NPOT images. Beware that the texture coordinates for NPOT textures range from [0…w], [0…h] rather than the POT [0…1] range.

Inside the pixel shader one can use:-

uniform samplerRECT <variable name>

texRECT(<texture Object>, <texCoords>)

Thats it!

I know this has been mentioned before but the ATI compiler doesn’t seem to know about textureRect and samplerRect…unfortunately, my app works with large numbers of 720x576 images, which I have to store in 1k*1k textures more than doubling their memory footprint.
Does anyone know if and when a fix for this might appear?

Cheers

Originally posted by mikef:
[b]I know this has been mentioned before but the ATI compiler doesn’t seem to know about textureRect and samplerRect…unfortunately, my app works with large numbers of 720x576 images, which I have to store in 1k*1k textures more than doubling their memory footprint.
Does anyone know if and when a fix for this might appear?

Cheers[/b]
Use nvidia :slight_smile: Seems that ATI doesnt support rectangle textures (or if it support it will use next POT texture that can match size). Im afraid that you have to wait until ATI release new hw gen.

On nvidia hw you may use PBO to speedup texture uploads.
720x576 looks like PAL video stream. Download my opengl video player from http://rttv.users.sbb.co.yu/VideoPlayer.zip (source and bin) and try it.

yooyo

ARB_texture_rectangle –> To display NPOT images. Beware that the texture coordinates for NPOT textures range from [0…w], [0…h] rather than the POT [0…1] range.
Note: Rectangle texutres are not the same as NPOT textures (as exposed from ARB_non_power_of_two_texture). NPOT is simply a lifting of the power-of-two restriction from all texture formats. Rectangle textures are a new type of texture, as different as 2D are from 3D or Cube textures. This is one reason why there is a separate sampler type for them, rather than just using the 2D one.

Originally posted by yooyo:
Seems that ATI doesnt support rectangle textures (or if it support it will use next POT texture that can match size). Im afraid that you have to wait until ATI release new hw gen.
I’m definitely regretting not doing enough research before buying my X800…I saw ‘EXT_texture_rectangle’ in the extension list and was stupid enough to assume that this indicates the driver actually implements the specification. Along with the lack of fbo and pbo, this makes this card a pretty stinky platform for video-processing (which is, as you guessed, what I’m trying to do).

I’d love to try out your movie-player, but it doesn’t run due to lack of support for several extensions. Sigh.

download again… I fix few things inside… :slight_smile:

yooyo

Originally posted by mikef:
I saw ‘EXT_texture_rectangle’ in the extension list and was stupid enough to assume that this indicates the driver actually implements the specification.
It does.

Originally posted by mikef:
[b]Along with the lack of fbo and pbo, this makes this card a pretty stinky platform for video-processing (which is, as you guessed, what I’m trying to do).

I’d love to try out your movie-player, but it doesn’t run due to lack of support for several extensions. Sigh.[/b]
FBOs will be supported. I know people have been waiting for this functionality a long time, but don’t forget that it was just recently ratified and it’s a very large spec.
For NPOTS, we support OpenGL 2.0 and you can use NPOTs through the GL2 interface. It’s recommended that you use this instead of rectangles anyway for performance reasons. Rectangles were originally speced around GF3 hardware, which had different limitations than our hardware.

Originally posted by Humus:
[quote]Originally posted by mikef:
I saw ‘EXT_texture_rectangle’ in the extension list and was stupid enough to assume that this indicates the driver actually implements the specification.
It does.
[/QUOTE]I couldn’t find an EXT_texture_rectangle spec in the registry, but I’m guessing from your reply that it doesn’t define GLSL behaviour. All I had to go on was the ARB tex rect spec which defined samplerRect and textureRect, and claims to be “functionally identical” to the EXT spec. Then again, it makes the same claim for NV_texture_rectangle which definitely doesn’t mention GLSL, but DOES support it (albeit using differently named types/functions).
Perhaps a spec should be added to the registry, and/or the ‘functionally identical’ claim removed from the ARB spec.

Anyways, apologies for the snotty tone of the previous post.

(edit)
PS: What’s the GL2 interface for NPOT textures? The driver doesn’t advertise ARB_texture_non_power_of_two so I assume it’s something else, but I couldn’t find any details.

You can use samplerRect and textureRect in GLSL on NV cards. You need newer drivers. Im using 76.10 and it works.

yooyo

What’s the GL2 interface for NPOT textures?
NPOT doesn’t define new types of textures, so there is no interface. You use them just like any other texture.

Rectangle needs an interface because it defines a specific type of texture, as separate from 2D textures as they are from 3D or cube maps.

There is a bug in the current ARB_texture_rectangle spec, the correct sampler types are:

sampler2DRect
sampler2DRectShadow

and the correct functions are:

texture2DRect
texture2DRectLod
texture2DRectProj
texture2DRectProjLod
shadow2DRect
shadow2DRectProj

Thanx jra101.

I was wondering why GLSL shaders with samplerRect work only on FW 76.10. I was forget to use sampler2DRect and shaders works only because of unified compiler.

yooyo

Originally posted by mikef:
I couldn’t find an EXT_texture_rectangle spec in the registry, but I’m guessing from your reply that it doesn’t define GLSL behaviour.
Here’s a spec:
http://developer.apple.com/graphicsimaging/opengl/extensions/ext_texture_rectangle.html

Originally posted by mikef:
PS: What’s the GL2 interface for NPOT textures? The driver doesn’t advertise ARB_texture_non_power_of_two so I assume it’s something else, but I couldn’t find any details.
Just check the GL_VERSION for 2.0 or higher, and if that’s the case, you can simply upload a NPOT texture as usual through glTexImage2D() etc. and use it as you’d a regular texture. It differs of course from rectangles in the way that it’s using normalized texture coordinates, like regular POT textures. Also, keep in mind that our hardware isn’t fully orthogonal when it comes to NPOT, but if you’re fine with the restrictions of rectangles you should get acceleration for NPOTs through GL2.0.

Originally posted by Humus:
FBOs will be supported. I know people have been waiting for this functionality a long time, but don’t forget that it was just recently ratified and it’s a very large spec.
True, but on the one hand you don’t start coding only when the spec is ratified, you code while the spec evolves. On the other hand, ATI has / had a hidden ATI_uber_buffer extension is their drivers, wherefrom functionality doesn’t differ too much, so they have a good base to start upon. Thirdly, the spec is so large mainly due to discussion and history, not because it’s to hard to implement. NVIDIA already has FBO support starting with their 79.10 drivers, so why is ATI always behind when it comes to OpenGL support? I think it would be just more honest if you said that in terms of company politics, OpenGL doesn’t play an important role to ATI (for consumer cards).

Originally posted by jra101:
[b]There is a bug in the current ARB_texture_rectangle spec, the correct sampler types are:

sampler2DRect
sampler2DRectShadow

and the correct functions are:

texture2DRect
texture2DRectLod
texture2DRectProj
texture2DRectProjLod
shadow2DRect
shadow2DRectProj[/b]

I’m confused. If the driver says it supports ARB_texture_rectangle and has GLSL support, does this mean these samplers and functions are available in GLSL?

What about EXT_rectangle_texture and GLSL?

I think the GLSL spec should be updated to that those are reserved keywords.

Originally posted by V-man:
I’m confused. If the driver says it supports ARB_texture_rectangle and has GLSL support, does this mean these samplers and functions are available in GLSL?
Depends entirely on the driver, I reckon. The GLSL part of this spec is so bug-ridden that if a driver stuck to implementing the spec as written, the GLSL portion would be basically unusable.

Eg, according to the spec you can only access samplerRects with a 1D texcoord, which defeats the purpose of using a 2D texture somewhat.

And the fact that sampler2DRect/texture2DRect are reserved keywords but samplerRect/textureRect are not does indeed suggest that the spec has got these names wrong.

What about EXT_rectangle_texture and GLSL?
Nope.
Although the ARB spec claims to be “functionally identical” and “semantically equivalent” to the EXT one, this is a major difference between the two.
Don’t suppose someone would like to (a) fix this claim, and (b) add EXT_texture_rectangle to the registry?

I think the GLSL spec should be updated to that those are reserved keywords.
I think they already are (except for the lod functions, which probably shouldn’t be in that list).
Ordinarily, this wouldn’t matter since they wouldn’t be exposed to a shader unless the explicitly enabled it by saying something like

#extension GL_ARB_texture_rectangle : enable

Of course, the spec ignored the extension-writing guide and says nothing about this, so your guess is as good as mine as to what actually happens.

Originally posted by eyebex:
NVIDIA already has FBO support starting with their 79.10 drivers, so why is ATI always behind when it comes to OpenGL support? I think it would be just more honest if you said that in terms of company politics, OpenGL doesn’t play an important role to ATI (for consumer cards).
I think you’re highly unfair here. First of all, you’re comparing a leaked beta to our offically supported and WHQL approved drivers. That our drivers don’t get leaked as much shouldn’t count against us. Second, it’s far from a rule that we’re always behind. It’s a pretty even split. Sometimes we’re ahead, sometimes nVidia are. It depends on what the management of the driver team decide is top priority at the moment. We’ve been ahead in many very important extensions. For instance GLSL. We were nearly 6 months ahead with official support IIRC. I even played with beta GLSL drivers already in late 2002/early 2003. We were first out with WGL_ARB_render_texture, VBOs and just recently, we were ahead of nVidia with OpenGL 2.0 support.