The ARB announced OpenGL 3.0 and GLSL 1.30 today

[NeARAZ]

Whoa, GL3 finally sees the light of the day. Whoa-whoa, the response to that was... well... "interesting".

So just to recap, what I was expecting from GL3 (link, link, link):

1. Major cleanup of the runtime, resulting in simpler drivers, hence more stability and possibly even performance. Fail.

2. Make GLSL actually useable. Precompiled binary shaders, one offline compiler that does basic optimizations. Fail.

Without those two, OpenGL/GLSL is still quite unusable in the real world. Yeah, promoting some extensions to core is a nice gimmick (driver support is still an open question), thinking about "some quite possible deprecations that maybe perhaps someday we'll most likely do" is sure nice, yeah. And spectacular handling of public relations of the whole thing.

"Keep up the good work", what else can I say. Me back to fighting driver bugs.

[Brolingstanz]

Simon that strikes me as a way to mitigate the profusion of errors going forward.

The glStringi API and the new tokens for retrieving the major an minor version numbers together I think'll make it harder to do the wrong thing and play into the deprecation hand quite nicely.

[knackered]

is nobody going to tell us why the community weren't informed of this change in direction in january? or february? or march? ...etc.

[dor00]

is nobody going to tell us why the community weren't informed of this change in direction in january? or february? or march? ...etc.

Maybe because rest of us in the ARB members eyes, are just a bunch of idiots who dont need to interfere with big guys business?

The "big brothers" do whats best for us.. we dont need to disturb with our stupid ideas.

[Timothy Farrar]

So how about it mighty hardware vendors, when can we have extensions for the fabled ATI tesselator or Scattered writes?

Here's a quick list to include in your new 3.0 drivers:
-Geometry shader
-Tesselator
-Blend shader
-Seperate pre and post Z-discard shaders
-Post-rasterisation instancing (for multipass deferred shaders)
-Updatable resolution LOD textures
-ByteCode GLSL
-Precompiled binary save/restore
-Multi-threaded background buffer loading
-A way to query if wanted functionality is hardware supported or emulated in software

"Scattered writes" - OpenCL will be covering this I'm sure. Cross platform GPGPU is not a fully solved problem yet, even DX11 prototypes only are seeing a 2x performance improvement (out of say the 4x or 8x which is possible in theory) with this type of "compute shader" functionality (which is what scattered writes are for). So don't expect this to be figured out yet, and thus isn't core in GL or anywhere else.

"Geometry shader" - Is supported in extensions by Apple and NVidia. However wasn't the fast path on the hardware (in fact very slow). Other methods, such as Hystopyramids, showed much faster performance for similar functionality. Also NVidia's hardware only recently (200 series) made the updates to support better geometry shader performance. So really not as useful as you would think, and understandably out of core spec to make it easier for vendors to build GL3 drivers.

"Tesselator" - Lack of current cross platform hardware support, no reason to think about this now.

"Blend shader" - Lack of hardware support period. Not even in DX11 I believe.

"Seperate pre and post Z-discard shaders" - You can do this yourself with a branch in a shader. Or with stencil if you want a more hardware friendly path (due to 2x2 pixel quad packing into vectors for hardware).

"Post-rasterisation instancing (for multipass deferred shaders)" - What? I think you need to describe what you are looking for here, any why you cannot do this type of thing with current GL3 functionality.

"Updatable resolution LOD textures" - What do you mean here?

"ByteCode GLSL, Precompiled binary save/restore" - If you really get into the internals of both the order and (especially) newer hardware you will see that a common byte code for all vendors is a bad idea because hardware is way too different. All vendors would still have to re-compile and re-optimize into the native binary opcodes. So all you would be saving is parsing strings into tokens which really isn't much of a savings. Due to all the different hardware, shaders in the form of pre-compiled binaries really only makes sense in the form of caching on a local machine after compile, and perhaps might be something to request as a new feature.

"Multi-threaded background buffer loading" - You can map as many buffers as you want and fill them from whatever threads you want, so this is currently easy to do.

"A way to query if wanted functionality is hardware supported or emulated in software" - The GL3 standard provides a listing of required functionality (especially in texture formats) to the route forward for knowing what is supported seems rather clear. Now it is onto the vendors to create correct drivers.

Also cubemap arrays (different post) are not hardware supported on (many of the) NVidia cards?, so I wouldn't expect that to be core, but rather an extension if ATI sees that as worth while.

[Brolingstanz]

Judging from the DSA spec, NV has at least a couple of contenders in the works (NV_explicit_multisample (?), NV_texture_cube_map_array).

[ector]

[quote=Timothy Farrar]

"ByteCode GLSL, Precompiled binary save/restore" - If you really get into the internals of both the order and (especially) newer hardware you will see that a common byte code for all vendors is a bad idea because hardware is way too different. All vendors would still have to re-compile and re-optimize into the native binary opcodes. So all you would be saving is parsing strings into tokens which really isn't much of a savings. Due to all the different hardware, shaders in the form of pre-compiled binaries really only makes sense in the form of caching on a local machine after compile, and perhaps might be something to request as a new feature.

You're forgetting the #1 advantage of the token approach: Updated drivers will not break your shader compiles. Currently, nVidia can fix a bug in its parsing that renders a previously parsable program illegal, or a program can be illegal on ATI but legal on nVidia, while using just basic features but slightly out of spec syntax. This problem, which is a major one, DOES SIMPLY NOT EXIST on D3D and is the major reason why D3D has you compile the shaders into tokens first.

[Korval]

perhaps might be something to request as a new feature

Request as a new feature?

We have been requesting this for years!!!

The GL3 standard provides a listing of required functionality (especially in texture formats) to the route forward for knowing what is supported seems rather clear. Now it is onto the vendors to create correct drivers.

Longs Peak was going to give us real (implicit) checks. If you created a vertex array object with a certain format, you were assured that it would work in hardware. If the VAO failed to create, it wouldn't work in hardware.

GL "3.0" doesn't give us that. I want it back.

[dorbie]

I've been working with opengl for a few years now.
I think the 2.1 api is basically solid. I would much prefer to see an opengl ES approach to opengl 3.0. Ie strip out the parts of the API which suck. Immediate mode for one, since it is nearly impossible to optimise for. Plus i've seen so many CAD programs try to push 500k vertices per frame, and wonder why performance is so poor. Display lists are another, again these must be a nightmare to maintain at the driver level. Other bizare stuff such as glRectf ?? That really has no place in the API.

I'd also like to see frame buffer objects standardised rather than just be extensions. Plus, the ability to do multisampling with offscreen render targets. The current extensions to do this seem to be somewhat of a mess.

It would also be a novelty to have updated header files. The header files for windows are now 12 years old ? I mean, wtf.

Redact the "deprecated" stuff from the 3.0 spec and you have everything you asked for.

[Lord crc]

Trying to find something good about all of this, at least I have no more reasons <i>not</i> to buy that 4870x2 now...

I haven't had time to read it all yet, but it seems that what was delivered as OpenGL 3.0 now, would have been nice had it been released as OpenGL 2.0.