Well, i was going to complain, that although it’s called “4.0” it does not contain DSA or multi-threaded rendering.
But after more carefully sifting through all the material, i am actually pretty happy with all the progress. And since tessellation does change so many things, i think it is OK to call it “4.0”.
Good job guys!
Now that OpenGL has caught up with the most important features of DX11, i really hope 5.0 gets a more thorough API clean-up.
Jan.
I’m skimming through the new specs and it is evident that much of the new functionality is based on community feedback. I cannot begin to describe how awesome that is! It’s saying a lot about the new direction of the Khronos board - glad to see the API sailing at full speed again.
And bonus points for validating the design of OpenGL 3.2 (no deprecated features.) 
I’m writing this on my old laptop with it’s Intel integrated graphics, which supports OpenGL 2.1, lots of extensions, including GL_ARB_framebuffer_object and GLX_SGIX_pbuffer.
The only missing feature from your list is GL_MESAX_elder_gods_sacrifice.
What do you mean by old? Most complains have to do with the GMA950/XP combo found in most netbooks, followed by 915 and 865 chips. Newer chips, like the 4500HD, seem to support FBOs under Vista or newer (but still not FBO_blit. What you were thinking of implementing bloom on Intel IGPs? Naughty boy, this is Intel we are talking about!)
That said, I think someone issued a pull request for GL_MESAX_elder_gods_sacrifice, targeting Mesa 7.9 / Gallium. Should be interesting.
I’m another dev that wants DSA and some sensible thread model (contexts that create command lists are fine) before I leave DX11. But as important for DSA, and something no one is talking about, is a binary standard for shader IL and an offline compiler. Some shaders, especially GPGPU shaders, are getting long, and taking a very long time to compile (like 30seconds or more). This is an enormous annoyance with OpenCL especially. DX and CUDA both support portable ILs with offline compilation. The other thing with ILs, beside startup speed, is that it gives the dev a way to visually inspect a shader for branching, register usage, etc. The DX IL (which is almost 100% compatible with ATI’s IL) is very nicely formatted and makes diagnosing shader performance issues much easier.
All I can say is +1 to DSA and +1 to binary shaders (compile into common, high-level IL that is then read and optimized by the IHV drivers. Significantly faster than parsing from source every single time.)
To be honest, DSA is syntactic sugar; it would be very nice to have, but I can live without it.
But they just introduced 2 new shader stages. The ability to separate program objects is only going to become increasingly more relevant. Also, binary shaders. I don’t care much about an intermediate language or anything; I just want to be able to get a binary shader and save it, then load it back later and use it.
Oh, and BTW: someone (I forget who) will be very happy with ARB_blend_func_extended. Especially since it’s core 3.3, which means that most if not all 3.x hardware will be able to use it.
Good stuff, but more DSA please!
OpenCL supports binary kernels. See section 5.4.1 of the 1.0 specification and the clCreateProgramWithBinary command. It is true that the IL is not portable and that it may be invalidated for any reason, but this does not negate its primary benefit of speeding up launch times.
Yay for GL_ARB_shader_bit_encoding!
Epic fail for GL_ARB_sampler_objects 
Yay for GL_ARB_explicit_attrib_location, but where’s the updated separate_shader_object spec…?
Regards
elFarto
I’m very happy with the new features in GL 4. I am glad to see many of them in GL 3.3 to support old, lol, current hardware.
I have a question regarding 64-bit support: this is a GL 4 feature that requires next generation hardware, correct? Page 14 of the GL 3.3 spec includes ui64 as a type descriptor but section I, which lists new features, does not mention 64-bit.
Also, does anyone know how the 64-bit pipeline is expected to perform?
Regards,
Patrick
If you have any more … constructive ? detailed ? … thoughts to add on that topic, could you type them in here?
very nice work and keep up the great pacing (thanks for #include and transform_feedback3)!
sampler objects look good to me (same as dx10 I think).
I would have hoped that GL_ARB_explicit_attrib_location would also work for vertex shader outputs, and therefore bring along separate_shader_objects as well… that and some form of binary representation for load times, would also be my picks for very useful additions.
The buffer centric workflow GL offers is really nice, but Dx still has an edge when it comes to shader convenience. (and tools, can’t khronos not just sponsor gdebugger for all)
That would be me! (http://www.opengl.org/discussion_boards/…1694#Post251694)
And yes, i am VERY happy about that, i did not think that anybody would take it seriously.
Jan.
ARB_blend_func_extended is called dual source blending in DX10, but got dropped in DX11 afaik.
And I see there is a link on the front page for an OpenGL 4.0 quick reference card! Also the link announcing online OpenGL 3.2 reference pages is changed so that it now announces OpenGL 4.0 reference pages. Still under construction though, I hope these will be available soon… I still peek at the 2.1 pages sometimes to check quickly how a certain function worked again.
Can you elaborate on “dropped” ?
DX11 cards still need to be able to run DX9/DX10 software, so I don’t see how this feature could be cut from silicon unless it has simply become another programmable behavior masquerading as FF behavior… or do you mean that it’s just not in the DX11 API any more.
First of all, great job for the releases. It is really good to see covering dx10 features (Indirect draw commands, seperate sampler states …) and having support on dx11 before market is going mad about it…
I want to comment on sampler objects; we bind samplers to texture units but when we want to bind a texture to same unit, we need to set active texture unit and then bind texture to the related target on same unit. We need actual DSA in here. Newborn features seem to expose DSA behaviour but old habits (binding points) cause crawling in my skin… Actually what I want is management of such state values in shader code (material idiom). CgFX got this, HLSL got this, but when we want some material approach in OpenGL we need to coordinate GL code with GLSL code all the time and need to “trust” each other
ARB_blend_func_extended is called dual source blending in DX10, but got dropped in DX11 afaik.
… why? What, did they think having more powerful blending function was a bad idea?
Newborn features seem to expose DSA behaviour
That’s actually a good thing. While it makes the API a bit inconsistent, it means that whenever they do get around to a DSA-style overhaul, that there will be fewer legacy-style functions lying around.
Someone posted a comment on the OpenGL homepage news story. Hopefully they won’t mind if I move the comment over here so it can get some clarification and worthy feedback:
First, congratulations on the milestone. Second, as a cross-platform developer I would like to use OpenGL exclusively but it’s commercially inviable to use it on Windows, due to the fact that OpenGL just doesn’t work on most machines by default, which forces me to target my game to both DirectX and OpenGL. The OpenGL shortcomings on Windows aren’t a big deal for hardcore games where the users are gonna have good drivers (although they are a cause of too many support calls which makes it inviable anyway) but it’s a show-stopper for casual games.
If it was me in charge of OpenGL I wouldn’t even bother coming up with new versions of the standard until this situation was rectified. I really don’t understand why the effort isn’t put in working with Nvidia, Ati and Microsoft to rectify the situation. If Microsoft wont help just bring back glsetup! Having to run an installer on installation of your product would be fine. But currently the user has to find good drivers by himself and then reboot, this is unacceptable. DirectX on the other hand can be streamlined as part of the installation. Until OpenGL isn’t expected to just work in any Windows box it is dead in the Windows platform. Do something about this please.
[quote=“Rob_Barris”]
If you have any more … constructive ? detailed ? … thoughts to add on that topic, could you type them in here? [/QUOTE]
The idea of having a textures and samplers separate is so that you can bind the texture object directly to the shader uniform/uniform buffer so you didn’t have to play music texture units when you change the shader (rebinding the right texture object to the right texture unit).
Regards
elFarto
I really don’t understand why the effort isn’t put in working with Nvidia, Ati and Microsoft to rectify the situation.
Because none of them are responsible for it. ATI’s drivers are OK, and NVIDIAs are pretty good. The problem is Intel. Their drivers are terrible. And if you’re making casual games, you want to be able to play them on Intel integrated chipsets.
The idea of having a textures and samplers separate is so that you can bind the texture object directly to the shader uniform/uniform buffer so you didn’t have to play music texture units when you change the shader (rebinding the right texture object to the right texture unit).
No it isn’t. The purpose of separation is exactly what is said in the overview of the spec: to be able to use the same texture data with different filtering parameters without having to do a bunch of texture parameter state changes. This is very valuable.
And personally, I’ve come to rather like the game of “music texture units”: it allows me to change exactly what state I want. I can use the same shader with different textures very, very easily.
Under the system you’re suggesting, I have to change the program itself to swap texture sets. This is more expensive, both in terms of the number of function calls and how the hardware handles it.
Personally, what I would like to see is full separation of program objects (compiled/linked programs) from program object state (uniforms, etc). UBOs are about as close to that as it gets, so I’m fairly content with that compromise.