Official feedback on OpenGL 4.0 thread

Khronos Unleashes Cutting-Edge, Cross-Platform Graphics Acceleration with OpenGL 4.0

Open standard 3D API specification available immediately; Provides performance, quality and flexibility enhancements including tessellation and double precision shaders; Tight integration with OpenCL for seamless visual computing

March 11, 2010 – San Francisco, GDC 2010 – The Khronos™ Group today announced the release of the OpenGL® 4.0 specification; a significant update to the most widely adopted 2D and 3D graphics API (application programming interface) that is deployed on all major desktop operating systems. OpenGL 4.0 brings the very latest in cross-platform graphics acceleration and functionality to personal computers and workstations and the OpenGL standard serves as the basis for OpenGL® ES, the graphics standard on virtually every shipping smart phone.

The OpenGL 4.0 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.00 update to the OpenGL Shading language in order to enable developers to access the latest generation of GPU acceleration with significantly enhanced graphics quality, acceleration performance and programming flexibility. This new release continues the rapid evolution of the royalty-free OpenGL standard to enable graphics developers to portably access cutting-edge GPU functionality across diverse operating systems and platforms. The full specification is available for immediate download at http://www.opengl.org/registry.

OpenGL 4.0 further improves the close interoperability with OpenCL™ for accelerating computationally intensive visual applications. OpenGL 4.0 also continues support for both the Core and Compatibility profiles first introduced with OpenGL 3.2, enabling developers to use a streamlined API or retain backwards compatibility for existing OpenGL code, depending on their market needs.

OpenGL 4.0 has been specifically designed to bring significant benefits to application developers, including:
[ul][li]two new shader stages that enable the GPU to offload geometry tessellation from the CPU;[]per-sample fragment shaders and programmable fragment shader input positions for increased rendering quality and anti-aliasing flexibility;[]drawing of data generated by OpenGL, or external APIs such as OpenCL, without CPU intervention;[]shader subroutines for significantly increased programming flexibility;[]separation of texture state and texture data through the addition of a new object type called sampler objects;[]64-bit double precision floating point shader operations and inputs/outputs for increased rendering accuracy and quality;[]performance improvements, including instanced geometry shaders, instanced arrays, and a new timer query.[/ul][/li]Lastly, Khronos has simultaneously released an OpenGL 3.3 specification, together with a set of ARB extensions, to enable as much OpenGL 4.0 functionality as possible on previous generation GPU hardware; providing maximum flexibility and platform coverage for application developers. The full OpenGL 3.3 specification is also available for immediate download at http://www.opengl.org/registry

Amazing… you keep getting more and more astonishing!

EDIT: I just had a look on the extension, it’s so much more than whatever I could have expected! I think there is a lot of developer little dreams that just happened here.

Ok, no GL_EXT_direct_state_access but still.

Wow! I was checking this forum often the last few days (knowing that GDC2010 was going on). But as nothing was announced until now I almost began to believe there would be no new OpenGL spec.

Very nice! Will be reading the specs right now. Good to see that OpenGL is still actively being developed and that the core specs are moving along with the newest hardware available.

Can’t wait until we get the first OpenGL 4.0 drivers (hurry AMD! ;)) so I can play with this new baby (actually I would have to buy myself some new hardware as well, but that was already planned).

Great! Congratulations to Khronos and all people involved.

A sampler binding is effected by calling
    void BindSampler( uint unit, uint sampler );
with <unit> set to the texture unit to which to bind the sampler and <sampler> set to the name of a sampler object returned from a previous call to GenSampler. 

I’m really not sure about this … I was dreaming about it but keeping the “texture unit” idea was an issue of texture objects… Does it require it? I don’t think. Instead of BindSampler, I thing we were expecting a UniformSampler

It would have removed the texture unit limitation…

congratulations!

reading through 3.3 and 4.0 spec atm. sadly no direct state access, but i am very impressed but the pace OpenGL is evolving currently.

keep up the excellent work!

-chris

Congratulations!

Any word on Intel support?

Stephen: You just made the joke of the day! :wink:

It seams more honest from Intel to keep quiet.

I’m not even waiting for an OpenGL 2 implementation anymore.

Hello,

The new glext.h (rev 59) has a corrupted line:

#ifndef GL_ARB_draw_buffers_blend
#define GL_@@@ 0x9110
#endif

This part in rev 58 used to be:
#ifndef GL_ARB_draw_buffers_blend
#endif

Yeah, it’s wishful thinking on my part. But hey, imagine an Intel spokesperson announcing that, “we are planning to ship OpenGL 3.3 support by the end of May!”

