OpenGL 3.0 is here (finally)

Monday 11th August 2008, 10:21:00 PM, written by Richard Connery

Nearly a year since the expected release of the OpenGL 3.0 specifications, the Khronos group has finally unveiled them. The press release mentioned some of the new features:

Vertex Array Objects to encapsulate vertex array state for easier programming and increased throughput;

non-blocking access to Vertex Buffer Objects with the ability to update and flush a sub-range for enhanced performance;

full framebuffer object functionality including multi-sample buffers, blitting to and from framebuffer objects, rendering to one and two-channel data, and flexible mixing of buffer sizes and formats when rendering to a framebuffer object;

32-bit floating-point textures and render buffers for increased precision and dynamic range in visual and computational operations;

conditional rendering based on occlusion queries for increased performance;

compact half-float vertex and pixel data to save memory and bandwidth;

transform feedback to capture geometry data after vertex transformations into a buffer object to drive additional compute and rendering passes;

four new texture compression schemes for one and two channel textures providing a factor of 2-to-1 storage savings over uncompressed data;

rendering and blending into sRGB framebuffers to enable faithful color reproduction for OpenGL applications without adjusting the monitor's gamma correction;

texture arrays to provide efficient indexed access into a set of textures;

32-bit floating-point depth buffer support.

The new version of the OpenGL Shading Language, GLSL 1.30, provides front-to-back native integer operations including full integer-based texturing, integer input and outputs for vertex and fragment shaders and a full set of integer bitwise operators. It also improves compatibility with OpenGL ES, adds new interpolation modes, includes new forms of explicit control over texturing operations, provides additional built-in functions for manipulating floating-point numbers and introduces switch statements for enhanced flow control within shader programs.

The full specs are now available online.


Discuss on the forums

Tagging

graphics ± opengl, khronos, siggraph


Latest Thread Comments (24 total)
Posted by I.S.T. on Tuesday, 12-Aug-08 17:47:58 UTC
That would be SGI, not Apple.

Posted by frogblast on Tuesday, 12-Aug-08 18:13:43 UTC
OpenGL was developed by SGI (a very long time ago) and eventually moved to Khronos.

OpenCL was developed by Apple, and recently proposed to Khronos.

Posted by Rys on Tuesday, 12-Aug-08 19:00:59 UTC
My main concern here is that Direct3D doesn't exist anywhere but Windows. OpenGL is still the only good way to program 3D graphics on myriad platforms, including the one that just got 5% PC market share in North America, yet there's no denying that it's some distance behind D3D10 in terms of giving a sane programming model with no extension and vendor hell. 3 does little to change my mind, despite Timothy's nice dissection.The need for a clean object model and a strong push to deliver it has been around for years now, ever since D3D9 showed up.As someone who rarely cares to touch Windows any more unless forced into it, I'm a little upset. I was hoping 3 would let me get enthusiastic about tools dev on Linux :(

Posted by I.S.T. on Tuesday, 12-Aug-08 20:13:29 UTC
Quoting frogblast
OpenGL was developed by SGI (a very long time ago) and eventually moved to Khronos.

OpenCL was developed by Apple, and recently proposed to Khronos.
I read the C as a G. >.

Posted by jordi on Wednesday, 13-Aug-08 05:06:47 UTC
I think people is too flamable.

Ok. It is not as nice as we wanted. It is not so clean. And what? Any middle or big size application will not be issuing GL commands all over its code, but have a thin layer over the API. Make this layer as clean as you want, because that is what you will be using it all the time.

I think OpenGL will prevail because, as already stated by many people, it is the only option for many platforms. And it will evolve more.

j.

Posted by MrGaribaldi on Wednesday, 13-Aug-08 11:20:06 UTC
But it took 2 years to maintain status quo, only upgrading a few extensions to core and adding a few new extensions, and the most interesting one (http://www.opengl.org/registry/specs/EXT/direct_state_access.txt) might not be supported by AMD, making it useles...

It's nice that they added deprecation, but what are the chances that they will actually remove the functions later when they didn't manage to remove them now? There are no timeline telling us when to expect them to disappear, which means we can't schedule when we need to have removed them. And that means the old code bases will stay the way they are, and the argument to delay/not removing them because of said code bases will stay as valid as it is today.

Sure, those who really need to be cross-platform will continue using OpenGL, after all there is no other viable alternative. But what developer will choose OpenGL over DirectX?
Unless there is a requirement for cross-platform or a huge hatred for MS, there really isn't much reason to choose OpenGL with driver problems, lack of supported features and an apparent lack of direction.

That doesn't really bode well for the future of OpenGL.

Posted by Arwin on Wednesday, 13-Aug-08 12:40:58 UTC
Actually, deprecated functions this version should be gone in the next version. That's why some people call for a short time before the 3.1 spec is released, to speed up that process and right some wrongs.

Posted by Chris Lux on Wednesday, 13-Aug-08 12:58:24 UTC
Quoting Arwin
Actually, deprecated functions this version *should* be gone in the next version. That's why some people call for a short time before the 3.1 spec is released, to speed up that process and right some wrongs.
should!

Michael Gold (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243193&fpart=7) said this morning:
Quote
Version 3.0 is fully backward compatible with all versions since 1.0. However significant legacy functionality has been deprecated, i.e. marked for removal in the future. This allows you to start using all the new features today, without having to rewrite a single line of existing code. But it serves as fair warning, t*he next version may remove some or all (or none) of the deprecated features, depending on the mood of the ARB at that time.*
who is trusting the ARB after this?

in the same post he also states:
Quote
Here's why I believe you should avoid shipping code which requires a lite context.
so whats up with that? they give us the option of a lean and mean API with the option for better performing drivers in the lite mode, but we are not supposed to use it?

this man was one of the main editors of the long peaks api...

Posted by GLX on Thursday, 14-Aug-08 07:26:03 UTC
NVIDIA put up beta OpenGL 3.0 drivers tonight - this was announced at the SIGGRAPH BOF.

Posted by compres on Friday, 22-Aug-08 23:13:45 UTC
Quoting jordi
I think people is too flamable.

Ok. It is not as nice as we wanted. It is not so clean. And what? Any middle or big size application will not be issuing GL commands all over its code, but have a thin layer over the API. Make this layer as clean as you want, because that is what you will be using it all the time.

I think OpenGL will prevail because, as already stated by many people, it is the only option for many platforms. And it will evolve more.

j.
Apologists...

Above post is proof they are there even in the worst of disgraces.


Add your comment in the forums

Related graphics News

Diving into Anti-Aliasing
Travelling in Style: Beyond3D's C++ AMP contest
Beyond Programmable Shading CS448s first slides available
Khronos release OpenGL 3.3 and 4.0
Mazatech release AmanithVG 4.0, supporting OpenVG 1.1
[Analysis] TSMC 40G to deliver up to 3.76x the perf/mm^2 of 65G & Power Implications
Old News: AMD CTO resigns, NVIDIA CFO retires, DDR3 for MCP7A, S3, etc.
SwiftShader 2.0: A DX9 Software Rasterizer that runs Crysis
S3 launches DirectX 10.1 Chrome 400 GPUs
GPGPU and 3D luminaries join 3D graphics heavyweights