OpenGL 3.0 - A Big Step in the Right Direction

Posted by Nick Haemel on August 18, 2008
OpenGL 3

There has been much controversy over the direction the Khronos Group/OpenGL ARB has chosen for the next major version of OpenGL. After testing an approach that would have a drastic effect on the API, requiring complete OpenGL application rewrites and not introducing any of the long awaited features modern GPUs are capable of, the choice was made to give programmers what they are really waiting for. And that’s new features now. GL 3.0 takes two important steps to moving open standard graphics forward in a major way. The first is to provide core and ARB extension access to the new and exciting capabilities of hardware. The second is to create a roadmap that allows developers to see what parts of core specifications will be going away in the future, also providing the OpenGL ARB with a way to introduce new features faster.

Over the last few years graphics hardware has made great strides forward. Different vendors have exposed home-grown extensions to give users access to hardware, but vendor extensions vary between vendors and are not a stable approach to supporting new hardware.  GL3.0 brings these new features under one roof, defining one common and accepted way that all vendors will implement. Now all GL application programmers can get access to things like float color/texture/depth buffers, integer formats, conditional rendering,  framebuffer objects, transform feedback, vertex array objects, half-float data types (vertex/pixel), and so much more. With these new features all developers have the tools to add new eye candy and much better optimize render algorithms and performance.

Many of the new features of OpenGL3.0 provide mechanisms to increase the efficiency and speed of today’s complex scenes. Conditional rendering allows an app to discard geometry that would be occluded during normal rendering. Half float formats can help drastically compress vertex data sets. Vertex array objects make setting up rendering much easier and less error prone. Map buffer range support allows a small portion of a buffer to be mapped, even while it is rendered from, no more GPU stalls required. There are also quite few additions to enhance rendering flexibility. Framebuffer objects provide a fast and simple way to accomplish off-screen rendering.  Transform feedback opens the door to a whole new set of complex multi-pass rendering and geometry generation algorithms previously impossible. Integer-in-shader support allows for much more flexible and natural shader code. Several other important features such as instanced rendering and geometry shaders have now been given ARB extension status as well.

By introducing the new deprecation model, the ARB has created a way to signal what will be removed in future revisions. This provides enough time for all developers to move code-bases to newer and better methods. Future versions of GL will remove fixed-function rendering, color index mode, immediate mode, client vertex arrays, and other seldom used portions of older specs. This helps to keep the spec lean and mean, also allowing hardware vendors to better optimize performance and maintain quality. A way for OpenGL to gracefully move forward has been long missing.  With the most recent changes, OpenGL now has the tools to keep open standard graphics current and useful for many different flavors of 3D applications.

Tags: 3D, Developers, OpenGL
(23) Comments | Permalink | Trackback URI | Bookmark & Share

Comments

I saw this post on the Register and being in CAD, it seemed to be pretty relevant: "The CAD developers first and foremost want a stable platform that just works, and will continue to be working in 5 years time - the life of a CAD project can be much longer than that, so the original software used *must* still work (often unpatched) even on new hardware with new drivers. Speed is important, but not the main objective - CAD developers spend most of their time developing the user interface and making the CAD functionality better / correct. They want a graphics API that is extensible but rarely loses core functionality."

By SWdesignman on 2008-08-18

