ARB_Superbuffers - all the gory details

[harsman]

It turns out ATI have released their presentations/whitepapers from SIGGRAPH 2003 at their developer site. Among them is a rundown of the upcoming superbuffers/überbuffers proposal. Take a look over here . Interesting...

[Korval]

Some good stuff. Some bad stuff.

Why is the binding of a memory object syntax so different from VBO syntax? The entry points already exist. It'd be nice if both of them worked the same way.

[davepermen]

nice nice..

still waiting till its available from the arb..

[Ozzy]

ugly.

[MZ]

Originally posted by Korval:
Why is the binding of a memory object syntax so different from VBO syntax? The entry points already exist. It'd be nice if both of them worked the same way.

Same feeling. Now, when VBO has been included into core just a while ago, it's kind of schizofrenia...

Apart from the VBO issue, UB looks good to me.

[Humus]

The functionality is definitely needed. Syntax issues are less important, though if anyone have a problem (as it seems) don't hesitate to shoot of a mail to James Percy (whose address is at the front page in that presentation) or to Rob Mace.

[MZ]

Couple of comments to Framebuffer Object (page 21) :

– 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?

Example: In a game level some objects/surfaces are assigned effects using RTT. Let's say color data of these RTTs is cachable or fully dynamic, but depth-stencil data is only temporary (becomes useless after RTT color data is ready, so depth buffer can be reused for another RTT effect). And let's say different instances of these effects may use RTT of different resolution. In this circumstances I'd be forced to create depth & stencil buffers for every possible RTT resolution found in the level, rather than reuse one large for all (possibly the main, screen-sized)

– Memory objects attached to color targets (GL_FRONT, GL_BACK, GL_AUXi, etc.) must have the same format

This could be limiting usage of multiple-render-targets (DX9 is less restrictive here too).

Example: in deferred rendering I'd like to output reflection-vector in 16|32bit float per channel format, but normal-vector in standard 8bit per channel format. Despite having MRT, I'd be forced to do it with multipass.

[Korval]

I can't say I'm terribly familiar with DirectX, but the way I understand it, hardware vendors are allowed to not have certain functionality avalaible in their Hardware Abstraction Layer. The user can tell, via caps-flags, whether or not a particular piece of functionality is avalible.

Therefore, just because D3D 9 allows for the possibility of a driver exposing render targets with differing resolutions or different formats, it doesn't actually require that HAL's implement them. Right?

It would be nice, of course, if we did have the DX9 functionality.

[MZ]

I'm not expert in DXn either, I stopped using it in DX6/7 times. Since then I only download their SDKs, and main reason for this is to read the documentation.

Regarding the first issue, there is no related cap (looks like every HW supports it, or DX emulates it ?). Regarding the second one (MRT), we have:

If the D3DpMISCCAPS_MRTINDEPENDENTBITDEPTHS cap is set, the device can support all mixed formats regardless of format type or bit depth. If the D3DpMISCCAPS_MRTINDEPENDENTBITDEPTHS cap is not set, the device can support mixed types for surfaces containing the same bit depth above 16 bits. The mixing of different format types for 16-bit depth is undefined

plus, of course, a cap saying whether MRT is supported at all.

[Mazy]

from the flexible and easy to use VBO to this strange extension.. Since this redefines the vertex attachement, and also disallows interleaved arrays, I can only see that we are going to get 2 totally different objects for vertexdata, one for predefined or cpu created data, and one other for gpu generated data.. Same for textures, one interface for loaded textures and one for generated data..

I want to test this out befor i complain, but when i compare SB against VBO i say that VBO was a improvement of an old technique, and this (sb) totally redefines a lot of stuff, that i think could be done in an easiser way.. but i still want to try it out.