ARB_super_buffer extension

Hi all!

According to the ARB Sept & Dec meeting notes ARB_super_buffer extension will be avaiable about June 04.

I’ve read about the following features in forums:

render to vertex buffer
treat textures as vertex buffer and use them in vertex shader/programs

But does super buffer extension covers additional pixel buffers like defined in early GL2 spec (you can read/write to them in fragment shaders)?

What else does ARB_super_buffer extension include? What are other new features of this extension?

Thanks a lot
Corrail

[This message has been edited by Corrail (edited 01-24-2004).]

Have a look at the Siggraph presentation of James Percy:
http://www.ati.com/developer/SIGGRAPH03/Percy_OpenGL_Extensions_SIG03.pdf

  • Klaus

Cool! Thanks a lot!

I see a lot of discussion on super buffer, could anyone give me some hints about how to use the extension? I have read the SIGGRAPH 03 ppt file, but I am still quite confused. are there any sample for this extension?

ARB_super_buffer is, for the time being, dead. Any render-to-* functionality will be coming from ARB_render_target and other extensions based on this.

I just want to clear things up a bit. There never was a spec proposed called “super_buffers” or anything like that. The working group is called “super buffers”, but that’s it. The original extension, brought to the ARB by ATI a long, long time ago was called uberbuffers (with an umlaut over the first u), and it is, for all intents and purposes, dead.

In the interim, there were numerous specs proposed to fix or work around various perceived issues with the original uberbuffers proposal. The most famous of which is Nvidia’s EXT_render_target spec (see the discussion too).

The spec that is currently in front of the WG is not uberbuffers and it is not EXT_render_target. I think it’s fair to say that it is born of those two specs. It’s not quite done cooking, but a yummy aroma is filling the kitchen. :wink: Don’t worry. Nobody wants to see this completed more than the people that have been working on it for the past 2+ years!!!

The spec that is currently in front of the WG is not uberbuffers and it is not EXT_render_target. I think it’s fair to say that it is born of those two specs. It’s not quite done cooking, but a yummy aroma is filling the kitchen.
Considering that there was precious little that was good about superbuffers (and that there was lots good about EXT_RT), I fail to see what good is going to come of taking an excellent spec and adding hints of a lesser one to it. As far as I’m concerned, once the minor points of the spec were finished (interactions with other things, etc), EXT_RT was finished and ready for implementation and use.

More importantly, why not drop a preliminary spec on us, ala EXT_render_target? Even ATi gave us a few peeks at what superbuffers would look like API-wise a while back, which prompted some discussion.

Well, I’m not going to delve too much into the details, but a lot of people, myself included, that actually have to implement this stuff in drivers had some serious concerns about EXT_rt. I’ll enumerate the two biggest ones:

[ol][li]Any texture can be renderable. On a lot of hardware this would require either software fallbacks or some evil CopyTexImage-like hacks.[*]There’s no such thing as a stencil or accumulation texture, yet both are useful for rendering.[/ol][/li]That said, I think the resulting spec is, in a lot of ways, more like EXT_rt than uberbuffers. Like I said in a previous post, the collaborative design process that started after we spent a long, long time trying to “fix” uberbuffers to make everyone happy has been really useful. The current spec isn’t perfect by any means, but I think that in a year, after they’ve forgotten how long it took, people will be happy with it and will think we did the right thing.

Any texture can be renderable.
Yes. That’s the whole point of render-to-texture, and one of the principle faults of the superbuffers proposals.

On a lot of hardware this would require either software fallbacks or some evil CopyTexImage-like hacks.
OK, that doesn’t quite make sense. I presume you’re refering to swizzling of textures as to why this would be required (or, at least, one reason why not). Well, it wouldn’t be terribly hard to simply change the internal format of the texture when it is bound as the render target (into a linear one). Once the rendering is complete, the texture can be re-swizzled. More importantly, if a particular texture is frequently used as a render target, then it can just be stored linearly by default, and the user simply won’t get the benifits of the improved performance that swizzling offers.

Yes, I know that the 1.5 GL spec expressly disallows reallocation of textures by drivers, but the render-texture extension could easily modify this to allow binding a texture to change its format. Extensions are, by definition, allowed to modify the spec.

Given the above, I suspect that this new version has created a bunch of new texture formats that are required-use for render targets. And that this extension forbids the use of just any old texture as a render target, requiring the use of specific textures.

As such, if it should ever arise that an already existing texture needs to be a render target (without foreknowledge. Say, I’m writing a library that someone else uses), then I, the user, must create a new renderable-texture, draw the old texture onto it, and delete the old texture. These are things that a driver has both the right and the responsibility to do for us.

There’s no such thing as a stencil or accumulation texture, yet both are useful for rendering.
First, I disagree that they are useful as render targets. The accumulation buffer, maybe. The stencil? Not very. Maybe a little, but not terribly often. Certainly not worth damaging a perfectly clean API over.

