Official feedback on OpenGL 4.0 thread

[Jan]

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.

[Stephen A]

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.

[BarnacleJunior]

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.

[Stephen A]

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.)

[Alfonse Reinheart]

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.

[remdul]

Good stuff, but more DSA please!

[Jean-Francois Roy]

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.

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.

[elFarto]

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

[pjcozzi]

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

[Rob Barris]

Epic fail for GL_ARB_sampler_objects

If you have any more ... constructive ? detailed ? ... thoughts to add on that topic, could you type them in here?