The Khronos Group has released two new versions of its 3D graphics APIs. The mobile-oriented OpenGL ES specification has been given a major upgrade to version 3.0, and the desktop OpenGL specification has received a minor update to bring it to version 4.3.

After some years of stagnation and an abandoned attempt to radically change the way OpenGL worked—during which time Microsoft's Direct3D API progressed in leaps and bounds—the Khronos Group has been developing new iterations of the OpenGL standard at a regular clip. While Direct3D has still been first to standardize certain new features, the OpenGL designers are quickly picking them up and integrating them.

OpenGL ES has risen to prominence primarily on the back of the iPhone and Android. Both iOS and Android use OpenGL ES as their 3D API, and the enormous growth in smartphone gaming has made OpenGL ES a critical API for many developers.

OpenGL ES 2.0 was first introduced in 2007, with hardware hitting the market in 2009-10. It was roughly based on the then-current OpenGL 2.x, stripping out OpenGL features that were needed only for backwards compatibility, and using a simpler set of data types and texture formats.

The new OpenGL ES 3.0 adds various features from OpenGL 3.x and 4.x. Shaders, the small pieces of code used to program GPUs, have been made more capable, with full support for 32-bit integer and floating point data. OpenGL ES 3.0 GPUs will support more complex textures—for example, textures with arbitrary sizes (instead of requiring the dimensions of each edge to be a power of two), and textures with floating point values.

The Khronos Group has added new compressed texture formats to OpenGL ES 3.0. Using algorithms devised by Ericsson, and available royalty free for anyone to implement, ETC2 and EAC provide a standard way to compress textures for OpenGL ES developers.

This fills an important gap in OpenGL ES. Texture compression is particularly important on mobile devices, as it reduces the amount of memory and bandwidth required to store textures. Direct3D hardware tends to use a compression algorithm called S3TC, but this is proprietary, and to use S3TC you must pay royalties to HTC.

OpenGL forbids the use of non-free algorithms, so it cannot use S3TC. Instead, each GPU vendor has tended to implement its own proprietary compression algorithms. This makes things difficult for developers, as they cannot rely on any particular set of features and have to distribute multiple versions of their textures, one for each algorithm.

The Khronos Group is working on a new compression algorithm, ASTC, that isn't a mandatory part of OpenGL ES 3.0, but might become compulsory in the future.

OpenGL ES 3.0 also has some new drawing capabilities, such as the ability to perform instanced rendering: one object (made up of a set of lines or triangles) can be drawn multiple times with a single command.

Even with the new features, OpenGL ES 3.0 is still somewhat behind Direct3D 10 and OpenGL 3.2 (and newer) in capabilities. In particular, OpenGL ES 3.0 doesn't include support for geometry shaders. These shaders can generate new lines and triangles, and can be used for tasks such as tessellation: taking an existing shape, and adding new lines to it to smooth out curves and make it look better.

Mobile hardware supporting OpenGL ES 3.0 should become available in 2013.

OpenGL 4.3 is a much smaller update. Many of the changes are to bring parity with OpenGL ES 3.0 to ensure that it remains a true superset of OpenGL ES.

The big new feature in GL 4.3 is support for compute shaders. Compute shaders allow graphics-oriented software to integrate GPU-based computation into their rendering engines. In the early days of GPU-based computation, developers had to pretend that their data was either pixel data, processed using pixel shaders, or line and triangle data, processed using vertex shaders and geometry shaders. These shaders were executed in a very particular order; essentially, data goes from the vertex shaders into the geometry shaders, and then (after the GPU does some processing) into the pixel shaders.

While this works, it is awkward for developers. They have to wrangle their programs to make them look as if they were operating on graphics data, and the involvement with the graphics pipeline means that it's awkward to use the GPU simultaneously to work on graphics and perform general purpose computation.

Compute shaders address this very issue. Compute shaders operate on general buffers of data, and operate separately from the graphics pipeline—while they can inject data into the graphics pipeline, they don't have to. This makes it much easier to use the GPU both for non-graphical tasks, such as physics or AI processing, and for advanced graphical processing such as raytracing.

In addition to these two new API versions, the Khronos Group has started development of a software library to make development of programs using its OpenCL computation API easier. Similar libraries already exist for OpenGL and Direct3D (called GLUT and DXUT, respectively). The OpenCL library will be called CLU.

OpenGL is 20 years old this year. Silicon Graphics published OpenGL 1.0 in January 1992. The Silicon Graphics RealityEngine, released in 1992, was spread across three to six circuit boards. The Geometry Engine board housed eight Intel i860XP CPUs at 50MHz each. Rasterization and texture storage were performed by one, two, or four Raster Memory boards, and display output was handled by a Display Generator board.