Second, the EXT_RT extension provided for a depth-stencil texture format. If a separate depth and stencil were needed (not that hardware supported it), then those formats could be exposed by this extension or a future one.

Originally posted by Korval:
ARB_super_buffer is, for the time being, dead. Any render-to-* functionality will be coming from ARB_render_target and other extensions based on this.
What I am really concerning about is the ability to render to vertex-buffer/vertex-array. I read the specification at http://www.opengl.org/resources/features/GL_EXT_render_target.txt, the feature seems missing. Does anyone have any idea about other method to achieve this? Read back from texturing is too slow, and NV_pixel_data_range extension give me some hints, but it still is a readback process.

tang_m, EXT_render_target’s purpose was to take over the job of p-buffer based textures. The spec is serving as a model for something else it seems according to idr.

After rendering to it, you can always sample it in a vertex program and do what you want from there.

Using a texture as a vertex buffer… I’m not sure how that will work as of yet, but it sounds like a totally new extension is needed and EXT_render_target need not be concerned by it.

Originally posted by V-man:
[b]tang_m, EXT_render_target’s purpose was to take over the job of p-buffer based textures. The spec is serving as a model for something else it seems according to idr.

After rendering to it, you can always sample it in a vertex program and do what you want from there.

Using a texture as a vertex buffer… I’m not sure how that will work as of yet, but it sounds like a totally new extension is needed and EXT_render_target need not be concerned by it.[/b]
Thanks, vertex texture is good, but I am using an ATI 9800, which don’t support SM3.0 features.

It IS extension, like NV_/EXT_NPOT where it doesn’t matter that you have to sample texture in [0, dimension] format, it is fixed in ARB good, but we were using old approach for quite some time. I would love to see RT extension in string so I could use it right now, & as I allready mentioned it’s not in core so it may have limitations, fixes to be applied when it goes to ARB. Wasn’t that the point of extensions?

tang_m, if you want to render to vbo have you looked at EXT_pixel_buffer_object? I was messing around with this a couple of weeks ago and got the results I wanted with using a floating point texture , rendering to a floating point p-buffer and reading this into a vbo. Have a look at the specification for EXT_pbo - it gives an example of render to vertex array that I based my work on.

Originally posted by idr:
The spec that is currently in front of the WG is not uberbuffers and it is not EXT_render_target. I think it’s fair to say that it is born of those two specs. It’s not quite done cooking, but a yummy aroma is filling the kitchen. :wink: Don’t worry. Nobody wants to see this completed more than the people that have been working on it for the past 2+ years!!!
Does anybody know about the state of the spec that is currently in front of this WG?
It is supposed that this week (or last week) has been the latest ARB meeting.
Has anything been cooked (last version posted of the EXT_rt spec is from this year’s April) or are there to many cookers in the kitchen putting their hands in the same bowl?

Originally posted by ffish:
tang_m, if you want to render to vbo have you looked at EXT_pixel_buffer_object? I was messing around with this a couple of weeks ago and got the results I wanted with using a floating point texture , rendering to a floating point p-buffer and reading this into a vbo. Have a look at the specification for EXT_pbo - it gives an example of render to vertex array that I based my work on.
Thanks a lot, that’s what I am really looking for. I will try it.

Originally posted by V-man:
Using a texture as a vertex buffer… I’m not sure how that will work as of yet, but it sounds like a totally new extension is needed and EXT_render_target need not be concerned by it.
I wrote an extension idea about that at
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_to pic;f=3;t=012395
This would solve the render to vertex array problem quite simple but there’s a problem because (as Korval said) mostly texture aren’t stored linearly.

Korval,

I think you’ve missed some the subtle implications in EXT_rt and my post. You don’t see how stencil buffer is useful as a render target? With EXT_rt (or uberbuffers or…) you need to provide all the buffers (color, depth, stencil, etc.) that are part of the pixel format in classic, on-screen rendering. Saying the stencil buffer isn’t useful as a render target is the same as saying the stencil buffer isn’t useful on-screen rendering. I’m sure Carmack would disagree. :wink:

The depth-stencil format was an ugly hack. It was a one-off fix that didn’t solve the underlying problem. What does it mean to use a “depth stencil” texture for texture mapping? It’s nonsense, but the API would have to allow it. When you bring accumulation buffers and multisample buffers into the equation, it falls apart even more.

Since there’s so much confusion about it, I’ll give a concrete example. With EXT_rt you could say, “I have an RGB332 texture, and 16-bit depth buffer, and an 8-bit stencil buffer that I want to render to.” I know of no hardware that can draw to that combination of buffers. However, the way the API is designed, the driver has to do it. The only options are to fallback to software rendering or internally (i.e., behind the application’s back) draw to a different buffer and copy the results. Both of which, IMHO, suck. One the one hand you have unacceptable performance, and on the other hand you have invariance issues. For a driver writer, it’s a lose/lose situation.

To make it even worse, I seem to recall that you could specify a compressed texture as a render target. I don’t even want to go there…

