PDA

View Full Version : ARB_Superbuffers - all the gory details



harsman
08-10-2003, 10:18 AM
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 (http://ati.com/developer/SIGGRAPH03/Percy_OpenGL_Extensions_SIG03.pdf) . Interesting...

Korval
08-10-2003, 01:36 PM
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
08-10-2003, 08:30 PM
nice nice..

still waiting till its available from the arb..

Ozzy
08-10-2003, 10:48 PM
ugly.

MZ
08-11-2003, 07:39 AM
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... http://www.opengl.org/discussion_boards/ubb/confused.gif

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

Humus
08-11-2003, 09:01 AM
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
08-12-2003, 07:38 AM
Couple of comments to Framebuffer Object (page 21) :


– Memory objects attached to a framebuffer object must have the same dimensions and dimensionalityDX9 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 formatThis 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
08-12-2003, 09:04 AM
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
08-12-2003, 11:24 AM
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
08-14-2003, 05:29 AM
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.

Korval
08-14-2003, 10:39 AM
Same for textures, one interface for loaded textures and one for generated data..

That is a good idea... for textures. After all, any super-buffers extension is going to be cumbersome to work with. At least, moreso than just calling glBindTexture and glTexImagenD, if nothing more than the explicit allocation of memory. We still want the old method to work, because very few textures will be render targets. So, we don't need the code overhead to handle this.

Mazy
08-14-2003, 11:21 PM
Not if you could bind a texture as a color/depth/stencil target to a framebuffer.
And just load data into a memory area. That would be one call more, just to allocate the memory via opengl instead of an os dependent call.

glGenObject(1,texture);
glGetMem(texture, size, format);
//load the texture
glBindAsTexture(texture, edgeformat and stuff);
// draw with that texture.

and you could just as easy attach it as a rendertarget with the glAttachMem(fb,GL_COLOR_BUFFER, texture); to render to it.

Korval
08-14-2003, 11:49 PM
and also disallows interleaved arrays

I was looking at the .pdf, but I didn't see anything that disallows interleving. If you use glVertexArrayMem() with the same memory object, but with different offsets and strides, you can achieve interleving, just like you can with regular vertex arrays.

Granted, I do agree that the memory binding should have used (and may yet still use, as the spec isn't done) VBO syntax. But I think that's been said enough.


Not if you could bind a texture as a color/depth/stencil target to a framebuffer.

Superbuffers is about more than merely render-to-texture. It's about creating free-standing memory objects that can be used in a multitude of places. Vertex arrays, render targets, textures, and potentially others. This API is useful enough to cover lots of circumstances, while simultaneously not providing too much in the way of overhead.

Mazy
08-15-2003, 01:02 AM
I must have missed the interleave part if that call.. ( still cant see it)

and i dont see how my approach for textures in any way makes it impossible to bind it as a VBO instead.

Korval
08-15-2003, 01:34 AM
I must have missed the interleave part if that call.. ( still cant see it)

The vertex pointe commands have a stride and an offset. That's all you need to have interleved arrays.


and i dont see how my approach for textures in any way makes it impossible to bind it as a VBO instead

Easy. A texture has mipmaps. Which mip are you wanting to bind and use as a vertex array? Certainly the VBO glBindBuffer command has no field for specifying mipmap level. And how do you handle slices of 3D textures?

Also, texture objects and buffer objects don't come out of the same pool. Therefore, texture object 1 and buffer object 1 could be in use at the same time. How does an implementation know which one you're refering to? Granted, this explains why they don't use VBO binding syntax (or, at least, why they don't use glBindBuffer. They could have created a glBindMemBuffer to use a mem buffer using VBO syntax).

Here's one question I have: how does 2D image data map to a 1D data type like vertex arrays? Things like this could be what lead to the limiting of resolutions for a render target to all be the same. That way, you can't possibly only render to a part of a buffer, but then expect only that part to be used as a vertex array.

Mazy
08-15-2003, 01:59 AM
Do you use the pointer commands for drawing?

I only see:
glVertexArrayMem(GL_VERTEX_ARRAY, 4, vmem, 0);
glVertexArrayMem(GL_COLOR_ARRAY, 4, cmem, 0);
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);

and if you still used the Pointer commands, why should you specify color and vertex in those commands?

(i think the '4' is a miss, i think they meant to write '3' there, since they allocated the memory with 3)

And i think oyu overcomplicate things in the bindings, you cannot bind an vertexarray to a mipmap level ( not that i can see) and not to a specific slice in a 3d texture. You can bind a slice to a framebuffer, but thats also functionally in my approach (the 'stuff' part)