This powerhouse could process 1 million triangles per second and render 240 million pixels per second. Its total number-crunching power was about 0.64 billion floating operations per second.

Twenty years later, an NVIDIA GeForce GTX 680 can handle 1,800 million triangles per second, 14,400 million pixels per second, and has processing power totaling 3,090 billion floating point operations per second—between 60 and 4,830 times faster than the pioneering RealityEngine.

This powerhouse could process 1 million triangles per second and render 240 million pixels per second. Its total number crunching power was about 0.64 billion floating operations per second.

Twenty years later, an NVIDIA GeForce GTX 680 can handle 1,800 million triangles per second, 14,400 pixels per second, and has processing power totaling 3,090 billion floating point operations per second—between 60 and 4,830 times faster than the pioneering RealityEngine.

Is it 240 000 000 vs 14 000 or is the unit missing behind the second figure?

Even with the new features, OpenGL ES 3.0 is still somewhat behind Direct3D 10 and OpenGL 3.2 (and newer) in capabilities.

So the mobile standard is behind the desktop standard? Oh noes!

Article wrote:

While Direct3D has still been first to standardize certain new features, the OpenGL designers are quickly picking them up and integrating them.

That's mostly because hardware designers design for Direct3D first, then OpenGL. It's better than it was, but with games pushing the tech, and DirectX powering most of those games, it makes sense. It's hardly Kronos' fault that Direct3D gets first swing at the features though.

The Adreno 320 GPU in the Snapdragon S4 Pro supports OpenGL ES 3.0 (previously code named Haiti) and should be out at the very end of the year. Other compatible mobile GPUs include the ARM Mali T658 (unsure about the T604 in the Exynos 5250/5450) as well as the PowerVR 6 series.

Hopefully DirectX 11 capability in Windows 8 and Windows Phone 8 means more developers will be making apps with these newer APIs and port comparable features to OpenGL ES 3.0 so we can escape the 2.0 pit we are in today (and will likely be in for another year or two).

While Direct3D has still been first to standardize certain new features[...]

Which new features? I think it's funny, since D3D's most touted trick is tessellation which it got more than 3 years after opengl. Opengl hasn't been stagnant at all, it's just had a fairly massive media blackout since the unreal 3 era.

Those compute shaders are interesting though... I wonder if they could replace opencl?

Those compute shaders are interesting though... I wonder if they could replace opencl?

I think the idea is to complement openCL. So you can do parallel computing using OpenGL, just with less flexibility, but more ease-of-use than OpenCL. Since I assume it uses many of the same objects (buffers, etc.), it should allow for more efficient code if you're doing graphics and computation. Think about stuff like simulation games, so you can parallel process chunks of simulation objects in between draws using the same bits of memory.

I look forward to getting to use OpenGL ES 3.0, 2.0 has been great and I'm amazed at just how much power you can squeeze out of mobile GPUs. 32-bit float textures? Oh my, yes please! I just hope texture lookups in vertex shaders become much better supported than they are in 2.0. Bummer about geometry shaders being left out though.

Texture compression is particularly important on mobile devices, as it reduces the amount of memory and bandwidth required to store textures. Direct3D hardware tends to use a compression algorithm called S3TC, but this is proprietary, and to use S3TC you must pay royalties to HTC.

This means that any participant in the OIN Community of Licensees does not have to pay royalties to HTC for S3TC for use in any Linux System.

S3TC patents are not in the list of Currently Owned Patents. Note that Linux System is defined by OIN very narrowly -- list of packages of some precise version (for example, mesa 7.11), so S3TC probably is not a part of "Linux System". Anyway it could be helpful only for OIN licensees.

I think it's funny, since D3D's most touted trick is tessellation which it got more than 3 years after opengl. Opengl hasn't been stagnant at all, it's just had a fairly massive media blackout since the unreal 3 era.

If the extension doesn't say ARB at the beginning, it doesn't count.

Quote:

Those compute shaders are interesting though... I wonder if they could replace opencl?

They probably could, but that's not really what they're there for. They're to make it easier to integrate computation (both graphical and non-graphical) into OpenGL programs. Relative to OpenCL, they have more data types in common and well-defined interaction with the graphics pipeline.

From the Article: "Prior versions of OpenGL ES are not true subsets of any version of OpenGL, and require some amount of porting to move from desktop to mobile or vice versa."

OpenGL has been a superset of OpenGL ES since version 4.1.

This is not entirely accurate.

