Now that the 3.2 specification is out, the API seems to be headed in the right direction but I fear that it’s just too little too late. Whereas OpenGL 3.2 seems to have targeted D3D 10 feverishly, Microsoft was already working on a new iteration of Direct3D in the background. Direct3D 11 once again leaves OpenGL to play catch-up, which they will, but likely too late.

OpenGL has one thing going for it that Direct3D doesn’t: cross-platform compatibility. If you really have to develop for multiple platforms, use OpenGL. If you just develop for Windows/360, use Direct3D. It almost seems as if we’re at that great “games versus industrial application” API divide again. Any momentum that OpenGL might have gained with 2.1, it has lost with its release of 3.0.

Here’s a great article by Tom’s Hardware explaining the issues better than I ever could.

Oh and a happy new year, by the way…

Click here to read the PDF, scroll down to page eight (8)

Larrabee will support a rasterization pipeline as well as raytracing but Forsyth mentions raytracing to be more of a technical feature than a mainstream implementation. Regardless of this, for graphics programmers this should be good as there will finally be a piece of hardware that actually supports realtime raytracing.

Direct3D as well as OpenGL will be supported in addition to the much anticipated programmable route, either through C++ or pure assembly, which should open up the card for people interested in parallel computing.

Sadly there’s no definitive answer from Forsyth on how many cores Larrabee will actually contain. I guess we’ll have to wait for that a bit longer.

PS, if anyone is at GDC listening to Abrash and Forsyth tomorrow, let me know what you got from it.

I have been extremely skeptical about OpenGL 3.0 since it was more like an OpenGL 2.2 and did not implement any of the promised object oriented features that competing APIs like Direct3D implement. Thankfully, this release of OpenGL 3.1 seems to be better at first glance as it not only deprecates but removes the old functionality which has been in the way for so long.

It looks like Khronos has heard and listened to its outraged end-users and finally created a better specification. At least, upon first glance, that’s what it looks like.

With the release of OpenGL 3.1 also comes a new version of GLSL, version 1.40. Most excitingly, NVIDIA has released OpenGL 3.1 drivers immediately after the release of GL, showing that they’re way ahead in the game already (as opposed to AMD or Intel).

It is amazing to me that no major outlets such as Slashdot have picked up this this story and one has to find out about 3.1 by accident or RSS feeds.

• The ability to install a piece of software without having to invoke a CLI.
• A full-featured development environment (that’s not Eclipse) that rivals Visual Studio in C++ development.
• A non-Unix-like file system.
• Better manual when you buy a distribution (SUSE manual: case and point).
• Better IHV driver support.
• Better native ISV software support without having to run Wine.
• And the coup de grâce: An OpenGL specification that can compete with Direct3D.

Don’t get me wrong, I have nothing against Linux itself, in fact much of my development time goes into LAMP related work. But for the desktop it just seems like a CLI-ridden nightmare at the moment.

Once upon a time there was a little old API, struggling for its life amongst the giants of software. Little old OpenGL knew that in order to survive it had to adapt to a strange, bewildering and new environment; it was a strange new world indeed. For two years, rumors of old OpenGL’s struggles reached the user-groups and there was much rejoicing indeed. But on one faithful day, August the 11^th of 2008, OpenGL perished. Its age and idleness had (as with all things good and bad) caught up with him and slayed little old OpenGL in its path.

After reading the spec and looking desperately for the promised object model, I felt quite like a (self-censored) taking the newsletters seriously and writing about them so explicitly.

For those who haven’t read the specification yet, it’s OpenGL 2.1 plus and minus some stuff, hardly the fruition of two years labor. The anticipation that followed the initial announcement of OpenGL 3.0’s Object Model was tremendous. For the first time in a long time, people started noticing OpenGL again and maybe a place for it in modern multimedia applications such as PC games besides id Software’s titles.

Alas, it was not to be. Woe is me for my old API is truly dead. D3D, hello.

The OpenGL ® Graphics System: A Specification (Version 3.0 – August 11, 2008)
Link to the registry containing the link

Let me know what you think of it, thanks nosmileface!

CHW member KaiserGerhardI has provided a deciphering of the screenshot which provides more information on the contents of the screenshot:

• First: Quad ?????? Release February
• Hybrid Shipped Spring
• Spring Notebook Cycle
• GT200 + ????
• Big Bang II-Fall Will Focus on
  • Now/WWW features
  • SLI connectivity features
  • Display connectivity
  • Quality improvements
  • Performance improvements
  • OpenGL 3.0

The words which could not be deciphered are marked with question marks. What this means for OpenGL enthusiasts and developers is that we won’t have to attend SIGGRAPH, NVISION or any other meeting for that matter, since this is basically a confirmation on its own.

Now, let’s hope that ATI will also provide an implementation this soon.

1. Hardware Evolution
2. The Software Side
   1. Objects
   2. Asynchronous Transactions
   3. Backwards Compatibility
   4. Goodbye, Fixed Function Pipeline
3. So, what’s wrong with 2.1?
4. Conclusion

Terms used:
Mutable: something which can change shape or form.
Immutable: something which cannot change shape or form.
API: Application Programming Interface, an interface designed to allow transactions with a library or application.

Hardware Evolution

Image by: Rooka

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 Software Side

Most 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.

Objects

Image by: stilleben2001

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:

• Templates
  • Put in simple terms: a placeholder for the definition of a specific object type. Attributes can be set to fulfill the creation of a specific object type. For example, to create an “image” object, one must first create a template object with specific parameters for the creation of the image object, set the attributes required for the object and pass it to an image object constructor function, e.g.: glCreateTemplate(GL_IMAGE_OBJECT); returns a GLtemplate object, after which attributes are applied, glCreateImage(variable to GLtemplate object); returns the handle to an image object (see Data Objects below) constructed according to the attributes supplied to the image template. Templates may be modified at any time since they are defined and stored on the client-side.
• State Objects
  • State Objects are simple objects containing a specific set of attributes applicable to multiple objects. State Objects are partially mutable once created, meaning that only certain aspects of the object can be altered after it has been constructed.
• Data Objects
  • The example given above at Templates talked about an “image object” which contains image data, stored in a Data Object. These objects have an immutable structure but the data is mutable. These Data Objects get stored VRAM (or RAM depending on the implementation) and can be shared amongst multiple contexts. Examples of Data Objects are Image Objects and Buffer Objects.
• Container Objects
  • The best way to describe a Container Object is by the example of the VAO (Vertex Array Object). The VAO represents a piece of geometry by describing an array of vertices stored in memory and may not be referenced amongst multiple contexts. The Container Object contains a mutable attachment (VAO: Vertex Buffer) and immutable attachment properties.

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.

Asynchronous Transactions

Image by: James Cridland

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.

Backwards Compatibility

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.

Goodbye, Fixed Function Pipeline

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.

So, what’s wrong with 2.1?

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.

Conclusion

The OpenGL API Logo

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.

Sources Used

• OpenGL Pipeline Newsletters
• OpenGL.ORG Discussion Boards
• Wikipedia article on OpenGL

SIGGRAPH 2008 runs from August 11^th till August 15^th 2008 in Los Angeles, California; let’s keep our fingers crossed for some good news from the Khronos camp.

Well, that’s the plan at least. OpenGL 3.0 has been delayed tremendously since its scheduled release in October of 2007. On October 30^th 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.