Of course, reality kicks soon, when someone asks for the 100th time on how to perform offscreen rendering:

  • User trying to create an invisible window or other broken hacks: “Why do I keep getting garbage back?”
  • Linking to the OpenGL FAQ: “You are not passing the pixel ownership test. Use FBOs.”
  • “But FBOs don’t work on Intel.”
  • “Try pbuffers.”
  • “Nope, no pbuffers either.”
  • “How about a sacrifice to Kthulu?”
  • “Wha…?”
  • “Just kidding. Software rendering for you.”

That much for “high performance graphics” on Intel…

Any idea if a new quick reference card is coming along?

I can’t find any reference of GL_NV_texture_barrier feature in the new spec… anyone got more lucky?

That would be a big miss I think. :stuck_out_tongue:

Or an updated version of the online OpenGL reference pages. That would be great (currently the top menu of the OpenGL page still lists the OpenGL 3.2 reference pages as `under construction’).

edit: so far it looks good to me. I’ve mainly been looking into the OpenGL and GLSL 3.3(0) specs for now. Include directives and explicit attribute locations are nice additions to GLSL. Extra blending functionality, separate sampler states and timer queries are nice as well. All in all, it looks like a solid release to me!

Will be chewing through the OpenGL 4.0 and GLSL 4.00 specs now :D.

Extraordinary work!!!
Two versions in the same day. I’m amazed!
The revolution is started. :slight_smile:

When the new (GL 4.0) beta drivers will be available? I cannot read specification without ability to try anything. ;). Last time they were released together with the new spec (the same day), but now we are not so lucky.

P.S. Although a new GLSL spec is not released, according to GL spec. 4.0 the new revision number will be 4.0. It seems inconsistent to jump to ver. 4.00 after 1.50. :frowning:

It’s hard to call it “revolution”, I was hoping to see all glBinds deprecated and use only DSA (at least in core profiles).

It is released. It’s called GLSL 4.0 to match OpenGL 4.0 because there is a GLSL 3.3 for OpenGL 3.3.

What if OpenGL 3.4 get released and GLSL versions are called 1.6 for OpenGL 3.3 and 1.7 for OpenGL 4.0.

Ok true, sound inconsistent but well. At least with all those versions of GLSL and OpenGL you now which one come with which one.

DSA still look “in progress” as I find a couple of references in the extensions files.

Fingers crossed … with (OpenGL 3.4 and) OpenGL 4.1 at Siggraph 2010!

Agreed; while its nice to see OpenGL has finally caught up with DX11’s feature set the API is still the same old API which drove me away and DSA, the best thing to come out of the whole GL3.0 farce, is still missing.

I’ll swing back around again when GL5 is out; maybe that’ll have something to tempt me back from D3D11…

DSA would be nice I agree, BUT catching up the hardware has much greater priority in my opinion.

DSA is not something that can be cleanly integreted into OpenGL without much work. It requires API redesign. Bind methodology has been with OpenGL from the beginning.

I think that OpenGL 4.0 feature set is great.
Try to notice the beauty of it’s initial design and how cleverly authors of this API has integrated new features into so old architecture.

It’s much easier to throw away old API (D3D9) and to create nicely designed new one (D3D10+). But OpenGL authors can not do that. And I think that they did great job with OpenGL 4.0

Yeah, it’s wishful thinking on my part. But hey, imagine an Intel spokesperson announcing that, “we are planning to ship OpenGL 3.3 support by the end of May!”

Of course, reality kicks soon, when someone asks for the 100th time on how to perform offscreen rendering:

  • User trying to create an invisible window or other broken hacks: “Why do I keep getting garbage back?”
  • Linking to the OpenGL FAQ: “You are not passing the pixel ownership test. Use FBOs.”
  • “But FBOs don’t work on Intel.”
  • “Try pbuffers.”
  • “Nope, no pbuffers either.”
  • “How about a sacrifice to Kthulu?”
  • “Wha…?”
  • “Just kidding. Software rendering for you.”

That much for “high performance graphics” on Intel… [/QUOTE]

Well, I stopped waiting for an OpenGL 2 drivers for Intel hardware when they arrived.
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.

Philipp

The bad news is that not every release will have every feature that every developer wants. The good news is that the releases are now spaced by months rather than years… ( http://en.wikipedia.org/wiki/OpenGL )

3.0 - July 2008
3.1 - May 2009
3.2 - Aug 2009
3.3 / 4.0 - Mar 2010.

So, as has been the custom for those releases, make your own assessment of what you like or don’t like, and keep the feedback coming.

If a dozen separate developers all shout loudly for DSA for example, this could effectively raise its priority for an upcoming release (assuming the objections of some of the implementors can be reconciled).