If i havent missunderstod something in the presentation then i think we have an overcomlicated api, atleast for the functionallity we have now, especially since the words ' for future extencabillity' was in the VBO aswell.. but im not here just to try to convice you, i just stated mu point and hoped for one of the persons that voted for it, or atleast was part of the workgroup to explain the whole new path since VBO api pretty much was designed for 'buffers' and vertexbuffers was just the first path of it as i understand.

NitroGL
08-15-2003, 10:23 AM
I was under the impression that the super buffer extension would be more like the VBO extension:

glBindBuffer(GL_MEMORY, foo)
foo_addr=glMapBuffer(GL_MEMORY, GL_READ_ONLY)
glBindTexture(GL_TEXTURE_2D, bar)
glTexImage2D(GL_TEXTURE_2D, ..., foo_addr)
glUnmapBuffer(GL_MEMORY)

Or something like that, and the point was that you would still "upload" data with the standard GL functions, but the memory would be on the video card itself and a copy wouldn't occur (like with glCopyTex[Sub]Image).

And you could allocate memory with the glBufferData function, and the super buffer extension would add whatever is needed for framebuffer binding (or find some way to do that with existing GL calls, like glRead/DrawPixels).

Korval
08-15-2003, 11:14 AM
and if you still used the Pointer commands, why should you specify color and vertex in those commands?

What does using gl*Pointer have to do with interleving? The concept of interleved arrays exists outside of a particular API.

Unless you're refering to explicitly interleved array formats, which was a bad idea when it was written into the vertex array spec, and goes unused in any real application.


you cannot bind an vertexarray to a mipmap level ( not that i can see) and not to a specific slice in a 3d texture

Sure you can. All you do is get the sub-memory object for that mip level and call glVertexArrayMem() using that sub-memory object.


If i havent missunderstod something in the presentation then i think we have an overcomlicated api, atleast for the functionallity we have now, especially since the words ' for future extencabillity' was in the VBO aswell..

VBO was a very simple case, compared to what buffer objects have to provide. After all, supplanting client-side memory with server-side memory is not hard from a design point of view. Contrast that with taking an existing API for textures and adding the capacity for creating free-standing memory objects that can be used for textures, framebuffer pieces, vertex arrays, and potentially other things.


a copy wouldn't occur (like with glCopyTex[Sub]Image).

It still accomplishes the goal of preventing memory copies.


And you could allocate memory with the glBufferData function, and the super buffer extension would add whatever is needed for framebuffer binding (or find some way to do that with existing GL calls, like glRead/DrawPixels).


Oh no. That was never the intent. Even the first inklings of super-buffers, back at GDC, didn't have the actual allocation of memory being the same as VBO (which had just released around that time).

Now, as we've stated before, it would be nice if they used the same entrypoints for binding to

Mazy
08-15-2003, 11:31 PM
Just please give me an example of interleaved data, and how you bind it with the new array commands in the SB presentation, since i cant find a stride in that call, the size seems to refer to the number of elements (3 for vertex and normal, 2 for UV coords and so on) and then you only have an offset.

and for the rest, ok, i can have missed that in the presentation, But you could just as easily just added the getSubbuffer commands to get the new memorypointers and just used those pointers in VBO.

This way we end up with 2 completely different way to make, and use, buffers for loaded or generated data.



[This message has been edited by Mazy (edited 08-16-2003).]

zeckensack
08-16-2003, 07:48 AM
Originally posted by Mazy:
[B]Just please give me an example of interleaved data, and how you bind it with the new array commands in the SB presentation, since i cant find a stride in that call, the size seems to refer to the number of elements (3 for vertex and normal, 2 for UV coords and so on) and then you only have an offset.There is no stride, and I see no facility to emulate it.
You'll need to use different memory objects for each vertex attribute, as far as I understood the presentation.

If that's true, it sucks. It greatly hinders transition from system memory vertex arrays and VBOs (apps will need 'regular' arrays for fallback, VBOs are much easier to implement there; interleaving array data was a *good* thing last time I checked).

and for the rest, ok, i can have missed that in the presentation, But you could just as easily just added the getSubbuffer commands to get the new memorypointers and just used those pointers in VBO.Not sure. It makes sense to divide namespaces. Mem objects may be conceivably used in place of VBOs, but the opposite just isn't possible.
For starters, VBOs never defined hierarchical structure and can't start doing so now. It may be 'surprising' for apps when, say, id 1000 joins the pool of defined VBOs as soon as id 1 is created.

This might have been avoided by further delaying the VBO specification and ironing out the interaction first. I hope we can agree that this wouldn't have been a good idea.

