PDA

View Full Version : Feedback on the FBO specification needed!



barthold
09-09-2005, 02:24 PM
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 (http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt)

Thanks for taking the time to comment!

Regards,
Barthold
ARB Superbuffers workgroup chair

Corrail
09-09-2005, 03:01 PM
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 (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=11;t=000818) in the OpenGL Shading Language.

Korval
09-09-2005, 04:36 PM
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.

zed
09-09-2005, 10:33 PM
I don't know if it is too offtopic here but what I'm really miss are global uniforms in the OpenGL Shading Languagesorry 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)

Eric Lengyel
09-09-2005, 10:35 PM
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.

grisha
09-09-2005, 10:38 PM
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.

spasi
09-09-2005, 11:53 PM
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

Matt Zamborsky
09-10-2005, 06:30 AM
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.

ratta
09-10-2005, 07:12 AM
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 :)
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.

skynet
09-10-2005, 07:24 AM
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 :) 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 D3Ds 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 Im missing :-)

NitroGL
09-10-2005, 08:33 AM
I would like to see single and double channel texture support addressed, it's rather careless to leave it out of the spec IMO.

ratta
09-10-2005, 08:46 AM
OT: BTW, what about the ABR meetings minutes of 2005?

Humus
09-10-2005, 02:17 PM
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.

Eric Lengyel
09-10-2005, 04:40 PM
I second the request for the ability to use the main depth buffer with an FBO render target.

V-man
09-10-2005, 04:56 PM
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).

4) and 5) Nope. Rendering to RGBA8888 and RGBA(float) with depth24+stencil is typical for me.

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

Korval
09-10-2005, 07:09 PM
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.

Zulfiqar Malik
09-10-2005, 08:57 PM
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 :) ) want to use the main depth buffer instead of manully having to attach one myself with each render target.

andras
09-11-2005, 06:32 AM
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 :)

Dirk
09-11-2005, 02:59 PM
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:
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).
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$

Foobarbazqux
09-11-2005, 07:35 PM
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.

ffish
09-11-2005, 09:13 PM
1. Yep. For screenshots, GPGPU and some buffering work. Mostly experimental until implementations catch up.
2. I'm happy with all of it.
3. Nothing major.
4. I'd be happy if implementations supported depth/stencil according to the spec instead of having to wait for a future extension (like the NV_packed_depth_stencil or whatever it's called).
5. Depth/stencil.
6. Not yet. Reasons already given by others.

Overmind
09-12-2005, 01:43 AM
1. Yes.
2. Everything except 3, 4 and 5 ;)

3. I don't like the seperate behaviour of framebuffer 0. IMHO special renderbuffers for on screen content would be better. Framebuffer 0 should simply default to all onscreen buffers bound, so when you don't change it, you still have the same behaviour as now, but then you could mix on- and offscreen renderbuffers. That would be no additional burden for hardware that can't support it, because it can still return UNSUPPORTED if you make an illegal combination of on- and offscreen buffers.

4. The UNSUPPORTED mechanism is a bit complicated to use. But I don't have an idea how to do it better ;)

5. The ability to share buffers between an FBO and the onscreen buffer. Especially for the depth buffer this would be nice, I can think of many situations where I need the same depth data in both the on- and offscreen depth buffers.

6. No. I'd definitely prefer onscreen renderbuffers instead of an onscreen framebuffer, but this should be tested before going into core.

Dark Photon
09-12-2005, 03:44 AM
Yes Very simple to use Undocumented, vendor-specific tricks needed to get better performance than render-to-framebuffer/ copy-to-texture.
Perhaps suggest the recommended way (via example) to use multiple depth buffers (to avoid losing early Z), to render to multiple texture resolutions (separate or same FBO), etc. Let the vendors discuss this and document in the spec how developers can make the best use of their hardware. No. #1: Multisampling, #2: Packed depth/stencil (with MS), #3: 2 component textures Not yet. After the above are supported, perhaps.

zeroprey
09-12-2005, 07:57 AM
I use it and its great. Good job guys!

Negatives: I don't see why there are actual framebuffer objects. It's recommended for better performance to keep with just one fbo and bind renderbuffers and textures to it. I don't see the need to have different fbo's. In my code right now I have just one fbo that I bind things to and it acts like a enable disable instead of a object. I think this adds unneeded complexity to the extension and its without much gain. It also implies the use of many fbos for better performance when that is not the case.

If this performance characteristic is incorrect or will be changing please let me know. Otherwise I think its a valid point.

Korval
09-12-2005, 09:28 AM
If this performance characteristic is incorrect or will be changing please let me know. Otherwise I think its a valid point.No, it is not.

The performance characteristic is not part of the spec. How well it performs is an implementation matter, not a matter of the spec itself.

Plus, the characteristic you describe is documented only for nVidia hardware. I haven't heard either way about how ATi handles changing FB objects.

Cab
09-12-2005, 11:43 AM
1. Yes. Currently for shadow mapping.
2, 3. I read it some months ago and I don't remember the details, but I remember I liked it.
4. Don't remember any.
5. An antialising option. I have not need it but I agree with people that it will be good to render to one/two component textures, and some of the other ideas.

Hope this helps

barthold
09-12-2005, 02:47 PM
Thanks all, this is great feedback to have! Please keep posting your comments and ideas. Tomorrow night I'm going to summarize it and present it at the ARB meeting Wednesday. It'll help us decide what to work on next.

Barthold

jonhjelm
09-13-2005, 01:59 AM
I agree with most suggestions here:
1 and 2 component textures would be great, though this could be solved in a separate extension which allows red and red/green textures.
Packed depth/stencil is useful.

