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…

They’ve posted a shipload of information over the last couple of months, so if you’re like me and had no idea this existed, you’ll have quite some reading to catch up to. It’s mostly about Windows 7 and the new graphics APIs (Direct2D, DirectWrite, etc.) but it’s interesting nonetheless.

Yeah, I don’t have the DX11 logo yet…

This release contains the first official release of Direct3D 11 (RTM), which was previously only a technical preview. According to the release notes, this version of Direct3D 11 will only work on the RTM version of Windows 7, not on the RC and Beta versions. So I guess only vendors and MSDN subscribers will be able to develop software until Windows 7 hits the retail market.

There’s also the issue of pure Direct3D 11 hardware not being sold yet but that should be right around the corner if the SDK is here.

Once per week or so I browse a local Barnes and Noble hoping to catch a book I haven’t seen before. It rarely happens since their inventory is very stagnant, but still. A month or two ago I accidentally browsed the Graphics/Web section and found “Introduction to 3D Game Programming with DirectX 10″ by Frank D. Luna.

The title, publisher (Wordware) and cover were kind of off-putting so I almost didn’t buy it. But I’m glad I did since, in my case, it has become my number one DX10 reference. It’s compact, concise, always around my desk and well written so give it a shot if you have 30 bucks or so to spare.

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.

Also, there seems to be some interesting stuff bundled with this version of the SDK, here’s my take on the important stuff:

• Technical Previews
  • Direct2D
  • DirectWrite
  • DXGI 1.1
• PIX works on the Windows 7 beta
• Several updated samples

Check out the details at the link posted above. Also, it doesn’t look like the online MSDN library docs have been updated yet but usually that happens pretty quickly.

My guess would be that with the release date of Windows 7 inching closer, the development for DirectX 11 has to be completed soon. Of course this is 100% speculation.

If anyone has a clue, let me know.

It doesn’t look like there are any DirectX 11 previews in there. Is it my imagination or were those supposed to be in it? Thanks Aras for the confirmation that the DirectX 11 preview are actually in there.

EDIT2: The new DirectX redistributable was released today.

Major Direct3D 11 Features:

1. Compatibility: Ability to run on previous generation hardware (9, 10, 10.1)
2. Multithreading: Resources may be created asynchronously on separate threads.
3. Tesselation: Allows for subdivision surface operations (Fixed Function, not programmable)
4. Compute Shaders: Allows for general programming on the CPU, much like NVIDIA’s CUDA.
5. No Overhaul: Direct3D 11 is a superset of Direct3D 10, no learning curve as with 9 → 10.

A DX11 preview should appear in your November 2008 DirectX SDK. Keep your eyes on this page for GDC 2008 DirectX 11 papers.

Notes
1. Although you may use the Direct3D 11 SDK on older hardware features will naturally be limited to the hardware itself.

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.

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.

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

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.