"After testing an approach that would have a drastic effect on the API, requiring complete OpenGL application rewrites and not introducing any of the long awaited features modern GPUs are capable of, the choice was made to give programmers what they are really waiting for" So.... why are so many developers so furious then? These developers were *not* looking forward to new features, but to a cleaner, saner API for working with current mainstream GPU's where they can be relatively sure of finding the fast (hardware-accelerated) path. Developers wanted something that was competetive with DirectX for DX9-class functionality. Once they got that, they'd be happy to see new features, of course. But adding features to an API that no one who has a choice actually uses is just not going to impress. OpenGL has been falling behind for a decade or so. What we wanted to see was something that would *change* this. Not just "an incremental update to the last incremental update to the last incremental update", because that strategy has had a decade to prove just how well it works. (it doesn't) The problem with GL3.0 is that it fails in all these areas. It does *not* catch up with all the "new" features that have become possible on GPU's. You still need to mess with extensions to use geometry shaders, for example. It does *not* clean up the API. It does *not* work with current mainstream GPU's (because it needs juuuust a few features only available on DX10 GPU's). And it does nothing to help you stay on the fast path. It was almost a year delayed, and despite all the promises, and completely contrary to the claimed goals of 3.0 (give developers a warning before removing stuff), *not a word* was spoken to developers for half a year after the change in direction for 3.0 was decided. Khronos could have posted a simple newsletter back in January saying "Instead of making the GL3.0 you've all stated that you love to death and are looking forward to, we're going to provide an extremely minor update which merely integrates a few extensions into the core. You won't get a new API, so don't wait for GL3.0". Instead, it was decided to keep developers in the dark for half a year. But suddenly, it's all "Yeah, we couldn't change OGL too much now, because you know, developers would have no time to adjust". As for the deprecation mechanism, I would find it a lot more relevant if we were given some kind of timetable of when features are removed. When was the last time you saw a deprecated function in an API get removed? Microsoft has never removed a single deprecated function from their API's. Neither has Java, or virtually anyone else. The only company I can think of that has actually removed deprecated functionality is Apple. Which means that a "deprecated" label just seems like a slap in the face. A "we didn't have the guts to remove this, and we won't have the guts to remove it next year, or the year after, so to avoid losing face, we'll just put this "deprecated" sticker on it instead". Unless of course, there are actual concrete plans for removing these deprecated functions. In which case Khronos might want to consider *telling* people. I don't know, I just find it hilarious that Khronos decided half a year ago to give up on the project they'd been getting extremely positive feedback from developers on, in order to "give developers what they really wanted"... without actually asking developers what they really wanted. Because of the developers I know, the old GL3.0 was much more of what we really wanted than this current GL2.2 (or should it be 1.8?) Well, what I really want is what you said Khronos was giving us, a roadmap. I don't see a roadmap. I see vague armwaving, saying "one day, at some unspecified point in the future, this function may no longer be available". There are two things missing here: First, *when* is it going to go away. Second, what are we getting instead? Are we going to see anything like the "original" 3.0 proposal's object model? Are we going to see any structural changes to the API? Or are we just getting more of the same old messy API? A roadmap that says nothing about the future isn't much of a roadmap. Is there a plan for the future? And does it involve a change from the failed strategy of the last decade?

By grumpy on 2008-08-18

WELL SAID!!!

By Clarks on 2008-08-18

I'm not entirely unhappy with OpenGL 1.7, but it a disappointment. Calling it "what [programmers] are really waiting for" seems dishonest. Much of the hostility could have been avoided by simply being upfront and informative. Indeed, it could still be calmed by providing the information Grumpy is asking for.

By anonymous on 2008-08-19

You fail tom mention with any word the the entire process itself is broken entirely, mabye even beyond repair: an uncommented delay over almost a year is not acceptable. Users and developers,vendors and others cannot (!) trust Khronos anymore to deliver anything reliable - because they showed that they are not able to communicate anything regarding the standard. So while I see that you think the technical side of the development is not that bad at all, I don't get how you can still be confident that there will be a next step in the development of OpenGL. How can you be sure that Khronos doesn't screw it up, or simply just drops the OpenGL spec?

By liquidat on 2008-08-19

grumpy: "all" the developers are furious because you're just reading tabloid magazines of the web age, where all the whiners can be found. There is probably also some amount of deliberate FUDding from the competitor(s). The failure was in fluent communication, not in the delivery. The spec document is not as beautiful as it could be, but really tutorials are the ones for making stuff easily understandable, not specs. If you look at the spec rewritten for human beings, ie. all the appendix E stuff really removed, it's a huge good step in the correct direction IMHO.

By notgrumpy on 2008-08-19

Most of the extensions in GL 3.0 have been implemented in NVIDIA G80 series GPU, so I do not feel it's a greater improvement compared with the old. Have a look at DX10/10.1/11, OpenGL does not unleash the capacity of GPU at all, so I do not like GL 3.0 a little.

By Bo Schwarzstein on 2008-08-20

notgrumpy: You may hide the state of affairs from youself by saying "Oh, it's not ALL developers. And besides, it's all about jalousy". I'm not an expert but I have heard loud complaints 'from the development community'. Yep, you can shoot me down on 'tell me what that is". But the complaint from grumpy seems a fundamental one: how do I make sure that all the activated features are hardware accelerated? As I said, I'm not an expert, but it seems that if the API is styled in the fashion of "Just tell me what you want an I give it to you!", you're in big trouble. You activate shader XYZ, only to find out that performance tumbles. In the specs you can find then: "Well, if this feature is not supported by your hardware it will be simulated in Software". I can imagine a developer saying "So, why didn't you SAY so, you #@$**@@!" And this requires a different philosophy behind the API.

By Steven on 2008-08-20

@notgrumpy "tabloid magazines of the web age"? Oh, you must mean that pesky Opengl.org and Gamedev.net forums where, upon release of the spec, the giant cry of 'what the hell? not again...' went up from estabilished community members and OpenGL users as the ARB failed to deliver on it's promises. THIS is where the other webpages have picked up the outrage from. I've been using OpenGL myself for around 8 years (bobvodka on the ogl forums, phantom on the gamedev.net forums) and this latest failure has pushed myself, and others, over the edge and into D3D land.

