OpenGL 3.0 released

cube-with-matrix
The Khronos Group has released a new mile stone version of the OpenGL API: version 3.0, codename Long Peaks. While this is really good news, Khronos is still unable to communicate with the community.

The Good: a new release

The Long Peaks release of OpenGL API was announced more than a year ago and was supposed to be released last fall. However, despite the official announcement Khronos never made this release – and never published any note, hint or even unofficial statement.

Today, during the SIGGRAPH conference Khronos he published the new API version and made it available for download. The new version is described as an evolutionary step which includes many new features while still supporting old hardware.
The new features include, among others:

  • 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
  • transform feedback to capture geometry data after vertex transformations into a buffer object to drive additional compute and rendering passes
  • rendering and blending into sRGB framebuffers to enable faithful color reproduction for OpenGL applications without adjusting the monitor’s gamma correction

Besides the OpenGL 3.0 release the press note also highlights that the OpenGL working group works now closely together with the OpenCL working group to make sure both fit together quite well. OpenCL is a “royalty-free standard focused on programming the emerging intersection of GPU and multi-core CPU compute”, e.g. in the future OpenCL will be the language in question in case you want to make extensive calculations on your graphics card.

The Bad: the future

While all these news are pretty good news, there are indeed some shadows. First of all the API itself is nice, but it will take some time until the graphic card developers will pick it up. According to a Phoronix post Intel hasn’t even started looking at OpenGL 3.0. Also, Nvidia and ATI/AMD extended the old OpenGL API in their implementations anyways to better support their modern hardware so many of the new features of the OpenGL API were already out in the wild quite some time. Also, the question of when the free X drivers will support the new OpenGL depends on when Mesa 3D, the free OpenGL implementation, will support OpenGL 3.0. The Mesa project recently picked up quite some development speed, but before the last release it seemed to be almost dead.

Another, quite dark shadow is the Khronos group itself. OpenGL 3.0 was necessary, but DirectX 11 is already in the pipe. OpenGL must be comparable to it, and it doesn’t look like that the 3.0 API matches that requirement. However, the Khronos group obviously totally fails to manage a release: delaying a release is understandable, but not giving out *any* kind of information, not even a single piece of it, is not bad, that is horror. In fact, all official channels (newsletter, forum, etc.) where dead for more than a year and gave everyone the feeling that the project itself is not alive anymore, that something bad has happened and the ship sunk before anyone could tell the users.

Such behavior leads to the loss of faith and trust by the developers and vendors – and an API without trust and faith is worthless. So while Khronos invested work to bring out the next API they totally neglected the necessary work to keep in touch with their community (hardware vendors, developers, projects, etc.). How can you blame a vendor switching from OpenGL to for example DirectX when an API release was delayed for almost a year without any further notice?

If Khronos handles the next release as they handled this one, OpenGL might already effectively be dead before the first beta version.

