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