This way we end up with 2 completely different way to make, and use, buffers for loaded or generated data.True. You'll have to chose one of the two ways. If you don't need the functionality, you needn't be concerned with this and can keep using VBOs.
Mixed usage may get a bit complicated http://www.opengl.org/discussion_boards/ubb/wink.gif

madmanchan
08-16-2003, 11:53 AM
There seems to be some confusion regarding VBO and superbuffers. The way I understand it, they address two different parts of the GL.

Buffer objects address "byte memory" -- GL memory whose fundamental unit is the byte, and it's the type of memory that we can work with directly in terms of arrays. As with vertex arrays, we can directly access the memory contents of buffer objects and perform selective updates (e.g. cherry-picking just one or two vertices whose attributes we want to change). Traditionally, byte memory objects such as vertex arrays have been stored on the GL client side, usually on the host processor. Sending this memory to the GPU may require extra copying by the driver, which is expensive. The purpose of buffer objects is to extend API in a way such that such memory can be implemented on the GL *server* side, which on today's architectures may be AGP memory. You can still cherry-pick individual vertices (in the specific case of vertex buffer objects) and get access to the individual bytes of the buffer object. Until you specify how you want to treat that buffer object (e.g. positions, texture coordinates, normals, etc.), it's still fundamentally just a collection of bytes.

Superbuffers, in contrast, address "element memory," whose fundamental unit is some sort of "element." A common example of this type of GL memory today is the texture object. We have a block of memory that we first feed to GL using glTexImage*, but in that command we specify not only what the data is, but how to format it (RGBA, BGR, ALPHA, etc.). Once the memory is formatted, it forever stays that way. This type of memory is typically stored on the GL server side (e.g. GPU texture memory), and unlike byte memory, you can no longer gain access to the byte representation of that memory once you've created it. The superbuffers extension, as I understand it, is a generalization of element memory (previously available in the form of textures, off-screen pbuffers, etc.) so that we have greater flexibility in how we draw to this memory, re-use such memory for different operations, etc. The design of the API is such that (hopefully) the driver can make performance optimizations (e.g. avoiding expensive GPU buffer copies, etc.).

Hope this clarifies some issues. In summary, buffer objects and superbuffers handle different types of GL memory and the ways they are used.

Eric

Korval
08-16-2003, 11:57 AM
If that's true, it sucks. It greatly hinders transition from system memory vertex arrays and VBOs (apps will need 'regular' arrays for fallback, VBOs are much easier to implement there; interleaving array data was a *good* thing last time I checked).

I could have sworn I saw a stride. Maybe I was just looking at 'size', thinking it was the stride.

In any case, you're right; this sucks.

This is, yet more, evidence of the ARB being used as an arena for people to screw over their compeditors. Observe:

If you can't render to an interleved vertex array, the only way to do render-to-vertex-array stuff is to render to multiple buffers at once (unless you want to run your data multiple times for each component). Of course, ATi is right on top of this, with ATI_draw_buffers. nVidia isn't. nVidia gets screwed yet again. 3D Labs technically gets screwed (unless they have such an extension), but ATi probably was caching-in political coin for their support of glslang.

Looks like that article was right on the money; the ARB has become a battleground for getting ahead in the marketplace. And, of course, our needs are ignored.


It may be 'surprising' for apps when, say, id 1000 joins the pool of defined VBOs as soon as id 1 is created.

To me, that's a flaw in the whole glGen* structure. glGen* should always be required; they should never have allowed for objects to be implicitly generated simply by using a new integer.

The best way to make these memory blocks work like VBO's would have been to have functionality for attaching a memory buffer (a leaf) to a VBO object. That way, all your vertex array stuff looks the same.

Humus
08-16-2003, 12:15 PM
Originally posted by Korval:
This is, yet more, evidence of the ARB being used as an arena for people to screw over their compeditors. Observe:

If you can't render to an interleved vertex array, the only way to do render-to-vertex-array stuff is to render to multiple buffers at once (unless you want to run your data multiple times for each component). Of course, ATi is right on top of this, with ATI_draw_buffers. nVidia isn't. nVidia gets screwed yet again. 3D Labs technically gets screwed (unless they have such an extension), but ATi probably was caching-in political coin for their support of glslang.

Looks like that article was right on the money; the ARB has become a battleground for getting ahead in the marketplace. And, of course, our needs are ignored.

I think this sounds a little too paranoid. Ever considered that there might be technical reasons behind certain design decisions? It sounds more likely so to me. I think most if not all ARB participants honestly care deeply for the API and works for its best, but of course everyone sees things from their particular vendor's point of view. And of course everyone wants extensions to work on their particular hardware, even if that may reduce the beauty of the interface. Not all ARB work turns out as perfect, but then there's no vendor's hardware that's perfect and no driver team has infinite resources. Considering the amount of needs, wants and opinions that goes into the work of each extension I think the ARB has actually done incredibly well in most cases.

