FBO, ATI and rectangle textures

Yesterday I tried FBO for the first time. I must say: straight forward and easy API!

Standard RTT was implemented rather quickly, after that I tried some more “delicate” setups. Here are some findings and questions:

  1. NPOT
    NPOT worked out of the box. Just give your framebuffer npot-dimensions and it magically works. Downside: its so slow that you can´t use it. I obviously hit some software emulation path.
    I knew that ATI does not support ARB_npot fully, but AFAIR Humus stated that you can get some kind of npot on current ATI cards (I got a R9800). My question is: what precautions do I have to take in order to get hw-accerlerated NPOT textures on my ATI card?

  2. Rectangle Textures
    My card exposes “EXT_texture_rectangle”. So I wanted to give it a try. Unfortunately FramebufferTexture2DEXT() returns GL_INVALID_OPERATION if I use GL_TEXTURE_RECTANGLE_EXT as texture target.

  3. Render-to-Depth Texture
    I just tried to setup a framebuffer and see what happens. So I created a texture with GL_DEPTH_COMPONENT as internal format and attached it to the DEPTH_ATTACHMENT point. No color-attachment was set. After setting the drawbuffer to GL_NONE, the framebuffer was considered ‘complete’.
    Actually I did not try to use that buffer. I leave that as exercise for the reader :wink:

  4. Stencil Attachments.
    I tried to attach a stencil-renderbuffer to the STENCIL_ATTACHMENT point. Surprisingly I got ‘unsupported’ completness. Does that mean, one can´t use stencil buffers for offscreen rendering?

  5. Render-to-Float texture
    Worked as expected. Just set the internal format of the texture to one of the ARB_float_texture formats. Of course there are still the usual limitations like having no blending.

Well, to sum it up: FBO is really nice, but how to get render-to-rectangle/npot working (and hw-accelerated!) on ATI cards?

My question is: what precautions do I have to take in order to get hw-accerlerated NPOT textures on my ATI card?
Don’t use MipMaps.

  1. Rectangle Textures
    Rectangular textures are not 2D textures. They are their own texture type. So, until FBO gets extended with an entrypoint for them, you can’t use them with FBO.

Originally posted by Korval:
Rectangular textures are not 2D textures. They are their own texture type. So, until FBO gets extended with an entrypoint for them, you can’t use them with FBO.
The EXT_framebuffer_object extension already supports rectangle textures.

For FramebufferTexture2DEXT, if <texture> is not zero, then
<textarget> must be one of: TEXTURE_2D, [b]TEXTURE_RECTANGLE[/b],
TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z.

Am I right in thinking you have OpenGL Framebuffer Objects working on an ATI card?

I didnt think they had released drivers that supported them yet…

Do the Cat 5.6 drivers enable them?

The 5.6 drivers have limited FBO support.

Originally posted by skynet:
what precautions do I have to take in order to get hw-accerlerated NPOT textures on my ATI card?
Avoid mipmaps and GL_REPEAT.

  1. Rectangle Textures
    I’d suggest sticking to NPOT.
  1. Stencil Attachments.
    I tried to attach a stencil-renderbuffer to the STENCIL_ATTACHMENT point. Surprisingly I got ‘unsupported’ completness. Does that mean, one can´t use stencil buffers for offscreen rendering?
    Stencil is a bit tricky. The FBO spec is more flexible than the hardware. The hardware wants depth and stencil together in a D24S8 format. Since depth and stencil renderbuffers are created independently and you can freely swap depth and stencil attachments as you like this is hard to implement. There has been talks within the ARB to make special D24S8 renderbuffers, but I’m not sure what turned out of that.

Stencil is a bit tricky. The FBO spec is more flexible than the hardware. The hardware wants depth and stencil together in a D24S8 format. Since depth and stencil renderbuffers are created independently and you can freely swap depth and stencil attachments as you like this is hard to implement. There has been talks within the ARB to make special D24S8 renderbuffers, but I’m not sure what turned out of that.
That´s what I was thinking when the FBO specs came out. But I expected that it would be solved “behind the scenes” somehow (I guess those ‘intrinsic buffers’ are related to this subject). Maybe the ARB should introduce a new attachment point, like “DEPTH_STENCIL_ATTACHMENT_EXT” and provide new internalformats for renderbuffers, like DEPTH24_STENCIL8_EXT. Would be easy to integrate and easy to use.

Anyway, will the final ATI implementation of FBO also support TEXTURE_RECTANGLE_EXT as texture target for attached textures?

Originally posted by NitroGL:
The 5.6 drivers have limited FBO support.
ah, that could be usefull, the entry points have been in for some time but lack of presence in the extension string didnt fill me with hope :slight_smile:

Any word on how limited they are? For example, any chance of being able to use them and GLSL for MRT output? (standard 32bit or floating point)