16 thoughts on “OpenGL 3.0 released”

  1. How is the situation once we have Gallium3D-drivers? Will we still need hardware vendors to support OpenGL 3.0?

  2. Well, Gallium3D is an architecture to build graphic hardware drivers. The aim is to make it much simpler to develop such drivers.
    Additionally, Gallium3D will offer an unified API to the high-level graphics API, meaning OpenGL. So Mesa would not have to implement several hardware/driver backends (like it is doing now) but only a Gallium3D backend.
    So basically the situation will be easier for the people who implement the newest OpenGL API. Also, it will be easier to develop graphics drivers, and last but not least improve the performance at that point.

  3. Thanks for the explanation.

    But I’m still not 100% sure if i got it right, so please correct me if I’m wrong: I read that with Gallium3D it’s easily possible to implement OpenVG and isn’t that like creating whatever API you want? So could someone if he feels the need just create something new, call it e.g CoolGL and let it compete with DirectX 11? Of course it would only work on graphic cards with Gallium3D-drivers. But I think Gallium3D is LGPL, so proprietary drivers could also use it, right? Or am I misunderstanding something?

  4. As you can see here
    http://tech.slashdot.org/tech/08/08/11/2135259.shtml
    developers are already more than angry with Khronos. For many of them, OpenGL lost all its credibility; this release should have brought a fresh new api, directx10/11 features, and so on; instead is just 2.x (yes, no api change, backwards compatibile) with some extensions added inside the core spec.

    I don’t know about hardware vendors, but this article
    http://www.phoronix.com/scan.php?page=article&item=opengl_3&num=1 says it pretty well: AMD and Intel aren’t interested in supporting OpenGL3 in the short period. NVidia maybe is already writing a compliant driver; but I’d like to have good free 3D drivers for gaming and cad, and AMD/Intel will not bring them to us.

    Our last hope is Gallium3D: if it succeeds in being a useful driver architecture, and if it will be possible to develop good opengl2/3 drivers with that without all the problems that the developers are pointing out right now in the forums (another pledge not kept by khronos: a new api that matched current hardware, so writing compliant drivers shouldn’t be a PITA), well, maybe there’s hope for an OpenGL sequel. Otherwise OpenGL will be dead for the free software world, and if there will be (strong) interests in 3D people will bring Direct3D on linux.

  5. How is it then? I thought OpenGL 3.0 was supposed to make the API more object oriented, changing the architecture – is this change really dropped out of this release? Is this really so?

    What was the reason for the delay? How do we tell Khronos they need to release publicly information about delaying an API release?

  6. OpenGL is dead. DirectX is pushed as if there is no tomorrow and OpenGL sleeps. I dont know if Microsoft gives money so that Kronos sleeps, or if it is incompetence, but let’s face the truth – OpenGL has died already.

    It will only take more time for others to realize this sadness.

  7. Max, your assumptions are indeed right – with Gallium3D you could easily create a competing graphics API given that the hardware is supported by Gallium3D drivers.

    Bogdan, I tried to contact Khronos several times – there is simply no way of getting answers from them.

  8. OpenGL has been pretty much dead since around the time of D3D8. The API is fifteen years old, wasn’t great to begin with and just hasn’t kept pace with some of the advancements in graphics development. OpenGL 3.0 was promised to be a break with the past to really push things on, Khronos went into a padded cell for a year in complete silence………….and this is what was produced. The excuse has been keeping compatibility with the CAD world, but even many people in the CAD world are mystified as to how little things have moved on and there are better ways of taking care of backwards compatibility than keeping the same kludge and marking things for deprecation. God knows what people like Apple or others were actually doing in the ARB.

    I really am not surprised that AMD, Intel or nVidia are not terribly excited about supporting it, nor that they haven’t undertaken any work yet. Most vendors had their own extensions anyway and it keeps the free software graphics world fragmented until we get something sensible like Gallium3D to kickstart something. It’s a little bit like when Xfree86 stagnated and went doo-lally and we ended up with Xorg.

  9. Not sure about the “OpenGL is dead” part – well, at least not if you are developing for the mac, and/or the iphone.

    The industry needs a cross-platform 3d api. Clearly, no microsoft product will ever be cross-platform.

    Now if you are targeting Windows, well…I am sorry you are still using Windows. IMHO – In the long run it is Windows that is dead, and DirectX with it….

    I mean do you think the PS3 or the Wii, or any non-ms product will ever run DirectX… please.

    Help the world and at least do your best to try and embrace a cross-platform api…

  10. anon, you’re right that the world needs a cross platform API, but it clearly does not need OpenGL under the control of Khronos to be that API!

  11. It’s great that 3.0 is *finally* out, but yeah Khronos seems to be having *major* problems. Looking over the list of contributors on Khronos’s site there were a couple FLOSS friendly companies I saw (mostly Google and Tungsten Graphics… the latter is doing a lot of the work on Gallium3D).

    Before we can start calling OpenGL is dead it’d be great to actually get some word on what on earth is going on inside Khronos… it might be time for a fork, but it’d need the support of AMD, nVidia, or Intel to actually have a chance of becoming the standard IMO. Maybe it’d be possible for some companies with a stake in FOSS/Linux (think RedHat, Canical, Novell, Nokia, etc) could try to join Khronos in an attempt to try to push them to be more open (as in actually communicating occasionally), as well as increasing the speed of new releases.

    Something definitely has to be done, hopefully the Khronos group feels the same.

  12. Kit, believe me, I’ve tried that quite a lot, but no one ever answered my mails or questions.
    The only answer I got was from Zack Rusin, but he only had another mail address contact for me, and that one never answered.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.