Feedback on the FBO specification needed!

Hello everyone!

Next Wednesday and Thursday is the quarterly ARB meeting and I was hoping to get some feedback from developers on the FBO specification that was released back in January. Now that you, hopefully, have some experience using FBOs can you please share your thoughts on the following:

  1. Are you currently using FBOs in your application(s)?
  2. What do you think was done right in the FBO spec?
  3. What do you think was done wrong in the FBO spec?
  4. Does any existing functionality need changing? If so, why?
  5. Are you missing any functionality?
  6. In your opinion, is the FBO specification ready for promotion into core OpenGL? If not, what would need to change?

Please try to separate implementation bugs and limitations from the functionality the specification offers. Implementations will catch up.

You can find the spec here: FBO specification

Thanks for taking the time to comment!

Regards,
Barthold
ARB Superbuffers workgroup chair

Hello!

I’m using FBO in my new framework and all in all I’m quiet happy with that API. The only thing I was missing is a function to get out the data of a renderbuffer like glGetTexImage for textures. Binding the renderbuffer to a framebuffer and then binding the framebuffer is IMHO not a good idea for doing that.

[EDIT] I don’t know if it is too offtopic here but what I’m really miss are global uniforms in the OpenGL Shading Language.

1: No. But that’s more because I don’t need to yet. I have poked around with the extension, however.

2: Everything that wasn’t done wrong.

3: I’m still a bit torn about the issue of the only way to directly access a renderbuffer is to use gl*Pixels operations when it is bound as the framebuffer, rather than having a mechanism to access them like textures with their own entrypoints.

However, I do disagree with the idea of passing this extension without some kind of mechanism for guarenteeing framebuffer completeness (ie, selecting a texture that will pass completeness on any implementation). It’s explained more in #6 below, but that is effecitvely my most important conceptual problem with the extension as it exists.

4: Maybe the renderbuffer issue I listed above.

5: Yes, but it is functionality that was explictly exempted from the spec. So I’m not sure if it would be best called “missing” or something else.

6: In my mind, no. Core promotion, to me, would require the existence (and the promotion) of the extension that allows us to select texture formats that are valid for the particular implementation. Without this, cross-platform development is substantially weakened. Whether this takes the form of new texture formats or an enumeration ability that allows us to select which format would be appropriate is ultimately irrelevant to the functionality itself.

Oh, and the extension that gives us depth/stencil buffers or texture formats would be really nice too.

I don’t know if it is too offtopic here but what I’m really miss are global uniforms in the OpenGL Shading Language.
OT or not, “global uniforms” would simply be giving the driver more work to do that you could easily write for yourself. Considering the current state of glslang implementations, I’d prefer that they spend more time on the stuff that they can fix rather than on helper utilities.

I don’t know if it is too offtopic here but what I’m really miss are global uniforms in the OpenGL Shading Language
sorry about the OT but for global uniform in glsl u can use the various light thingees eg set light6 ambient to a value + it stays that value until changed (no need to reset it for each shader)

There is one major issue that has prevented me from using FBOs: No support for a packed depth/stencil format and a depth/stencil attachment. I’m using stencil for shadows, so I can’t render a scene to a texture map using FBOs.

  1. Yes.
  2. Almost everything.
  3. Only RGB and RGBA based formats are “color-renderable” - there is no way to render into 1- and 2-channel textures. Currently, I didn’t need it, but it can be useful.
  4. See #3.
  5. No.
  6. See #3.
  1. Yes
  2. Everything
  3. Nothing
  4. No
  5. 1/2 channel textures need to be renderable. That’s what I’m missing the most. Also, antialiasing support and the stencil issue should be addressed.
  6. The spec is very good (except for the missing stuff), but I’d let the whole thing* mature a little more. There’s no need to rush.
  • spec, implementations, user usage
  1. yes for shadow mapping
  2. Nearly everything
  3. Nothing except #4 and #5
  4. need support for rendering to 1-component color texture
  5. depth/stencil texture attachment
  6. When the #4 and #5 get resolved, I think that everything is prepared for core implementation

Spasi is right, no need to rush.

  1. Yes.
  2. Almost everything.
  3. I agree with Korval that a way to guarantee framebuffer completeness is required. The current way you may have to try a lot a color format before getting a working one, this a bit the DirectX way of doing things :slight_smile:
  4. Need support for rendering to 1-component color texture, AFAIUC this is only an implementation issue at the moment, but probably OpenGL should REQUIRE 1-textures to be supported.
  5. RTVA, but AFAIUC it was left out by purpose.
  6. See 3,4.
  1. Not yet, but will certainly abolish PBuffers soon.

  2. Only few new Functions; glGenerateMipmaps; not too far off current hardware (so implementations can be efficient from beginning); nice to use; I like the idea behind framebuffer objects. Managing several collections of independend textures/renderbuffers would have been horrible.

  3. Took too long :slight_smile: Specs for deletion of renderbuffers/textureobjects that are currently attached to (multiple?!) framebuffers is not clear to me. Is it like for shader objects where the actual deletion is deferred until the last referencing programobject dies? Current specs say that the to-be-deleted renderbuffer gets detached from the current framebuffer, but not from all others (sounds a bit schizophrenic). But does the renderbuffer actually get deleted now or not? Will the other framebuffers refer to a deleted renderbuffer or what? I circumvented the problem by wrapping FBOs and renderbuffers, using a smartpointer-scheme for the renderbuffers and textures.

  4. FRAMEBUFFER_UNSUPPORTED_EXT leaves the programmer clueless. Specs proposed to try some other setup instead. But how would you actually do that without any hint on what went wrong? I propose a functionality that at least can give us a textual error description back (just as with GLSL). This could give us enough information to code another setup.

  5. Some function like D3D´s StrectRect().
    Stencil-Support (I mean, one that actually works on current HW). Support for one- and two-component colorbuffers. Multisampling. FBO-support on older HW that already supports PBuffers (especially GF3/4, R8500+).

  6. Not yet. Ask again next year. First let all complaints settle and implement the stuff I´m missing :slight_smile:

I would like to see single and double channel texture support addressed, it’s rather careless to leave it out of the spec IMO.

OT: BTW, what about the ABR meetings minutes of 2005?

  1. Yes
  2. Most stuff
  3. Specifying that color-renderable formats must be RGB or RGBA. 1 and 2 channel formats are very important, especially single channel rendering is very common.
  4. The interaction with the main framebuffer could be better. Currently you can’t for instance use the main depth buffer with a render target. In D3D you can do this.
  5. Yes. In order of importance: Multisampling, packed depth/stencil, 1/2 channel formats, being able to use depth buffers that are larger than the render target, so you can share one large depth buffer instead of creating multiple depth buffers for all render target sizes.
  6. With most of the changes above, yes.

I second the request for the ability to use the main depth buffer with an FBO render target.

  1. No, I only tried it out. It will soon go into my texture class.
  2. Corners were cut to avoid creating a overcomplicated spec. That’s the most important thing IMO.
  3. What others have said.

Issue 14:
Is it necessary to require that all the logical buffers of a framebuffer object have the same dimensions?

Can you relax this? How about querying GL if the driver supports using non-identical buffer sizes (glGetInteger).

  1. and 5) Nope. Rendering to RGBA8888 and RGBA(float) with depth24+stencil is typical for me.
  1. It should be regarded as the foundation brick.
    The API looks good to me.
    If multisample will be added in the future, you can do something like
glGetInteger(DO_YOU_SUPPORT_MS, &yes_or_no);

if(yes_or_no==GL_TRUE)
{
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8_2X_MULTISAMPLE, 512, 512, 0,GL_RGB, GL_INT, NULL);
}
else
{
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0,GL_RGB, GL_INT, NULL);
}

Also, we may need to call glGetError after the call to glGetInteger since it may raise an error for old drivers that don’t recognize the token. Anyway, I’m sure you’ll figure out something more elegant.

Specifying that color-renderable formats must be RGB or RGBA. 1 and 2 channel formats are very important, especially single channel rendering is very common.
That’s part of the spec?

< checks spec >

Hmm, aparently it is. Section 4.4.4. I’d always thought it was an implementation problem.

I’d like to append this to my list of grievances and reasons not to promote the extension to the core yet.

I am using it to great extent for different effects (shadows, blooms, reflections etc. etc.) and i would really really (and i say this from the very bottom of my heart :slight_smile: ) want to use the main depth buffer instead of manully having to attach one myself with each render target.

I am using FBOs, albeit for now only for very simple stuff, like compositing textures.

I also admit that I haven’t read through the lengthy specs, so I am not familiar with all the issues and the reasons behind certain design decisions.

However, I do know that in the long term, I would like to see OpenGL to be as window system independent as possible. This will also be increasingly important with future OSes (eg. Vista).

For one, I don’t want to be able to attach the real window’s depth and stencil buffers to my own FBO. In fact, I don’t even want such non-color buffers to be part of my window in the first place!! A window is just that, a window with an image to display. There should be no such thing as depth! I can’t see depth! Why would I attach it to a visible window? OpenGL understands depth, the window system doesn’t.

I would rather do all my rendering into my own FBOs, where I could use my own fancy format depth, stencil, aux buffers, and my own color buffers also in all kinds of weirdo formats that might not even be possible with real windows, because of some stupid OS limitation.

Then, when I’m all done, I would just attach one of my color buffers to the window (FBO zero), and let the driver do whatever it needs (copy, convert, etc) to get my image on the screen.

For me, the most important issue is attachable formats. That’s the whole point of escaping the OS, to be able to use fancy formats. I want to render to multisampled, multi-channel, floating point color buffers, vertex buffers, you get the idea.

Again, this is only my not so well educated opinion, so take it with a grain of salt :slight_smile:

I haven’t used it seriously yet, but overall it seems to work pretty well. However, I’d like to second this one:

Originally posted by V-man:
[b]Issue 14:
Is it necessary to require that all the logical buffers of a framebuffer object have the same dimensions?

Can you relax this? How about querying GL if the driver supports using non-identical buffer sizes (glGetInteger).
[/b]
I’m currently thinking about how to implement some nice and dynamic impostoring, and having to keep a separate depth buffer for each texture size seems to be a waste of good memory. It would be nice if it was possible to use a bigger buffer instead of an exact match.

Just relaxing the spec would be fine, that would leave it to the implementation whether it actually supports that behavior or not. A comment along the lines of “Bigger buffers can be tried, but are not guaranteed to work” would allow that. If the FBO setup fails the app would have to fall back to exact matches.

Just my .02$

  1. Yes. For shadow mapping and experimental work with deffered shading.
  2. It’s all pretty good, considering all the issues that went into the design of the spec. The examples section is particularly good, the examples are simple to follow, but showing useful functionality.
  3. Nothing at the moment.
  4. No
    5 & 6. I agree with Korval and Ratta that a way to select valid formats is important.