By Rob Jones on 2008-08-21

I've a question... when available, if I install a compliant OpenGL 3 driver on a computer, will OpenGL 2 app's still running?? DirectX allow to run oldies... those apps using older DirectX libs than installed in a computer. If run a OpenGL 2.x or 1.x app on a system with OpenGL 3 installed, this removes major problems in 3.x. I don't see this clear... I believe this is the biggest problem The other problems are less important: - for use CUDA or Larrabee we may use OpenCL. - OpenGL is not an Object Oriented lib, maybe Kronos should standarize a OO lib for those who demand it. Although I say this, I don't think OpenGL 3 is the right step: OpenGL 2.x with a good set of ARB extensions is simpler and provides the same: OpenGL was designed to provide extensibility thru extensions, core should be minimal.

By Santi on 2008-08-22

The frustration is understandable - as well, many team members were frustrated that Longs Peak had not reached a shippable state after the time invested. There are a couple of axes to look at: (x) do you avoid forward-looking statements to the public in mid-project? (y) do you enforce a controlled timeframe for deliverables (publishable spec)? During Longs Peak, the "x" and "y" were both effectively set to "no". Which yielded the worst of both worlds, the project direction diverged from the roadmap, yielding frustration. This was magnified by the duration - the y axis - if it had only been a 3-4 month excursion then the frustration level would likely be lower. Since January 2008, x and y have both been set back to "yes" - it was a period of silent running but the self-imposed deadline of specification hand-off for final review in early July was reached. We're now in the second such window, and it's not likely that detailed roadmaps of precisely what will make it into OpenGL 3.1 will be published during the window, but our goal is to keep the window short. This doesn't mean blocking off communication with the public as we're happy to discuss specific ideas or ISV needs, but it would be off-policy for Khronos members to post details or roadmaps relating exactly what will be in OpenGL 3.1 until it has reached a final or very-near-final state in the specification process.

By Khronos Member on 2008-08-24

Khronos member: sorry, but that is utterly bullshit. This discussion is not about disappointed time frames or delayed time tables. The problem is that there was a total stop of communication on all levels regarding all topics. If you just stop to publish forward looking statements you release information like "working on it, reached mile stone one containing feature xy" once in a while. However, you (the Khronos Group) stoppped every communication - you created the image the Khronos group is not working on it any more. It was impossible to reach members of the group. Heck, even the press contact of the Khornos Group didn't answer any e-mail, let alone giving a statement. You try to present the situation as you were not giving out too much information. But in reality you gave everyone the idea that there is nothing done at all, that the project is dead or at least not really important.

By liquidat on 2008-08-24

@Liquidat, sorry you feel that way, but it's the honest truth. The problem with announcing details before they are well and truly finalized is that they can create false expectations, and this is very clearly what happened with Longs Peak. As I said though this isn't to imply that there can't be discussions about ideas for future revisions or extensions through any number of channels (OpenGL.org forum is a good one). That's a very different thing from putting up roadmaps committing to specific changes or timelines.

By Khronos Member on 2008-08-24

Khronos Member, thx for your quick response. I think we are talking at cross-purposes: my main concern isn't about the expectations regarding the release (feature wise or in any other way). It is also not about discussions about other features or API details. My main concern is that there was no information at all - nothing. Not even a "we are working but it takes longer" statement. The entire communication was shut down - totally. As I said, I asked at the forums, I tried to reach the official press contact (!) and I also got an e-mail address of a board member whom I tried to contact. But there never was an response. And that is the part I cannot understand: why didn't Khronos simply "hang out a sign" saying: "We are working at it, it takes longer, details later - but we are not dead." Or pointed out in a different way: between the least official statement (fall last year) and the 3.0 release: how could anyone determine if Khronos was indeed working on the spec or quietly dropped OpenGL?

By liquidat on 2008-08-25

Would those posting generic gripes against Khronos / OGL3 please put in the projects or company you work for rather than the chicken-shit safely anonymous generic assaults? I don't hear ANY crucial common demoninator save a propensity for passive-agresssion through whining. I'd really like to see the vaaaast authority from whence your gigantic self-important guru ego's spring.

By ogl enthusiast on 2008-08-27

ogl enthusiast, you are aware of the ironie that you call for the real identities while you are indeed posting anonymous? Also, well pointed criticism does not need any project names - the authority is given by the argument, not by an authority. As for me, my name does not need any further explanation: I speak for myself but I am active in several Open Source projects.

By liquidat on 2008-08-27

