DirectX 11 is to be presented at NVISION 08, click here for details.
Looking at the few mentioned features on the page (tessellation, multithreaded rendering, compute shaders, Shader Model 5), I’d say OpenGL is in big trouble if they want to catch up.
This weekend I took some time out to reformat my development computer in preparation for Windows Vista. I used Vista before but switched back to XP x64 in less than a week’s time. But heck, after a year and a Service Pack, I was willing to take the chance with Vista.
I wanted to take advantage of the DirectX 10 features Vista exposes since they’re not available on XP but was kind of disappointed with the performance of the API in Vista. It seems to me that the samples provided in the DirectX SDK simply run much slower than on XP.
Granted, I bought the most budget oriented GPU that supports DX10 (Geforce 8500GT 512VRAM) but that was simply because of the reason that I want my projects to be able to run on the lowest budget hardware possible while still being able to access DX10-like features. Dell, in fact, offers the 8400 on their laptops and budget desktop PCs, which is a fair share of the market and should be targeted.
Vista itself seems pretty solid so far; it certainly responds better than a year ago and supports all of my hardware and development tools (VS 2008, AQTime, Intel C++ compiler, etc). The big test will be OpenGL: Will it also have performance drops or stay the same? I’ll see tonight.
Some questions have come up in regards to my last post, The Ghost of OpenGL 3.0, and one of them keeps popping out on top: Why do we need OpenGL 3.0 and What’s wrong with OpenGL 2.1? This post will attempt to take you through the pre-published materials on the OpenGL API, version 3.0 and show you the major changes and differences. Or you could simple jump to the answer and conclusion without reading the features provided by OpenGL 3.0, if you don’t feel like getting informed.
Terms used:
Besides being a graphics API, OpenGL sets a standard for IHVs (Independent Hardware Vendors) to comply with. By doing this, we can be sure that a certain type of hardware is compliant with a specific set of demands, not unlike what Microsoft has been doing with DirectX 10 and higher, albeit not an open standard. For example, OpenGL 2.0 formally introduced the GLSL (OpenGL Shading Language) which was not available in 1.5, thus forcing IHVs to implement the capabilities according to the OpenGL standard.
A comparison with the Direct3D side of things would be the enforcement of Direct3D 10.1 compliance by setting a mandatory requirement of 4x anti-aliasing.
OpenGL 3.0 is said to be able to function on OpenGL 2.1/DirectX 9 level hardware, so basically anything from the GeForce FX series and upwards (supporting High Level shaders).
The OpenGL logoMost of the readers here are programmers, so the hardware side of the OpenGL standard will probably be less interesting to you than the features OpenGL 3.0 will bring. We all know that the OpenGL 3.0 specification has not yet been finalized, so all material discussed here is subject to change and compiled from various sources which I will list at the end of the post.
One of the major changes that OpenGL 3.0 will introduce is the usage of objects. Yes, the specification is still specified through the C programming language which natively does not support the OOP (Object Oriented Programming) paradigm but a way around this is being implemented.
The objects themselves are similar to native C structs which are used for creating user-defined data-types. Please note that I refrain from using the word class since a class is a data-type on its own, not found in the C programming language nor used in combination with the OpenGL API.
So far, four object categories have been announced, namely:
This new object-based system seems to be the biggest part of the restructuring of the standard and it certainly opens up a new realm of possibilities for IHVs/driver implementers. By abstracting the objects to the server-side, the underlying driver code can be optimized to handle the new data-types more efficiently. The more the API pushes to the server-side, the better the performance can potentially be optimized.
While this basically falls under the “Objects” heading, it’s a feature worth mentioning alone. In an effort to improve parallelism, Object creation calls are asynchronous. This means that during the time that an object is being created, a valid handle to the object has already been returned for usage, even before the object’s resources have actually been allocated.
What this means is that more commands can be executed on the client side while the server-side takes care of the execution thus resulting in a faster command chain.
The OpenGL API has always been backwards compatible throughout its revisions and OpenGL 3.0 will not be an exception. Plans have been made to retain backwards compatibility with the current OpenGL 2.1 standard without breaking older applications.
Another feature, which has not been set in stone, is the manner of interoperability between OpenGL 3.0 and 2.1 which would allow an OpenGL 2.1 application to attain an OpenGL 3.0 rendering context.
OpenGL 3.0 removes the fixed function pipeline which was eradicated in the Direct3D API in version 10. This means that many parts of a normal graphics pipeline are now programmable. This is a huge shift towards the future of a fully-programmable graphics pipeline which would be the definitive step in perfecting a graphics API.
The removal of the so-called “fixed function” pipeline means that all graphical output has to be defined through the “programmable pipeline” though a mechanism often called “Shaders.” Shaders are programmed in a language called the OpenGL Shading Language (GLSL or glslang) or through an intermediary language such as Cg. Shaders not only allow for shading the geometry but also the transformation of its vertices (vertex shader) and individual pixels (fragment shader).
If you’ve read the heading above this one, you’ll notice that OpenGL 3.0 is backwards compatible with older versions which support the fixed pipeline functionality. OpenGL also supports these functions but internally these are transformed into the form of shaders.
OpenGL version “Mount Evans”, which will be released after OpenGL 3.0, will support the functionality provided by Geometry Shaders which allows for the manipulation of “pieces” of geometry and generation of new geometry as well. This allows the programmer to take advantage of currently available hardware-accelerated functionality such as tessellation. Even though this functionality is said to be provided after 3.0 has been released, it is likely that this functionality will be provided with the formal release of OpenGL 3.0 instead.
By now you might have noticed that I haven’t exactly formally answered the question “What’s wrong with OpenGL 2.1?” The answer is: There’s nothing wrong with OpenGL 2.1.. informally. OpenGL 2.1 is a very capable API which could support many of the features that OpenGL 3.0 incorporated. The big difference is of course that the functionality in OpenGL 3.0 will be a formal standard while the 3.0-like functionality in OpenGL 2.1 is provided through IHV-developed OpenGL extensions which may differ from one and other.
The above, and the fact that the new API works with Objects, is causing the anticipation. OpenGL 3.0 will formally push the API into the next-generation era and will finally be able to compete with Direct3D 10, which is why OpenGL 3.0 is important.
As said above, OpenGL 3.0 will push the API into the next generation. In my personal opinion, the new structure of OpenGL 3.0 could severely compromise the position of Direct3D in the Microsoft Windows gaming market since the functionality provided with OpenGL 3.0 will also work on Windows XP, unlike Direct3D 10. Vista is still being viewed upon as somewhat of a quirky Operating System and many developers and users are sticking with XP for the time being.
I’d like to conclude by saying that this post does not present all of the new published features in OpenGL 3.0, rather it lists the features which I find most compelling about the new API. Also, I’m not affiliated with the Khronos Group in any way so everything you read here is non-official and compiled from various online sources, talking about the unfinished and proposed API. Last but not least, I don’t guarantee the correctness of the article, nor the correctness of the sources used — correct me if I’m wrong about something.
Taken from the original, now lost blog post comment section:
Korval says; 16 May 2008 - 13:01
Nobody really says that GL 3.0 isn’t important. But the fact is that it’s too late. There was a pretty good window of opportunity for a new and improved GL API to swoop in and garner attention among PC game developers. That time has passed. Vista adoption is up, which means that D3D10 usage will be up. The break between Vista/XP and D3D10/9 (ie: if you use XP, you can’t have D3D10 features) was a good opportunity that the ARB has squandered.
Furthermore, if the GL ARB couldn’t get this done last year, why should we believe them this year? The fact is that the ARB has failed, monstrously. They did it before back when they were working on render-to-texture. They spent 2 years on something that shouldn’t have taken more than 6. The younger GL programmers may not remember the days before VBO, but it took an awfully long time to get VBOs as well; until then, we had to rely on a bunch of vendor-specific extensions.
I love the ideas behind GL 3.0; I even wrote my GL 2.1-based rendering abstraction layer based on those ideas. But the fact is that it’s very, very late. And even that wouldn’t be so much of a problem if they could just tell us WHY it’s late. But they won’t. Which means it’s either IP or some stupid argument about something that matters very little. And if it’s the latter, then that means that the ARB is so worried about making a mistake that they won’t actually produce anything. Which makes them ineffective.
For 1 year, the ARB was good about updating us on their progress. And then they stopped. That shows a blatant lack of respect for us the potential users of OpenGL. So why should we respect them back?
–
Dave says; 19 May 2008 - 4:38
I think exactly the same to #Korval.
Every version of DirectX has the great disvantage of relying on a binary format for method calling and structs memory layout that is completely incompatible between major versions.
OpenGL has a smarter design in the sense of using raw C functions (instead of virtual C++ like methods) and almost no C structs.
But it is released with a functional equivalence to DX almost 2 years before. Otherways, using non-standar extensions is a nightmare.
Current OpenGL version has a lot of inconsistences, and a lot of legacy unusefull methods.
But the modern design of DX is not the only advantage over OGL, but a consistent DirectX SDK with a compact documentation and a pletoria of examples.
–
Aras Pranckevičius says; 19 May 2008 - 13:06
I don’t mind D3D changing the API with each major revision. API itself is nothing; it’s really easy to rewrite “the same stuff” to another API. Underlying hardware is still the same, so if the API is not Completely Stupid, it’s not a big deal.
What I do mind though, is whether API and everything related to it (drivers) work. OpenGL fails miserably in this regard, with it’s approach of “let’s let each IHV make their own bugs in the whole stack!” it’s just horrible. FBOs? GLSL? Argh!
Another thing that I don’t mind that much is all the legacy APIs/extensions. There’s probably ten ways to submit vertex data, while in fact there should be vertex buffers only. And even then, VBOs in GL don’t match up what was available in D3D for years (updating a portion of VBO without additional memory copy, anyone?).
So in my view GL3 does not bring anything new to the table. Ok, maybe it will be simpler for IHVs to implement, which would take care of some bugs in the drivers. But what they should really do is force a common stack upon everyone, and make only the lowest-level driver be a responsibility of IHV.
As you might know, NVIDIA has recently purchased Ageia, makers of the PhysX real-time physics SDK. Since then, NVIDIA has taken over the development of the SDK and a new version of the SDK is now available for free in binary form from the NVIDIA website, click here to go to check it out. A special license for the source code version of the SDK can be acquired for a mere $50K.
In other NVIDIA news: two new free book releases are now available on the NVIDIA website, namely: The Cg Tutorial and GPU Gems 2 which are two incredibly useful books. NVIDIA is on a roll, and looking at the manner in which freebies are coming in lately, I’ll be the last one to stop ‘em.
OpenGL 3.0 seems to become more and more of a promise that’s bound to be broken; like a friend who promises you to give back the money you loaned him, always tomorrow.
The expected API promises many new features, enhancements and is the first total rewrite of the existing OpenGL Standard. The API promises an interface compatible with the next generation of computer graphics programming and is set to compete with Microsoft’s DirectX 10.
Well, that’s the plan at least. OpenGL 3.0 has been delayed tremendously since its scheduled release in October of 2007. On October 30th of 2007, ARB member Barthold Lichtenbelt (NVIDIA employee) made an official announcement on the OpenGL.ORG forums claiming that the release date was postponed until further notice because “[the OpenGL Working group] don’t want to spend time fixing mistakes made in haste.”
The announcement settled fine with most of the OpenGL community since at least there was news. But after 7 months of neither news nor updates, some of the community is giving up on (or dismissing) the possibility of a new API at all.
But is it really possible to give up on OpenGL? The API is pretty much the only viable hardware accelerated option on platforms other than Microsoft Windows, and even on Windows many developers are reluctant to switch from XP to Windows Vista in order to take advantage of Direct3D 10.
The Khronos Group have been putting out updates on the other software which they maintain the standards of with the exception of their most popular/anticipated one, OpenGL.
So what does that mean? Either OpenGL is being actively developed on and public discussion is prohibited per NDA, or development has halted and there is reluctance in releasing the bad news. My hopes are up for the former option since the OpenGL API is without a doubt the most flexible Graphics API available today.
Of course, there is a third option which is quite scary and different. Khronos has been publishing information on a new API called OpenKODE which bundles several APIs in a DirectX-like manner of platform abstraction. Maybe the OpenGL API will become a part of this which would set back the development even more, but this is (as are the other options) a wild guess.
If there’s one thing to consider, it’s the fact that OpenGL is a standard (a definition), not an implementation. Which means that the actual source code for 3.0 would have to implemented by: A. the independent hardware vendors or B. the platform developers. So even if the OpenGL 3.0 API would be released today, the actual libraries wouldn’t be available yet since the implementation would be missing.
All in all, I think we’re still very far away from seeing a workable OpenGL 3.0 implementation that’s supported ‘cross-platform. For now we’ll just have to do with OpenGL 2.1 or Direct3D 10, which in many cases, is a limited set of options that’s impossible to choose from.