Uberbuffers, on the other hand, has a really complicated, heavy-weight mechanism for the application to describe what kinds of buffers it wanted, then as the driver what it could do. It was something like a radiation mutated ChoosePixelFormat. It was evil and universally despised.

I hope people can now see why I get so irritated when the WG is accused of arguing over petty crap. :frowning:

Given the above, I suspect that this new version has created a bunch of new texture formats that are required-use for render targets. And that this extension forbids the use of just any old texture as a render target, requiring the use of specific textures.

As such, if it should ever arise that an already existing texture needs to be a render target (without foreknowledge. Say, I’m writing a library that someone else uses), then I, the user, must create a new renderable-texture, draw the old texture onto it, and delete the old texture. These are things that a driver has both the right and the responsibility to do for us.

To answer your questions, yes and no. Handling the situation you describe was one of our specific design goals. In fact, that was one of the big gripes people had with uberbuffers, not surprisingly. The only times you are required to use new formats is if you’re rendering to something that you can’t texture from (i.e., stencil) or if you don’t intend to texture from it (i.e., render using a depth buffer that you won’t ever use as a depth texture). In the latter case it just provides some optimization opportunities for the driver.

Like I’ve said a whole bunch of times…the resulting API is quite clean and gives quite a lot of functionality. I really think people will like it.

tang_m, V-man: Our scope has been limited to replacing pbuffers. Any functionality beyond that will be a follow-on effort. I think that’s one of the problems we had at the start. We bit off way too much at once.

Zak: The ARB meeting is next week.

With EXT_rt (or uberbuffers or…) you need to provide all the buffers (color, depth, stencil, etc.) that are part of the pixel format in classic, on-screen rendering. Saying the stencil buffer isn’t useful as a render target is the same as saying the stencil buffer isn’t useful on-screen rendering. I’m sure Carmack would disagree.
For regular on-screen rendering, you don’t have to create anything with EXT_RT. The driver created it for you. So you can still have your regular screen stencil buffer.

And what Carmack would agree or disagree with is of little interest to me. I’ve always preferred depth shadows to stencil ones, so I have little use for the stencil buffer.

What does it mean to use a “depth stencil” texture for texture mapping?
It (should) mean the same thing as using a depth texture. The stencil part is ignored.

The only options are to fallback to software rendering or internally (i.e., behind the application’s back) draw to a different buffer and copy the results. Both of which, IMHO, suck.
Why do they suck? If you ask to render to an RGB332 texture, you deserve what you get in terms of performance. It’s just like using the accumulation buffer on hardware that clearly doesn’t support it (anything less than R300 and NV30). You get poor performance.

To make it even worse, I seem to recall that you could specify a compressed texture as a render target. I don’t even want to go there…
The only difference is that the copy back needs to compress the texture.

I hope people can now see why I get so irritated when the WG is accused of arguing over petty crap.
Well, by your own admission, the uberbuffers extension was going in very much the wrong direction. Either those proposing it should have seen that, or those working with them should have done something. Both sides failed, even (or especially) if one side failed due to lack of presence on the issue.

I, for one, would prefer the “arguing over petty crap” to what happened with uberbuffers. At least with an actual argument, everyone is aware of the situation. Effectively, you said that a number of people weren’t even involved with uberbuffers for a long time, which means that these people were negligent. I prefer petty over negligent.

Like I’ve said a whole bunch of times…the resulting API is quite clean and gives quite a lot of functionality. I really think people will like it.
The same thing was said about uberbuffers 2 years ago. I’m sorry, but just saying it doesn’t cut it anymore; the ARB has burned its credibility, and now needs to prove itself.

Hey Korval, may i ask you, if you are a driver writer? Or do you have experience in it? Because it sounds as if you are not, but still you tell people how to do the job.

I don´t want to offend you, but if you don´t have experience in writing a graphics card driver, you shouldn´t simply assume, that it is so easy to implement a good RTT mechanism.

Of course, i think the same way. I am very impatiently waiting for a render-to-texture mechanism, that is better than p-buffers, but on the other hand i DO want it to be good this time. Therefore i prefer a spec, which is powerful, yet “easy” to implement (well, as easy as such a thing is possible). I don´t want that my app falls back to software rendering on certain cards or on certain drivers. I want to be able to tell the driver to use a format, which is suitable for THAT hardware, so i can be sure to get hw acceleration on any card - as long as i don´t force it to use one format for some reason.

I really think it is a shame, that we don´t have proper RTT support in OpenGL, but i think the shame is, that this issue was taken up so late. Now that there is work in progress, i think they should take their time to make it as good as possible. No one will be happy with another crappy extension, only because it gets released fast.

idr: Nice to get a bit information from an “insider”. I think people would sometimes be able to be more patient, if they got some sort of status a bit more regularly. At the moment we don´t get really informed, IF there is work in progress and HOW FAR it is, which makes many people think “what the heck makes them take so long?”.

Jan.