The ARB announced OpenGL 3.0 and GLSL 1.30 today

[ScottManDeath]

In November, "that other" is going to preview about how *next* generation hw features will be exposed.

The ARB so far failed to expose all features of current generation hw. And I am not even talking about their "information policy"

It took them 4 years to get vertex buffers into core (version 1.5, 2003). It has been part of "that other" 3D API (version 7.0) since 1999.

It also took 8 years to get render to texture functionality into an OpenGL core (version 3.0, 2008). It has been part of "that other" 3D API (version 8.0) since 2000.

[Rob Barris]

Scott, we have a pretty long list of what didn't make it into 3.0 (both relating to specific hardware func as well as API streamlining) and have already started work on feature binning for 3.1 and beyond. If there is a feature you want, and want to confirm with the working group that it's under consideration, the best thing you can do is be very specific about what is holding back your application in GL 3.0.

[ScottManDeath]

Access to individual samples of a multi-sampled render target, so one can do a custom resolve for HDR and MSAA or implement stencil routed order independent transparency. (http://developer.download.nvidia.com...lRoutedKBuffer)

Removing redundant ways of doing things. E.g. One FBO per render target vs. one FBO and then rebinding the render targets. Having multiple rendertargets increases that combination also.

"That other" API has exactly one way of doing this. Both the app and the driver/runtime know what a SetRenderTargets(...) means. Currently in OpenGL "3.0", the app has to guess what is fast and the driver has to guess what the user wants to do actually.

Currently I have one FBO for each number of active render targets and then I rebind the color attachment properly.

Or with the "new" ARB_vertex_array_object functionality in OpenGL "3.0". Let's say I want to render 20 characters, each one has the geometry stored in a separate VBO. And I have 5 different shaders, some using only vertex position (e.g. one for a depth only pre-pass, one uses texture coordinates in addition, another might also use tangents and binormals).

Do what shall I do? One VAO for each combination of character and shader (total = 100)? Or one VAO for each shader (total = 5), rebinding the character's VBO before rendering. Or one for each character (total = 20) , enabling and disabling client attributes depending on the shader?

Once I get a driver with VAO support, I think I will have one VAO for each combination of active attributes and then rebind the VBOs to it. I have no idea what is better.

In "that other API" there are clear boundaries defined as well as rules how stages can fit together if the downstream stage doesn't need certain data.

[Lord crc]

I'd like to say that in my opinion the whining here is largely because people had over 1 year to wrap their minds around what was promised as Long Peaks and get their hopes up, and not so much because GL 3.0 is flawed.

The main thing I wanted from OpenGL 3.0 was to make it easier for IHV's to make drivers for it. From where I'm sitting, OpenGL 3.0 fails completely at this. Right now, IHV's will still have to code all those "obscure" features to be OpenGL 3.0 compliant (one way or the other). So, as far as I'm concerned, OpenGL 3.0 brought nothing to the table.

If they had included a "lean and mean" profile with OpenGL 3.0, I think things would be a whole lot better.

[Korval]

Once I get a driver with VAO support, I think I will have one VAO for each combination of active attributes and then rebind the VBOs to it. I have no idea what is better.

There's no reasonable way that this is better. In fact, there's a pretty strong argument to be made that using VAOs this way is no different than simply not using them.

The whole point of VAO is to avoid the cost of binding buffer objects: avoiding the cost of glVertexAttribPointer. Thus, you should choose the methods that minimize calling this function.

For example, it is perfectly legitimate to have more attributes bound than a shader actually uses. Because of that, I'd suggest 1 VAO per "character" (or mesh, rather) and just let the implementation figure out that some go unused. That is, never call glVertexAttribPointer inside the main rendering loop. It should only be used for setup work.

It's not that I don't disagree with your premise of reducing the "redundant" ways of doing things, but this doesn't really fit that. The only thing that this misses from LP is the attribute immutability: that each binding point in an LP VAO would have been fixed at creation time. You could still change what buffer object was being used and what the offset into that buffer was on the fly.

Yes, I would rather have immutable objects where that immutability matters with regard to performance. But the VAO case is about the least objectionable case, since we know that the bottleneck is glVertexAttribPointer. The FBO case is more reasonable, as we don't really know a priori the right way to use it.

In "that other API" there are clear boundaries defined as well as rules how stages can fit together if the downstream stage doesn't need certain data.

There are rules about how stages fit together in GL 3.0 (and 2.x).

[Brolingstanz]

One FBO per render target vs. one FBO and then rebinding the render targets. Having multiple rendertargets increases that combination also.

I can't imagine that there would be significant perf advantages to having more than 1 FBO on current hardware, not having tested. If anything I would expect an arrangement like this in DX instead, where it would seem that higher API interaction overhead would make a tidy grouping of targets an efficient packaging.

However, ... (I'd pause at this point to dig up relevant spec issues that make the forward-looking case or argue advantage on the basis of efficient internal bookkeeping and whatnot, but I'm plum tuckered.)

[Leadwerks]

Another thing that should be said is that Ati's OpenGL 2.1 drivers (Catalyst 8.x) are not as bad as their reputation is.

You obviously don't do very heavy shader work because if you try rendering to an FBO with AMD's current drivers gl_FragCoord.y is inverted! If you render to the back buffer, it is not inverted, and it is not inverted on their older cards. So there is no consistent way to detect the problem and use a workaround.

The release of our next product is stalled because if I release it while this driver bug exists it will give us a bad reputation.

GL3 doesn't make things any easier, so AMD will continue to not provide working drivers, and OpenGL will continue to not work on half our market's hardware. How many bugs do you think are going to come up when they try adding all the SM4 extensions, without breaking compatibility with the rest of the API, that isn't even working right now?

One of the reasons I chose OpenGL was because I kept hearing about how OpenGL3 would be a huge cleanup, and I figured around the time our technology was mature, the driver issues would get sorted out with GL3. I did my part, but it turns out everything they said about OpenGL3 was a lie, and they've know it for 9 months without saying anything.

[Michael Gold]

I can't imagine that there would be significant perf advantages to having more than 1 FBO on current hardware

There are two advantages of using multiple instances of objects like VAO and FBO. First, you avoid some of the API overhead by binding a single object instead of making multiple API calls to achieve the same state vector. Second, and probably more important, is the fact that some implementations can avoid performing redundant validation if you treat the object as if it were immutable after initial setup. Validation is perhaps the single most time consuming operation within the driver, and caching the results of validation within the object can reduce this overhead.

Immutable objects, as Longs Peak intended to deliver, prevent the developer from dirtying the state of the object. You can achieve much of the same effect by simply never modifying object state after creation, although you cannot eliminate the overhead completely under the current object model. Instead, simply create a new object for each unique state vector, or at least those which are most frequently used. Whether the incremental performance gain of immutability is more important than the lost flexibility of editable objects is an open debate, and in fact was one of the major sticking points in delivering on the ARB's original plan. (By the way Leadwerks, while the change in direction was unfortunate, the originally advertised plan was never a lie, and I can personally attest to this fact.)

Treating objects as immutable instead of thrashing object state may benefit legacy objects like textures and buffers as well as the new objects introduced in 3.0. The same principle applies.

[Korval]

By the way Leadwerks, while the change in direction was unfortunate, the originally advertised plan was never a lie, and I can personally attest to this fact.

A lie of omission is still a lie. It's one thing to decide to change strategy; it's quite another to not tell anyone about it for 8 months.

[Leadwerks]

I never cared about the immutable object thing. As a general rule I avoid them because they require more dynamic memory allocation, although the implementation on the GPU might be a completely different matter.

My gripe is that OpenGL3 does not make working AMD drivers any more likely than OpenGL 2.1. In fact, it makes them less likely, because it adds new features without simplifying anything. That is why I feel like we were deceived.