To ogl Enthusiast / liquidat and the distinguished Kronos group member Should this post be authorized : I have got to back up liquidat. I work with OpenGL ever since 1999, and went through all of its versions and subversions. It seems that Khronos has totally forgot the "Free as in Freedom" concept. I see that Khronos member is referring to the forum. The OpenGL3.0 topic , which was supposed to be the hottest living one , was all full of questions of "What happened to OpenGL3.0 spec ?" or "when can we expect anything ?" or even apologies like "No posts about the advancements of Opengl3.0 because ...". The whole way of process of defining the spec was something vague and did not remind me of the former ARB I knew which posted Requests for comments, suggestions and other Specs on the forum to allow developers to feel the pulse of the whole project. I have been to Siggraph2008 and expected some ingenious Idea like inversing the API : inventing a new API (As you promised in the beginning in the forums) to be more generic and less of a fixed approach and to declare all fixed function s as extensions of OpenGL3.0, thus allowing quick wranglers to quickly adapt to the situation , changing almost nothing for vendors , yet introducing new concepts to the world which will show that indeed much effort was put here and will SHARE the process with the users. The whole power of open standards is from no other than the community which uses it, Keep that in mind, oh distinguished Khronos member, embrace your community as you walk towards 3.1 : share your ideas and thoughts and even your problems. Trust me , real good and fine people are looking up to serving you as OpenGL is a great hope for all of us who believe in the power of free software,openness and community. Don't let OpenGL get to the point where GLide3.0 [if you regretfully recall] is today, Which is practically nowhere. On the contrary : Think of productive ways to have OpenGL offer MORE and be more attractive and associative than Direct3D. In person I believe in the power of communities, and so should Khronos ! Let OpenGL3.1 be the proof of that !

By phoenix_wrath on 2008-09-03

API developers are not game developers! Game developers need to be hush hush to avoid creating hype. API developers of an open standard need to be communicating with the community so that the community can hit the ground running with the updated API when it is released! Am I wrong?

By alipschitz on 2008-09-05

No, alipschitz, You are not wrong. At least not totally.... As much as I dislike the way Microsoft behaves in general, I liked what they did when they approached DX10. They first sought their target audience. As it happened to be , Microsoft understood that games over the market are their main goal , and set direction there. What they did as of that moment, is that their labs sought the right API WITH THEIR DESTINATION audience , they went to Intel , NVidia, ATI , and game companies and together they conceived a very nice API , who will, as I believe, undergo only minor changed to adapt itself to DX11 and later to DX12. they understood that the graphic accelerators have undergone a heavy change and thus a major API change is due. Should you ask me , they succeeded very much (Trust me on that one , that's what I do for a living...) . Khronos , on the other hand , (and again , I am speculating because as a member of this community I also feel I have been left out) sought to keep their audience without [as you say] making a big fuss. Well, it seems like they managed to do so , their audience shall be safely kept. and thus , we shall continue working with an API like DX10's which is new , innovative, and rocks, and OpenGL3.0 will be , once again , the proprietary of those who write CAD programs and professional flight simulators , like former MPI (Presagis today) and companies who relay on SGI to do their work, because , believe it or not , SGI (At least these days) is heaving a little trouble finding support for new revisions of OpenGL. So , once again a whole share of new , innovative, flexible audience is left aside. Instead of giving a new, flying colors, innovative API [I seem to get the impression many have expected] and lure new users inside, make everything faster and appealing. For now , you are correct, Gamers have been hushed, which is , in my opinion , a pity as they are the real ones who tweak and peak the API's. Think about that

By phoenix_wrath on 2008-09-06

Well, something else to think about, there are two ISV's actually on the OpenGL working group and both of them are game developers. The Longs Peak fans may have lost track of the fact that its feature set didn't even reach a complete DX9 level. The game developers in the working group for OpenGL have made it extremely clear that getting closer to current hardware capability (which means DX10 class hardware, as that is what is now available) should be the #1 priority, and this is the direction that has been taken for 3.0 - prioritizing integration of contemporary hardware capability above any sweeping API changes. The vendors alluded to above had very little to do with it. LP was simply long on schedule and short on features, so it was set aside. If you have a specific rendering or hardware feature that you feel would prevent you from writing OpenGL 3.0 code, you should write it up in the OpenGL.org forum, since the 3.1 definition effort is already underway. Long term, if OpenGL evolves to track hardware capabilities on a regular basis, legacy features are deprecated out in an orderly fashion, and the API undergoes some streamlining to eliminate old warts, what's the problem ?

By Khronos Member on 2008-09-06

Page 1 of 2 pages
 1 2 >

Add your comment

Note: All comments are moderated for spambots so there will be a posting delay.
Your email address will not be published.

Anti Spam: Please enter the word you see in the image below:


Close