Agreed, DSA is the best thing that happen since … GLSL!
It’s amazing to see how small is the subset of the API can become when you use all those great extensions DSA and bindable buffer.
I think, it would be so great to have a simplified API but those days what I really waiting for is:
1 - bindable buffer 
1 - DSA
3 - a debugging profile
Second that list.
On the debug profile, I would like to see something similar to d3d10’s infoqueue. Basically it’s just a context wide info log the driver can dump messages, performance tips, warnings and errors into. This comes in awfully handy.
Out of curiosity, which vendors support DSA? For me, this is the single biggest reason to move to GL3 (everything else is the same old mess as GL2.1).
Afaik, currently only NVidia on GF8x and above.
DSA is not part of GL3. It is written to take into account the fixed function pipeline stuff like glMatrixMode
Just to touch on some of the items mentioned above -
conditional rendering - this is in GL 3.0 already. Shipped.
buffers for uniforms - you will see something in GL 3.1 in this area.
“mixed FBO formats”, there are some things that are relaxed under GL3 and GL3 capable hardware - it would help if you could elaborate on the usage you have in mind (see http://www.opengl.org/registry/specs/ARB/framebuffer_object.txt)..)
Geometry shader - not in the core spec in 3.0, only a shipping extension on NV at the moment. An ARB-neutral version of the GS extension has been posted here: http://www.opengl.org/registry/specs/ARB/geometry_shader4.txt
I’d like to see a lot of the DSA concepts in GL as well. It’s a topic that has a reasonable level of interest in the working group.
Custom resolve for multisampling, thanks for pointing that out.
(edited per correction regarding GS on AMD HW)
No, AMD has no support for geom shaders in 9.1 driver.
No, AMD has no support for geom shaders in 9.1 driver. [/QUOTE]
I appreciate the correction, will ask them about that.
DSA is not part of GL3. It is written to take into account the fixed function pipeline stuff like glMatrixMode
I gather it won’t be in core GL3.1, either? Any chance we’ll see an implementation outside nvidia any time soon?
If enough people make a big enough stink about it you bet your boots we’ll see it 
One thing to keep in mind is that the GL spec development plan has been re-worked to provide a more regular series of progressive improvements.
If a particular feature pops up too late or is too controversial to adopt in release N, it goes in a holding bin for consideration in N+1. A couple features that are going in 3.1 were of exactly this class, we originally wanted them for 3.0 but they didn’t lock down in time.
DSA is currently a pretty big extension in part because it is written against the complete set of historical GL API’s, I could advocate for a leaner version of it to integrate against non-deprecated features in a later revision of the core spec. That said there would be nothing stopping vendors from shipping it in extension form before that time (even beyond NVIDIA) if consensus was reached on a common extension definition.
No, AMD has no support for geom shaders in 9.1 driver. [/QUOTE]
Check the Catalyst 9.2 drivers ?
Sound good! Thanks so much Rob for this feedback, I think it’s just what the community was expecting!
Rob: I checked, still no geometry shader extensions (ARB or EXT).
i think at least nvidia has support for that:
http://www.opengl.org/registry/specs/NV/explicit_multisample.txt
Yup, but I believe the original suggestion was for future core additions, not additional extensions. With this and few other items in the GL3.x bag we’re more or less on par with DX10’s feature set - more or less.
What do you expect to do with such feature?
But NV_explicit_multisample is ugly. Compare this to 2D multisampled texture [arrays], and you see what I mean. NV_explicit_multisample looks like the easy way of getting basic functionality done, without having to do much work to make it orthogonal.
So when considering this for core, please make it shiny as D3D10 
That’s what I don’t really understand: What the point of having 2D multisampled texture arrays? I might be interested to control how the multisampling is resolved but this would be what? An access to multisampling data? Is there any expectation for deferred rendering antialiasing?
Well, if you want to do HDR and MSAA, you want to have control over the MSAA resolve, to do the tone mapping before you do the MSAA resolve:
E.g. take the following 4 samples of 1 pixel, by rendering a triangle edge into a floating point render target.
0, 1000,
0, 1000,
If you do the MSAA resolve, you get (0 + 0 + 1000 + 1000)/4 - 250, which could get tone mapped to a very bright value, e.g. 1.
Now if you do tone mapping first, you get ( tonemap(0) + tonemap(0) + tonemap(1000)+ tonemap(1000))/4 = ( 0 + 0 + 1 + 1)/4 = 0.5, a medium intensity value, this way properly anti aliasing the edge.
For the latter, you need access to the individual MSAA samples, e.g. via 2D MSAA textures.
Or if you want to have a stencil routed k-buffer: http://developer.download.nvidia.com/SDK…utedKBuffer.pdf