zeckensack
08-16-2003, 12:27 PM
Yeah.
Also, if I'm not mistaken, the superbuffers thing is preliminary workgroup material and hasn't been voted on. I see an ATI logo and an ATI employee's name on the front page, so quite obviously, this is based on ATI's vision.
All of that may change yet.

Korval
08-16-2003, 02:21 PM
I think this sounds a little too paranoid. Ever considered that there might be technical reasons behind certain design decisions?

Certain design decisions, sure. This one, in particular? No.

The hardware certainly doesn't care whether the pointer is in video or AGP memory, or whether the memory was a render target a few cycles ago; it still supports a stride regardless of the memory's location. Since the hardware supports it just fine, the API should support it.

The conclusion about ATi's politicking comes from this fact, plus the fact that ATi's hardware is not terribly affected by this. Because they permit writing to multiple buffers, one can simply allocate several buffers and write individual components to them. Therefore, the lack of a stride is not a concern for developing on ATi hardware.

This is clearly a bad idea. Yet, here it is.

ATi has done some good things, both for hardware and OpenGL development. However, the fact remains that the ARB has been making some questionable decisions of late, and there must be an explaination for it. Most of these questionable decisions have been falling in ATi's favor, or at the very least, hurting nVidia.

Do you have a better explaination?


I see an ATI logo and an ATI employee's name on the front page, so quite obviously, this is based on ATI's vision.

I wouldn't say that it is only based on ATi's vision. ATi is certainly part of the superbuffers workgroup. This document could simply be a demonstration of how far the workgroup has gone. While this could simply be what ATi wants rather than where the workgroup is going, it hurts ATi if this document is vastly different from what the workgroup does. After all, this document has ATi's name on it; if it's incorrect, then ATi looks like they're spreading misinformation.

In any case, you are correct that this document certainly isn't a finalized spec. And adding a stride is no more difficult than a 2-line change to that spec, so the final spec could very well have a stride. But the fact that the stride is missing is worrysome; how do you overlook such a fundamental part of any vertex array API, unless you specifically removed it for some reason?

harsman
08-17-2003, 03:59 AM
Well, you can only write four floats to a render target at most. Since most vertex attributes are four component vectors the limitation about interleved arrays sort of makes sense. Still, it's weird that you can't pack i.e. a two component position and u.v texcorods into one four component vector. Having some way of unpacking the data when it's read from the membuffer would definitely be useful. Of course, both nvidia and ATI support 16-bit float textures, so why we cant use that to pack more data in I don't know.

Korval
08-17-2003, 12:17 PM
Well, you can only write four floats to a render target at most. Since most vertex attributes are four component vectors the limitation about interleved arrays sort of makes sense.

It makes sense to the extent that interleving would not be very useful. It should still be expose, for the day when fragment programs can output multiple components to a single buffer.


Of course, both nvidia and ATI support 16-bit float textures, so why we cant use that to pack more data in I don't know.

The limitation isn't one of 128-bits of data; it's that you can only write out 4 components.

Mazy
08-17-2003, 01:33 PM
well, not that is might be the fastest way, but since you know the x,y position of the pixel youre writing to, you can easily calculate a vertex in one, and a normal in the next pixel ( odd/even) with an simple 'if'

Ostsol
08-17-2003, 04:06 PM
Another way to do it is to simply manipulate your data however you want in vertex shaders. Techinically, one could simply pack two 2d texcoords (for example) into each pixel of a buffer and extract them in the shader. Heck, you could even split data amongst multiple arrays and combine them in the vertex shader.

davepermen
08-19-2003, 07:41 PM
wich is, i guess, the way we'll have to do it..

and the way i'm doing it even now http://www.opengl.org/discussion_boards/ubb/biggrin.gif so i don't have problems not having a stride..

MZ
08-20-2003, 06:52 AM
I'm curious why they have abandoned the previous method of binding GLmem to array, as shown in the GDC03 presentation (http://www.opengl.org/developers/code/gdc2003/GDC03_ARBSuperbuffers.ppt) . 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
08-20-2003, 01:41 PM
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
08-20-2003, 02:34 PM
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
09-02-2003, 03:49 PM
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 (http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0308e&L=directxdev&D=1&F=&S=&P=745) , it looks like the technique is nothing unusual in DirectX.




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

dorbie
09-02-2003, 04:49 PM
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
09-02-2003, 07:11 PM
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
09-03-2003, 11:41 AM
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.