I’d check myself but I’m kinda busy atm and dont have the time

Originally posted by bobvodka:
[b]ah, that could be usefull, the entry points have been in for some time but lack of presence in the extension string didnt fill me with hope :slight_smile:

Any word on how limited they are? For example, any chance of being able to use them and GLSL for MRT output? (standard 32bit or floating point)

I’d check myself but I’m kinda busy atm and dont have the time[/b]
Well, from my testing…
No RGB[A]16 rendering
No cube map textures
No rectangle textures
FSAA causes a system lock up (on my machine at least)

Normal 2D textures work, as does floating point textures (all formats). I didn’t try MRT, but it might work.

I’d suggest sticking to NPOT.
Here’s my problem with that suggestion, and if I’ve missed something, by all means let me know :slight_smile: I think ATI should just support ARB_texture_rectangle and add the rect sampling support to GLSL that this extension includes. It would make our lives, the developers, a HELL of a lot easier. As it is now with my current project, I target DX9 level HW. Using NPOT would be fine, except the NV3x line of cards fall in this category, and do not support them. They do support texture rects, as do all ATI cards (EXT_texture_rectangle). ATI can’t sample rects in GLSL due to missing ARB_texture_rectangle support. So now I have to have 2 versions of any shader that does anything with framebuffer post-processing effects (which I have a lot of). One for NPOT (texture2D) and one for RECTs (texture2DRect). This is very frustrating, and it’s even more frustrating to know that I could just use ARB_texture_rectangle if ATI would support it. My other problem with this is ATI doesn’t even expose NPOT support through the extension strings. So detecting support for NPOT so that I can do a dual NPOT/Rect path is made difficult. I could parse the version string for 2.0, but on linux this is a no go. ATI linux drivers seem to be permenantly stuck at 1.3, with no signs of that ever chaning. So I’m completely screwed :slight_smile:

Originally posted by NitroGL:
[b]Well, from my testing…
No RGB[A]16 rendering
No cube map textures
No rectangle textures
FSAA causes a system lock up (on my machine at least)

Normal 2D textures work, as does floating point textures (all formats). I didn’t try MRT, but it might work.[/b]
cheers for the info :slight_smile:

It was mentioned that the ATI Catalyst 5.6 drivers have limited FBO support. Can someone elaborate on this? GL_EXT_framebuffer_object is not returned from glGetString(GL_EXTENSIONS). I tried to get a function pointer to glBindFrameBufferEXT anyway with wglGetProcAddress and it returns NULL. I couldn’t find anything in the Catalyst release notes either. It this documented somewhere? Thanks for any info.

I’m generally satisfied from my tests, except a couple of cases (I’d appreciate it if someone could confirm, I’m testing on R300s):

  • No GL_DEPTH_COMPONENT24 support (INCOMPLETE_ATTACHMENT), GL_DEPTH_COMPONENT16 works fine.

  • LUMINANCE, ALPHA and LUMINANCE_ALPHA fp formats (either 16F or 32F) do not work. I haven’t tried the 8bit ones.

Originally posted by SCOTTYC:
It was mentioned that the ATI Catalyst 5.6 drivers have limited FBO support. Can someone elaborate on this? GL_EXT_framebuffer_object is not returned from glGetString(GL_EXTENSIONS). I tried to get a function pointer to glBindFrameBufferEXT anyway with wglGetProcAddress and it returns NULL. I couldn’t find anything in the Catalyst release notes either. It this documented somewhere? Thanks for any info.
No, it’s not documented anywhere, because it’s not fully tested, thus not exposed. Reason you get a NULL return is because it’s not glBindFrameBufferEXT, it’s glBindFramebufferEXT.

It’s pretty limited support… Also forgot to mention that depth buffers do not work (I knew I was forgetting something).

Originally posted by spasi:
[b]I’m generally satisfied from my tests, except a couple of cases (I’d appreciate it if someone could confirm, I’m testing on R300s):

  • No GL_DEPTH_COMPONENT24 support (INCOMPLETE_ATTACHMENT), GL_DEPTH_COMPONENT16 works fine.
  • LUMINANCE, ALPHA and LUMINANCE_ALPHA fp formats (either 16F or 32F) do not work. I haven’t tried the 8bit ones.[/b]
    Hmm, GL_DEPTH_COMPONENT24/32 works fine for me (Radeon 9700 Pro).
	glGenFramebuffersEXT(1, &m_hFrameBuffer);
	glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, m_hFrameBuffer);

	// ColorBuffer
	glGenTextures(1, &m_hColorBuffer);
	glBindTexture(GL_TEXTURE_2D, m_hColorBuffer);
	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, Width, Height, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0x0);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
	glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, m_hColorBuffer, 0);

	// DepthBuffer
	glGenRenderbuffersEXT(1, &m_hDepthBuffer);
	glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, m_hDepthBuffer);
	glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT24, Width, Height);
	glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, m_hDepthBuffer);