There are two places in OpenGL where the subset nature of ES is suspect. First, is texture specification and uploading. You can write glTexImage2D calls that will work in both, but you won't necessarily get the same behavior.

In ES, the last three parameters actually specify the size of the image format's components as they will be stored by OpenGL; in desktop GL, they only specify the size of the image data the user is providing. As such, in ES, when you make certain calls, you'll get one texture format, while desktop GL will give you another, likely larger, image format.

The other place is GLSL. Again, you can write shaders that will work in both, but this relies on non-core language: `attribute`, `varying`, and the like. Desktop GLSL replaced those with `in` and `out` way back in the GLSL 1.30 days; it only provides the old keywords for backwards-compatibility reasons.

ES 3.0 is a proper subset, in that it uses the correct keywords and language, as well as the specification of how texture formats.

Please stop claiming D3D11 parity. This release does NOT do any such thing. Khronos made the same claims for OpenGL 4.1 and 4.2, by the way. It's just as much of a lie this time as it was the last two times.

There are various holes and missing bits of functionality in the new APIs introduced in OpenGL 4.3 that still make it impossible to do quite the same things you can do with D3D.

There is still a lack of direct state access and immutable objects at all levels, which imposes a performance overhead** over what D3D has, and greatly increases the ease of making mistakes when using OpenGL.

OpenGL still lacks any kind of control for the main output surface separate from its device context, unlike D3D's clear separation of device context and "swap buffer" (bad name, I know). This creates problems when you want to hold on to resources and recreate or share windows. It's possible only using platform-specific non-standard extensions, and then only if that platform actually bothered to offer said extensions.

Lastly, OpenGL still lacks any kind of multi-threaded rendering API at all. Again, platform-specific extensions can be used, if they exist for your platform. Unfortunately, even if you do decide to depend on those, the API they impose is incredibly cumbersome and error-prone compared to D3D11's, and again imposes an unnecessary level of inefficiency.

I know everyone loves OpenGL because it's "Open" (sort of) and portable and Direct3D is evil Microsoft stuff, but don't try to pretend that OpenGL as a programming interface is something that it is not. It is old, crufty, error-prone, inefficient, lacking in various necessary features, and poorly supported. Those platforms that Direct3D doesn't support are stuck at OpenGL 3.0 (Linux/MESA, and it's actually 2.1 + extensions - patented stuff unless you compile yourself) and OpenGL 3.2 (OS X) when using their native installed-by-default drivers, for instance.

** Yes, yes, we've all seen the benchmarks from Valve. It's one data point from one company's single engine, and the comparison is between not just APIs but implementations; it's entirely possible that NVIDIA's OpenGL driver is faster than their Direct3D driver, but it's absolutely ridiculous to somehow think that the OpenGL API itself is responsible for that speed. Especially when NVIDIA itself is one of the biggest complainers about the inefficiencies the OpenGL API imposes.

There is still a lack of direct state access and immutable objects at all levels, which imposes a performance overhead** over what D3D has, and greatly increases the ease of making mistakes when using OpenGL.

Feature parity. Meaning you can do the same thing from one API as the other. There isn't any actual functionality that is not possible from OpenGL. How you access objects and whether object state is immutable isn't functionality; it's API convenience.

Though Valve's tests don't exactly show a strong case that D3D is faster than OpenGL despite the lack of immutable objects and DSA. See below.

elanthis wrote:

OpenGL still lacks any kind of control for the main output surface separate from its device context, unlike D3D's clear separation of device context and "swap buffer" (bad name, I know). This creates problems when you want to hold on to resources and recreate or share windows. It's possible only using platform-specific non-standard extensions, and then only if that platform actually bothered to offer said extensions.

That's not true at all. You're perfectly able to create a context to preserve the resources, destroy the old window, and create a new window that shares with the temporary context.

Also, there's a difference between "platform-specific extensions" and non-standard extensions. Yes, doing the above requires platform-specific code, but that's just how OpenGL contexts are defined. How contexts are created, shared, and destroyed is simply not defined by the OpenGL spec. Platform-specific APIs govern that.

Also, it should be noted that D3D is very platform-specific. So it requires platform-specific code to do it in D3D too. It's just that OpenGL and the surrounding systems allow you to do it on non-Windows platforms.

That's just a bold-face lie. OpenGL support on Linux with binary drivers is more or less fine. It's well-past GL 3.0. Yes, MESA and open-source drivers aren't exactly far along, but that's irrelevant.

elanthis wrote:

** Yes, yes, we've all seen the benchmarks from Valve. It's one data point from one company's single engine, and the comparison is between not just APIs but implementations; it's entirely possible that NVIDIA's OpenGL driver is faster than their Direct3D driver, but it's absolutely ridiculous to somehow think that the OpenGL API itself is responsible for that speed. Especially when NVIDIA itself is one of the biggest complainers about the inefficiencies the OpenGL API imposes.

If NVIDIA's OpenGL driver is faster than their D3D driver... then NVIDIA is stupid. After all, your claim is that D3D's immutable object-based API is fundamentally superior to the OpenGL model. If this were true, then the only way for NVIDIA's OpenGL driver to be faster at doing the same tasks is if NVIDIA's D3D driver team were utterly incompetent.

So, either OpenGL doesn't have the problem you claim that it does, or NVIDIA doesn't know how to write D3D drivers. Considering that 99% of high-performance games use D3D, and thus NVIDIA would have every incentive to make their D3D drivers perform as fast as possible, I consider the latter rather unlikely.

> There are various holes and missing bits of functionality in the new APIs > introduced in OpenGL 4.3 that still make it impossible to do quite the > same things you can do with D3D.>> There is still a lack of direct state access and immutable objects at all > levels, which imposes a performance overhead** over what D3D has, and > greatly increases the ease of making mistakes when using OpenGL.

Please explain how a "lack of immutable objects" makes it "impossible to do quite the same things you can do with D3D."

> OpenGL still lacks any kind of control for the main output surface > separate from its device context, unlike D3D's clear separation of device > context and "swap buffer" (bad name, I know). This creates problems when > you want to hold on to resources and recreate or share windows. It's > possible only using platform-specific non-standard extensions, and then > only if that platform actually bothered to offer said extensions.

Windows are a platform-specific concept. Some platforms don't even have the concept of a window, but just have a full-screen buffer you draw into. Android has Activities. iOS has apps. Windows has... well, windows. This is all platform-specific stuff, inherently. If you programmed for anything other than Windows, maybe you'd have a clue about this.

> Lastly, OpenGL still lacks any kind of multi-threaded rendering API at > all. Again, platform-specific extensions can be used, if they exist for > your platform. Unfortunately, even if you do decide to depend on those, > the API they impose is incredibly cumbersome and error-prone compared to > D3D11's, and again imposes an unnecessary level of inefficiency.

So create a rendering thread, and do all operations there. Or use multiple threads and share the OpenGL state between them. What do you think D3D is doing behind the scenes? The need for synchronization doesn't go away just because you have a new API. It's usually better to have the choice about whether you want the overhead of synchronization, than to have it forced down your throat by the library implementor.

> I know everyone loves OpenGL because it's "Open" (sort of) and portable > and Direct3D is evil Microsoft stuff, but don't try to pretend that OpenGL > as a programming interface is something that it is not. It is old, crufty, > error-prone, inefficient, lacking in various necessary features, and > poorly supported.

Actually, it's D3D that's poorly supported. More iPhones and Android handsets were sold in 2011 than Windows PCs, by a factor at least 3 or 4. I'm glad you like D3D, but the world does not revolve around you. Please refrain from posting this kind of bikeshedding bullshit in the future.

Thank you, you have done a far better job of knocking that guy down a peg than I ever could of.