I also believe that it would be useful to allow glReadBuffer(GL_NONE) also for window-system-provided framebuffers. As it is now there are no arguments to glReadBuffer that are allowed both for window-system-provided framebuffers and for application-created framebuffer object. Of course this modification will not allow any features that are not already possible with the current version of the FBO specification.

Jackis
09-13-2005, 03:27 AM
Yes, I use it for rendering reflections, building impostors, motion blurring and for shadow effects.

The spec is very good. I spent several hours reading it, but as a result I got total understanding of all the issues. As somebody said here, I think, that some of the issues are too complicated for unprepared readers and creation history takes too many text space (variations about why did you prefer such a name or method instead of another name).

About disadvantages: glGenerateMipmapExt must be unique extension, because it's implementation doesn't affect FBO routines, and this function is very helpful in many other cases (for exmaple, when I change texture interior 10 times a frame, I don't need to calculate mipmap chain 10 times, as generate_mipmap_sgis does).

Also, I hope, that "RGB/RGBA internal format based" limitation will be not so crucial in future, 1 or 2 component rendering is very useful also (for example, dUdV screen displacement texture creation).

About packed depth/stencil - it is also very useful, I hope, you will support it.

And waiting for full stencil support...

Dark Photon
09-13-2005, 05:35 AM
zeroprey:
Negatives: I don't see why there are actual framebuffer objects. It's recommended for better performance to keep with just one fbo and bind renderbuffers and textures to it. I don't see the need to have different fbo's. ...It also implies the use of many fbos for better performance when that is not the caseNot quite. On NVidia's FBO implementation, this "is" the case (but only under some circumstances): FBO Performance (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=013496)

If anything this may suggest that there is too much flexibility in the spec. I see Korval's point about not documenting performance 'requirements' in the extension, but there is enough flexibility that each vendor can choose their own fast path through the extension, leaving more of the burden to the vendors to tell developers what that is so their hardware will compare favorably, and to developers who are left to the "if Vendor1 then ... elif Vendor2 ... elif ..." routine.

However, OpenGL has always been this way. Adapting to changes in fast paths is just part of the job.

API
09-14-2005, 09:41 AM
Hi i'm using FBO, and i think that this is a good extension, but there are a "broken point":
FRAMEBUFFER_UNSUPPORTED_EXT leaves the programmer clueless, and the fact that FBO only works for some combination of internal formats, dependent on implementation, but you can't know which internal format is valid. The only way i know is try the possible combinations (please, if there are another way tell me!!!).

I know that this is a little off-topic, but, when the spec say that there must be at least one combination supported, this includes GL_TEXTURE_2D and GL_TEXTURE_3D? If there are a supported combination for GL_TEXTURE_2D but not for GL_TEXTURE_3D, the implemetation is correct?

I make this question because with my Geforce5900FX i don't find a internal format for use FBO with GL_TEXTURE_3D.

barthold
09-20-2005, 06:31 PM
All,

Thanks again for the excellent feedback. We discussed your feedback at the ARB meeting last week, and prioritized what we'll work on next. As you probably know from my Siggraph BOF presentation we've already been working on three other specifications that augment the FBO spec. Those are:

1. EXT_packed_depth_stencil. This is a modified version of the existing NV_packed_depth_stencil extension to allow a) creation of a packed depth_stencil texture and b) to attach this texture to a FBO. This specification is done, and should be in the extension registry any moment.

2. EXT_framebuffer_multi_sample. This extension allows the creation of multi-sample render buffers. These can be attached to a FBO to create a target for multi-sample rendering. This extension is essentially done, but is useless without the next one. Which brings me to:

3. EXT_framebuffer_blit. This extension allows for a stretch blit between framebuffer objects. The blit can also downsample from a multi-sample FBO to a single-sample FBO. This extension is work in progress.

Once we have these three extensions done, we'll work on:

1. allowing rendering to 1 and 2-component textures
2. allowing mixed size attachements to a FBO
3. defining some API that, if used, guarantees that the combination of images attached to a FBO will be supported by the OpenGL implementation.

After the above work we'll look at the other suggestions made in this thread. Expect to see some more revisions to the FBO specification during this work.

Regards,
Barthold
superbuffers WG chair

skynet
09-20-2005, 10:09 PM
Excellent news!
Thank you.

Korval
09-21-2005, 10:34 AM
3. EXT_framebuffer_blit. This extension allows for a stretch blit between framebuffer objects. The blit can also downsample from a multi-sample FBO to a single-sample FBO. This extension is work in progress.So, in order to do multisampled rendering, we render to a multisample FBO, then do a blit to some other FBO? Is it possible to blit to FBO's that have textures as their destination renderbuffer?

spasi
09-22-2005, 02:48 AM
Originally posted by Korval:Is it possible to blit to FBO's that have textures as their destination renderbuffer?EXT_framebuffer_blit sounds a lot like D3D's StretchRect() function, so, it has to be possible.

Matt Zamborsky
09-22-2005, 05:29 AM
I'm thinking about, for what there will be WGL/GLX/... in the future? When we have EXT_packed_depth_stencil, EXT_framebuffer_multi_sample,
EXT_framebuffer_blit, we dont need OS specific code at all. We need only a rectangle, where we blit the final downsampled image. Ofcourse the drawing to this rectangle must be very fast.
Only one problem is backward compatibility. But I think this will be a good step to reduce OS dependency.

barthold
09-22-2005, 09:55 AM
Hi Korval,


Originally posted by Korval:
So, in order to do multisampled rendering, we render to a multisample FBO, then do a blit to some other FBO? Is it possible to blit to FBO's that have textures as their destination renderbuffer?Yes and yes. The blit will allow stretching between two FBOs that are not multi-sampled. Filtering can be linear or nearest for the stretch.

BUT this is all work-in-progress. Things can change still. Standard disclaimer applies :-)

Barthold