One thing though… R and B gets swapped when rendering to this FBO and render a screen-space quad with that texture. :eek:

Originally posted by fenris:
Here’s my problem with that suggestion, and if I’ve missed something, by all means let me know :slight_smile: I think ATI should just support ARB_texture_rectangle and add the rect sampling support to GLSL that this extension includes. It would make our lives, the developers, a HELL of a lot easier. As it is now with my current project, I target DX9 level HW. Using NPOT would be fine, except the NV3x line of cards fall in this category, and do not support them. They do support texture rects, as do all ATI cards (EXT_texture_rectangle). ATI can’t sample rects in GLSL due to missing ARB_texture_rectangle support. So now I have to have 2 versions of any shader that does anything with framebuffer post-processing effects (which I have a lot of). One for NPOT (texture2D) and one for RECTs (texture2DRect). This is very frustrating, and it’s even more frustrating to know that I could just use ARB_texture_rectangle if ATI would support it. My other problem with this is ATI doesn’t even expose NPOT support through the extension strings. So detecting support for NPOT so that I can do a dual NPOT/Rect path is made difficult. I could parse the version string for 2.0, but on linux this is a no go. ATI linux drivers seem to be permenantly stuck at 1.3, with no signs of that ever chaning. So I’m completely screwed :slight_smile:
Well, NV3x cards support GL 2.0, so they should support NPOT. Are you saying it’s not hardware accelerated, even for the case where you have no mipmaps and GL_CLAMP_TO_EDGE? In that case I could use your own arguments for why nVidia should fix that instead. And I could add the argument that NPOT is the way to go for the future anyway and rectangles will likely get depricated at some point when NPOT support has filled the market.

Either way, if you’re going for a single path, someone’s getting screwed no matter what. Rectangles are built around nvidia hardware, while our’s is built around NPOT. Someone will have to modify the shader on the fly to scale the texture coordinates.

As for the Linux problem, I’ll bring that up with the Linux guys. Though you can detect it by simply trying to update like a 3x3 texture and check if you got a GL-error.

Originally posted by Sunray:
One thing though… R and B gets swapped when rendering to this FBO and render a screen-space quad with that texture. :eek:
This was a problem in the early stage of development, which is what you have in 5.6, but was fixed soon after. Simply using GL_BGRA instead should fix it.

Originally posted by Humus:
[b]Well, NV3x cards support GL 2.0, so they should support NPOT. Are you saying it’s not hardware accelerated, even for the case where you have no mipmaps and GL_CLAMP_TO_EDGE? In that case I could use your own arguments for why nVidia should fix that instead. And I could add the argument that NPOT is the way to go for the future anyway and rectangles will likely get depricated at some point when NPOT support has filled the market.

Either way, if you’re going for a single path, someone’s getting screwed no matter what. Rectangles are built around nvidia hardware, while our’s is built around NPOT. Someone will have to modify the shader on the fly to scale the texture coordinates.

As for the Linux problem, I’ll bring that up with the Linux guys. Though you can detect it by simply trying to update like a 3x3 texture and check if you got a GL-error.[/b]
I understand NPOT is the way to go in the future, but I still don’t get why ATI can’t support ARB_texture_rectangle. They have EXT_texture_rectangle support and it works just fine. I can sample rects in ARB_fragment_program as well. All they have to do is add GLSL support and then they can say they have ARB_texture_rectangle support. Is that asking too much?

Originally posted by Sunray:
Hmm, GL_DEPTH_COMPONENT24/32 works fine for me (Radeon 9700 Pro).
Sorry, I wasn’t too clear, I meant when rendering-to-depth-texture. Depth render buffers work fine here too.

Btw, I completely agree with what fenris has said so far. And I also agree with Humus that NV should support NPOT textures on older hardware, it was a good move by ATI.

Originally posted by fenris:
[QBI understand NPOT is the way to go in the future, but I still don’t get why ATI can’t support ARB_texture_rectangle. They have EXT_texture_rectangle support and it works just fine. I can sample rects in ARB_fragment_program as well. All they have to do is add GLSL support and then they can say they have ARB_texture_rectangle support. Is that asking too much?[/QB]
Well, it can certainly be done. Question is if we should prioritize this over other stuff. It’s a bit like implementing GL_EXT_compiled_vertex_array after VBO’s have become available. There’s little incentives to spend engineering resources to implement a slower path than what we already have, in particular if that will give us a disadvantage compared to the competition. There would have to be a large enough demand for the feature, which doesn’t seem to be the case. The last 6 months or so I don’t think I’ve had anyone asking for it.