Lol at Platform-specific complaining. D3D is platform specific, completely, it runs on Windows and the Windows derivative that runs on Xbox (I don't know about the phones) only.

D3D is also full of cruft, you have to be careful to make sure that you don't drop into the wrong API, the documentation is difficult and spread out, the API itself has a bunch of pitfalls and gotchas. Just like any long-running system that needs backwards-compatibility. I'm not saying OpenGL is better. The whole extensions thing is a nightmare to work with, some simple operations require a lot of work, it is easy to miss some important step and get a black screen, despite everything seeming fine.

As for stuff that D3D does that OpenGL doesn't, I imagine that OpenGL does a few things that D3D doesn't (I don't know any in either direction though, so...).

Texture compression is the Alpha and Omega of OpenGL ES. Transmitting data from DRAM to GPU, and textures are the prime user here, costs power. Power costs battery.

Moving right along, OpenGL absolutely is full of ancient cruft, as well as more modern cruft introduced by vendors due to ARB/Kronos being very slow with revisions of the spec.

Now at the same time, Direct3D has a very similar problem. If you're coding for DX9, then everything introduced by DX10 and 11 is completely off-limits to you for no good reason without ripping out your rendering engine and starting again. If you like, however, you can pull in stuff from DX8 and 7, but only some stuff. Makes a lovely neat Visio diagram, but that's about it.

Even this sword, however, has two blades. It's much too easy for OpenGL code to become fossilised deep in an engine because there's no incentive to renew it. Eventually vendor extensions have to be used and you've suddenly got a codepath for every single GPU on the market which makes best use of none of them. Crap! Fallback on r300, fallback on r300, aaarrghh, she hasnae got tha powah cap'n, we're going tae hit mesa!

If OpenGL is functionally comparable to D3D and runs on more platforms, including Windows, why would developers use D3D?

Common sense says that there has to be a strong reason game developers prefer D3D. OpenGL had a significant advantage in the 90’s. If both APIs are comparable, how did D3D manage to persuade developers to give up the benefits of a multi-platform API?

I hear a lot about standards but there doesn’t seem to be a convergence towards a unified API. At least not in the next two years.

While Direct3D has still been first to standardize certain new features, the OpenGL designers are quickly picking them up and integrating them.

That's mostly because hardware designers design for Direct3D first, then OpenGL. It's better than it was, but with games pushing the tech, and DirectX powering most of those games, it makes sense. It's hardly Kronos' fault that Direct3D gets first swing at the features though.

MS has also been highly aggressive in defining new features. This to the point of sometimes putting in software variants that would kick in if the game requested a feature but the hardware could not deliver. End result, the game would run but it would be at single digit frames pr second.

If OpenGL is functionally comparable to D3D and runs on more platforms, including Windows, why would developers use D3D?

D3D is part of a larger package, DirectX. This provides all your gaming needs like networking, audio, inputs, 3D and 2D. The closest you have elsewhere is SDL, but that is more of a abstraction layer that use different OS features on different platforms.

If OpenGL is functionally comparable to D3D and runs on more platforms, including Windows, why would developers use D3D?

Common sense says that there has to be a strong reason game developers prefer D3D. OpenGL had a significant advantage in the 90’s. If both APIs are comparable, how did D3D manage to persuade developers to give up the benefits of a multi-platform API?

Also, don't forget: game developers generally don't care about being multi-platform. Who are they going to sell to, the 2% of people who have Linux boxes? The 3% with OSX boxes? Being Windows-only is not a downside for them.

As non-Windows platforms slowly grow in popularity, so too does the desire for game developers to make games on them.

** Yes, yes, we've all seen the benchmarks from Valve. It's one data point from one company's single engine, and the comparison is between not just APIs but implementations; it's entirely possible that NVIDIA's OpenGL driver is faster than their Direct3D driver, but it's absolutely ridiculous to somehow think that the OpenGL API itself is responsible for that speed. Especially when NVIDIA itself is one of the biggest complainers about the inefficiencies the OpenGL API imposes.

If NVIDIA's OpenGL driver is faster than their D3D driver... then NVIDIA is stupid. After all, your claim is that D3D's immutable object-based API is fundamentally superior to the OpenGL model. If this were true, then the only way for NVIDIA's OpenGL driver to be faster at doing the same tasks is if NVIDIA's D3D driver team were utterly incompetent.

So, either OpenGL doesn't have the problem you claim that it does, or NVIDIA doesn't know how to write D3D drivers. Considering that 99% of high-performance games use D3D, and thus NVIDIA would have every incentive to make their D3D drivers perform as fast as possible, I consider the latter rather unlikely.

In short, your argument fails.

Valve proved nothing more than successfully porting their game to Linux using an unknown OGL spec(my guess is the latest and fastest available) and managed to optimize it past the win version which makes use of a 2003 API(DX9). They got closer on the win side(shy of 15 fps at 300) but also via OGL and not DX. L4D2 is a specific implementation of a specific game engine(Valve's Source). It is also fairly old. They should have ported it making use of the corresponding 2003 OGL spec to really compare to DX.There was also nothing on visual fidelity from their benchmark. An entirely "black" press release fresh on the heel of Gabe's declaration of war towards Win8. L4D2 is not BF3 nor Crysis and what Valve achieved with it can never be an axiom regarding DX vs OGL.

OpenGL ES 3.0 GPUs will support more complex textures—for example, textures with arbitrary sizes (instead of requiring the dimensions of each edge to be a power of two)

Slightly misleading, as OpenGL ES 2.0 supports non-power-of-two textures just fine. What it does not support, without the NPOT extension, is wrap modes other than edge-clamping and filtering modes other than nearest-neighbour and linear filtering.

So, they still haven't solved any of the problems that were really bothering OpenGL users. That's not surprising, given it's a minor version bump, but still.. I hope they're at least working on the real issues, but knowing the ARB, it will probably take a decade and it will still kind of suck.