ARB_Superbuffers - all the gory details

[MZ]

I'm curious why they have abandoned the previous method of binding GLmem to array, as shown in the GDC03 presentation . After adoption of that older method into the language of the newer proposal, we would get:

glBindBufferARB(GL_ARRAY_BUFFER_ARB, theVBO);
glAttachMem(GL_ARRAY_BUFFER_ARB, theGLmem, whatever);
glVertexPointer(4, GL_FLOAT, your_stride_if_you_insist, offset);

IMO the original binding method is better then newer one, because:

1. it seems to be more consequent with the rest of SB: you attach the GLmem thing to some existing, currently bound GL object (texture, FB, VB), rather than directly to the GL_VERTEX/COLOR/etc_ARRAY targets. (As far as I understand the spirit of the proposal, GLmem is not intended as a new kind of GL object, but as a holder of contents of *other* objects - otherwise I don't see justification for the new GLmem type, separate namespace, and lack of glGen)

2. it's easier to use: *only* initialization code is changed with SB (glAttachMem vs. glBufferData), but later you use all VBOs in exactly the same way.

3. there is no need for new gl(Multi)DrawElements() functions

4. the stride problem disappears: you set the stride as in regular VBO (although I'm not terribly convinced about the need of the stride in render-to-vertex-array usage)

So I'm curious, what adventages of the new binding method (glVertexArrayMem) outweighted these 4 above, as I simply can't imagine any...


[This message has been edited by MZ (edited 08-20-2003).]

[Tom78]

Is it possible that the final specs will get changed or will OpenGL begin to suck as DX does a long time ? I can't understand why every ARB_Extension needs another way of handling the whole problem. Why not using the VBO and SB the same way ? More and more i think, that DX will be the better choice for the future.
I begin to see it this way :
ARB is too slow to handle the GPUs evolution.
+
The time for Vendor-specific Extensions is over (too much work, i can have the same in DX with only one renderpath).

Am I the onlyone or are more people angry about the way OGL gets killed (hope MS won't be so successful). OpenGL gets too complicated. No more rapid-dev is possible and that was why i used OpenGL.

Please say that the specs are not ready. PLEASE !

cu
Tom

[Korval]

Am I the onlyone or are more people angry about the way OGL gets killed (hope MS won't be so successful). OpenGL gets too complicated. No more rapid-dev is possible and that was why i used OpenGL.

The super-buffers extension, in and of itself, is quite simple. As for OpenGL getting too complicated in general... tough. Complications are needed to be able to access advanced features.

Please say that the specs are not ready. PLEASE !

If you weren't paying attention, these aren't specs; they're a powerpoint presentation that ATi made at Siggraph. All we know is that it represents a particular state of the super-buffers extension.

BTW, here's the most likely reason why they don't use VBOs.

In general, it's a bad idea for certain functionality in an extension to rely heavily on an unrelated extension. For example, you wouldn't want render-to-vertex-array to rely on an extension that you can't be sure is implemented everywhere.

Note that VBO was only selected for insertion into the core a few months ago, and that vote was only preliminary. Back then, the superbuffers workgroup couldn't count on VBO becoming part of the core. So, they had to build into their API a vertex binding method.

Now that VBO has been (preliminarily) approved for insertion into the core, it is now reasonable for superbuffers to rely on that functionality as an interface for rendering meshes.

[MZ]

Originally posted by MZ:
(quote from proposal)– Memory objects attached to a framebuffer object must have the same dimensions and dimensionality

DX9 is less restrictive: (from SetRenderTarget() description) "The size of depth stencil surface must be greater than or equal to the size of the render target". Since HW supports it (wouldn't be in DX otherwise), then why not have this exposed in GL too?

excuse me if I reply to my own post in month-old thread, but: I've just spotted evidence , it looks like the technique is nothing unusual in DirectX.




[This message has been edited by MZ (edited 09-02-2003).]

[dorbie]

So what's wrong with viewport and scissor? What is the difference here in the context of what this guy is doing? Doing this sort of thing and trying to pretty it up behind an abstract interface that merely looks flexible can often lead to hidden performance pitfalls.

[Korval]

So what's wrong with viewport and scissor?

It is often the case that, in our quest for flexibility, we forget the capabilities that we already have.

Granted, viewport and scissor don't actually prevent us from allocating a 1600x1200 colorbuffer, to use with a 1600x1200 z-buffer, but it does effectively let us section one into smaller pieces.

You can't allocate two 512x512 buffers, one as a color buffer and one as an aux buffer, and render to both (with ATI_draw_buffers, for example) with a 1600x1200 z-buffer. You'd have to allocate two 1600x1200 regions and section them with viewport and scissor. And it has to be 2 because you can't have two buffers that draw to different regions.

There's still usefulness in having the flexibility.

[MZ]

I don't understand what you are talking about, dorbie, viewport and scissor are completely unrelated to the problem.

To generalize what the guy from my link is doing, consider this: You have a number of render targets. They can have different sizes and different dimensionality (RECT, 2D, CUBE). When rendering from any them, you use only color data (let's forget about ARB_shadow). When rendering to any them, you temporarily need depth buffer (+ stencil &| multisample). You can choose one of two strategies:

A. Create one depth buffer for every possible color buffer size (and every possible mipmap size). A group of equally sized color buffers can share one depth buffer.

B. Create single depth buffer of size being maximum of all possible color buffers, and use it when rendering to any of them (that's what the guy in the link is doing B)

With current GL neither of above is possible (except very limited A, with double buffered WGL_RTT trick).
With DirectX both strategies are available.
With current SB proposal you can do only A, B is explicitly disallowed - and this is my concern.

You can't mimic the B strategy with scissor & viewport, if this is what you've been trying to suggest (unless you considered glCopyTexImage as RTT method, but this is not related to SB). And it is not all about "trying to pretty something up", but about exposing a HW feature (ability to render to differently sized color and depth buffers), which appears to be widely available (it's not even optional in DX, it is standard), and which can be useful.

I thought about possibility of solving the problem automatically inside driver - there is "undocumented" glInvalidateMem(GLmem mem) thing in the proposal. With well placed hints saying "From now I don't care for contents of this depth buffer" the app could pretend it is doing A, but the driver would turn it to B internally - something like vertex buffer renaming when "discard" hint is given by app. With this, the extra flexiblity of DX wouldn't be necessery to achieve the same effect, so maybe the ARB guys have already gone this way.