PDA

View Full Version : FBO, ATI and rectangle textures



skynet
06-16-2005, 06:37 AM
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 ;-)

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?

Korval
06-16-2005, 10:43 AM
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.


2. Rectangle TexturesRectangular 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.

jra101
06-16-2005, 11:05 AM
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, TEXTURE_RECTANGLE,
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.

killerseven
06-16-2005, 12:15 PM
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?

NitroGL
06-16-2005, 12:23 PM
The 5.6 drivers have limited FBO support.

Humus
06-16-2005, 06:56 PM
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.


2. Rectangle TexturesI'd suggest sticking to NPOT.


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

skynet
06-17-2005, 03:33 AM
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?

bobvodka
06-17-2005, 06:42 AM
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 :)

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

NitroGL
06-17-2005, 10:14 AM
Originally posted by bobvodka:
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 :)

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 timeWell, 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.

fenris
06-17-2005, 10:18 AM
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 :) 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 :)

bobvodka
06-17-2005, 12:43 PM
Originally posted by NitroGL:
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.cheers for the info :)

SCOTTYC
06-18-2005, 11:17 AM
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.

spasi
06-18-2005, 11:38 AM
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.

NitroGL
06-18-2005, 01:05 PM
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).

Sunray
06-18-2005, 01:57 PM
Originally posted by spasi:
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.Hmm, GL_DEPTH_COMPONENT24/32 works fine for me (Radeon 9700 Pro).


glGenFramebuffersEXT(1, &amp;m_hFrameBuffer);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, m_hFrameBuffer);

// ColorBuffer
glGenTextures(1, &amp;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, &amp;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:

Humus
06-18-2005, 03:23 PM
Originally posted by fenris:
Here's my problem with that suggestion, and if I've missed something, by all means let me know :) 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 :) 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.

Humus
06-18-2005, 03:25 PM
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.

fenris
06-19-2005, 12:18 AM
Originally posted by Humus:
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.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?

spasi
06-19-2005, 01:59 AM
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.

Humus
06-19-2005, 11:12 AM
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.

skynet
06-20-2005, 12:43 AM
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.In my case I was waiting for FBO the last 6 months :-)
The only thing I was hoping for is to _finally_ have a single path on all cards for HDR and other postprocessing. Until now I was using render-to-pot-textures, because no render-to-rectangle/npot was available on ATI cards. This is a waste of videomemory and introduces other complications. NPOT textures are of course well to handle, but rectangle textures might have more advantages like being available on a broader range of gfx cards (especially older ones)and you can address neighbour pixels more easily.

Maybe we should start a poll on this, in order to see what the developers really want...

execom_rt
06-23-2005, 06:41 AM
Originally posted by Humus:
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.[/QB]Just tried FBO (on an ATI 9800 / Catalyst 5.6).

I had the same problem 'Red' and 'Blue' inverted.

I've tried 'internal_format' set to GL_RGB8 and 'texture_fromat' set to GL_BGR_EXT (instead of GL_RGB) and had an 'GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT' then after the glFramebufferTexture2DEXT

I've also tried floating point (HDR) cube maps and GLSL with FBO (instead of PBuffer), but the rendering was very broken.

Didn't test the rectangle textures with FBO yet.

Ah, also depth component FBO was not working (for rendering to depth buffer), but this was expected.

Else, on Catalyst 5.5, nothing was working : status was returning 0, which is not even a standard code.

I hope to see a better version next month.

Also a registry key to enable the GL_EXT_framebuffer_object would be also a good idea.

bobvodka
06-23-2005, 09:12 AM
a reg key isnt really required, most extension loading systems should allow you to force an extension to load (if it can find the right bind points, I know GLee allows you todo this), so just set that up and jobs a goodern.

execom_rt
06-23-2005, 09:34 AM
The reg key trick is usually used by nVidia, and I find it very convenient. Too bad. Also this allow some programs using FBO being tested (could be a good thing for ATI, if they want to test FBO extensively, there is a more and more program using it now).
I'm using glew + the glewExperimental flag that allowed me to load the extension properly.

Ah, also noticed that FBO + Multisampling simply doesn't work. Seeing that, I think I will wait next year for ATI + FBO now ;)

Korval
06-23-2005, 10:34 AM
Ah, also noticed that FBO + Multisampling simply doesn't work.FBO doesn't work with multisampling period. It's part of the spec that it doesn't do multisampling. They're working on some kind of extension to create multisample buffers or somesuch.

Humus
06-23-2005, 04:23 PM
Well, you can't multisample the render target, but it should work to use FBOs when you have multisample on the main framebuffer. Again, in early development (which is what you have in 5.6) there was an issue with this, but was fixed pretty soon.

execom_rt
06-24-2005, 01:20 AM
Yes, it was a multisampled primary buffer and single buffer FBO that I was talking about, and not multisampled FBO. Simply nothing is rendered. But apparently this will be fixed already.