The topics PBO and EXT_render_target were discussed in these forum some time ago. But I just read (and saw) the GDC 2004 presentation of the Superbuffer extension (available from ATIs developer section). They seem to be quite ready with the specification.
So what’s about them now? Are there two powerful extensions giving nearly the same features on the way? It seems that ATI and NV want to introduce their own extensions rather than cooperate and bring us one to ARB status.
What do you think about that? Does anyone know if that topic was discussed at the ARB march meeting?
I think one problem is the current HW. The superbuffers probably demand alot of flexilibity from the HW that arent there yet, and i must say, it seems much messier than the new proposal.
I’m going to have to side with nVidia on this one. After seeing the EXT_render_texture spec, it just seems too simple not to use. You want to render to a texture, you bind it to the framebuffer. End of story.
Superbuffers adds more functionality, but doing the simple things, what you’re going to want 80+% of the time, is exceedingly (and, to my mind, needlessly) complex.
We don’t need to allocate free-standing memory objects just to render to a texture. It’s useful for other things, but for basic render-to-texture functionality, it is overblown. Just look at the sheer quantity of code needed to render to a texture.
Also, ATi is too bound to the ARB to go and release a big thing like superbuffers on their own. If/when it is released, it will be done so after the spec is approved by the ARB.
EXT_render_texture, on the other hand, was built as a collaborative endevour involving only some of the members of the ARB. It doesn’t have to go through their approval process; merely an agreement by all parties involved in making the extension.
BTW, superbuffers still uses a new API to bind arrays, rather than using VBO. This remains both silly and unacceptable.
Lastly, PBO has traits that not even superbuffers has. Like being able to do async reads, which are a requirement for downloading image data without stalling. So, even with superbuffers, PBO has its place.
Both extensions are really good. They mainly provide the same features.
Superbuffers is a enourmous API. For example the proxy memory system they provide is really cool. But as you said Kroval they provide a new way of binding vertex arrays what I don’t like too. And that’s exactly what many developer criticize on OpenGL: There are thousand ways of doing something. Introducing a new API for vertex binding will be really messy.
VBO/PBO/EXT_render_target on the other hand is a small but simple API. What I really miss here is internal buffer copies. How do I copy buffers from one buffer object to another? AFAIK there’s no command for doing that internally. I also prefer the Superbuffer-way of binding framebuffer/textures.
So, but what way will the ARB choose? Superbuffer or VBO/PBO/EXT_render_target? Or both??
Introducing a new API for vertex binding will be really messy.
Especially considering that VBO was supposed to consolidate all the fast vertex API’s into one.
So, but what way will the ARB choose? Superbuffer or VBO/PBO/EXT_render_target? Or both??
The display ATi showed was pretty mature, with some specific details about enums and so forth. But, then again, EXT_render_target (was it target or texture?) was pretty close too; it just needed more definition and it could be done.
Of course, with the ARB, it’s all politics. ATi is definately coming down on the superbuffers side, and nVidia/3DLabs (at least, I think it was 3DLabs who helped on it) are leaning more towards EXT_render_target.
Really, if all we got was (a less-restrictive version of) EXT_render_target, I’d be happy. Superbuffers sounds nice and all, but it’s a lot more than the vast majority of us needs.
Oh, and props have to go to the EXT_render_target team for actually asking us what we thought about it.
I’m quite annoyed about ATI’s attitude. Bringing extensions directly into ARB extensions is a bad idea. We’re getting stuck with some odd, complex functionality.
The RTT EXT seems like a really nice light weight solution. ATI just seems to want to dupe people into their idea’s by throwing “ARB” buzzword around, and it seems that other members are following because they’re scared of nvidia.
ATI just seems to want to dupe people into their idea’s by throwing “ARB” buzzword around, and it seems that other members are following because they’re scared of nvidia.
In ATi’s defense, this extension has been in the process of being made by the ARB itself for over a year. I see their slides as a kind of “progress report”. Though it does advance what is likely their preferred position, the actual content is not wholely of ATi’s making.
In short, ATi did not just decide to call this an ARB extension. It is an ARB extension; it’s just a very big one that has taken over a year to reach anything close to being finished.
Well, given it was their presentation you can expect a small amount of their prefered solution into it at least.
As for teh question in this post, i think having both systems would be good, as someone said most of us will only need VBO/PBO/EXT_render_target however others will want the Superbuffers and after a while others will want the functionality of it.
As long as everyone pulls together with EXT_render_target and we get a working extension which exists on all major cards i’ll be happy enuff
I just read the new draft of EXT_render_target. There are some really nice improvements.
As for teh question in this post, i think having both systems would be good…
Yes, I agree with you. Both systems would be cool. But what about interactions between them? There should be a way to manage memory between these two systems…
Man, I hate WGL_ARB_render_texture so so so so so much!
EXT_render_target should come sooner than super buffer and should serve as a stepping stone.
Unfortunatly, cass can’t say when it will come, but I think this summer???
Yes, I agree with you. Both systems would be cool. But what about interactions between them? There should be a way to manage memory between these two systems…
The superbuffer gives us more power and I think we are free to user them… manage memory this and that but we should be able to use GL old school.
So they can/should exist together without effecting each other.
Eventually, when superbuffers comes around, I will probably use it. I don’t think of it as one vs. the other, but more of a evolution.
Lastly, PBO has traits that not even superbuffers has.
No? I guess async/sync definition was another part of the GL2 docs.
