OpenGL vs. DirectX – what really happened?

Games using DirectX 11 or DirectX 12 might be popular in online publications and YouTube channels but DirectX is not the only API for gaming. Do you know that these games do not use DirectX?

• DOOM 3 (2004)
• Enemy Territory: Quake Wars (2007)
• BRINK (2011)
• RAGE (2011)
• DOOM 3: BFG Edition (2012)
• Wolfenstein: The New Order (2014)
• Wolfenstein: The Old Blood (2015)
• DOOM (2016)

Yes, there is Vulkan and it is gaining popularity but before Vulkan, there is OpenGL. One of the advantages of OpenGL is it’s an open standard which means it is compatible with Linux, macOS, and Windows. However, despite that advantage, majority of games today still use DirectX.

Why?

To give our readers reliable information about this topic, I asked game developers that use OpenGL. Their answers are a bit lengthy and I have initially thought of paraphrasing it but decided to deliver their answers as is so there would be no misrepresentations. Here are the questions I asked them:

• If OpenGL has the same features and achieving performance parity with DirectX is possible, why do most game developers still use DirectX?
• Would OpenGL still be practical to use for new games (2019 and later) now that Vulkan is here?
• What do you think is needed to convince majority of game developers to use OpenGL and Vulkan instead of DirectX11/12?

The answers

The first one is Alen Ladavac, the Chief Technology Officer of Croteam. For those not familiar, Croteam is the developer of The Talos Principle, the 1st game to use Vulkan in February 2016.

First, OpenGL became way too complex to maintain by the IHVs. Even DirectX 11 already required a very complex structure to be fast. Where you now see that DX11 is still sometimes faster than DX12 or Vulkan in some games, it is due to extensive optimizations inside the driver. Optimizations that were created and maintained at no small cost of engineering resources. Resources that could be better spent elsewhere – since the sole reason those were needed is that the old APIs were a patchwork of new tuneups on top of old concepts, and still in their core used the concepts that were well thought out in 80s and 90s, for use in SGI workstations (does anyone even remember those anymore 🙂 ) and the likes, but that are a bad fit for the way the modern GPUs work.

Vulkan and DirectX 12 were re-specified from the ground up to be much closer to what you could consider a union of concepts of how different GPUs (desktop/mobile, UMA and separate memory, strict tiled-based deferred and various hybrids, different vendors’ approaches, etc) today work. This requires a complete rethinking from the application perspective, and that is a lot of work in any of today’s engines, and that’s why we are just beginning to see the true benefits of DirectX 12 and Vulkan. They are not ideal, as compromises still had to be made to make the APIs abstract and portable, but they are way, way better than the old state-machine-based ones. The old ones were kinda in denial of the facts like e.g. that GPU memory is separate from host memory – on some machines, that textures and other buffers on the GPU might not be in the format you think they are, or even that the some of the things they call “units” (e.g. blending, vertex assembly…) don’t always exist as specialized hardware in some GPUs today. That was both dragging down IHVs who had to emulate all that, and devs who couldn’t use the hardware to full potential. 

But the biggest improvement from the end user perspective is not just average performance, but finally control of frame stutter. Many stuttering issues were caused previously by the driver doing “on the fly” caching, conversions and compilation – as situations in the scene changed. This is now exposed to the application so that the application can have control of what is cached and prepared when – and thus prepare it in load time or stream in the background. This part is particularly hard to explain, but let’s just say for a very simple example that as you are turning your view in  a game, you see an object in the game that you’ve seen before, but in this part of scene it has some different effect on it. It eg. uses the same pixel shader, but with a different blending mode. The driver didn’t yet see this combination, and that combination requires specific changes to the GPU state. That frame will suffer a slight stutter since the driver has to recompile some shaders or similar. In Vulkan and DirectX 12, the app has complete control over this and can do this better. Note that it doesn’t mean it does! Most game engines were written in the age of the old APIs, so their first implementations of the modern ones were based on doing the same kind of on-the-fly caching as the driver would previously do. But the ability is there now. And as the engines improve, we now see more and more benefits being used. So in theory, you could have a stutter-free game now, and some are already getting quite close to that goal.

So in short – the questions you are asking are perhaps a bit misstated. Just forget about OpenGL. For high performance gaming, going forward… OpenGL and DX11 are dead. It is only viable for retro games, simple demos, etc.

And for DX12 vs Vulkan – there really isn’t anything else but portability. You need DX12 for Xbox and Vulkan for Android and Linux. There’s also Metal for iOS and OSX and Sony’s own API for PS4. But conceptually, those are all much more similar to each other, than to OpenGL or DX11.

Next up is Josh “Cheeseness” Bush. He ported to Linux Hand of Fate and The Day of the Tentacle Remastered.

The answer to item 1 is all about dominant narratives and familiarity. When people are taught to use DirectX in schools, when all of their friends and peers use DirectX, and when most of the resources they can find about best practices and optimisation are generally focused on DirectX, it’s easy for it to become a default. Microsoft having whole departments of dedicated marketing, PR, and customer relations people allows for stronger strategies for building and maintaing dominant mindshare across the industry. I wholly agree with the points that David makes in his article, and while I think they’re still worthwhile, they’re not so relevant in today’s industry. The vast majority of developers use third party engines (like Unity, Ureal, idTech, etc. etc. etc.) where renders are developed and maintained upstream. In these cases, game developers usually have a box to tick, and without a lot of first hand experience, whatever’s familiar is the easiest thing to go with. Fewer shipped renderers means less QA (something many developers struggle with already), so developers will often prefer to pick a minimal list than enable everything.

Moving on to item 2, all cross platform engines implement renderers based on open APIs like OpenGL and Vulkan, and most prominent engines these days are cross platform. Some developers may still prefer to ship OpenGL renderers because Vulkan is new (and therefore scary), but positive messaging from companies like Valve and developers like Croteam likely help to counter that a bit. Developers out there who are writing their own renderers, have strong OpenGL skills, and want to leaverage those skills, will still find OpenGL viable to ship these days. It’s still the only API that will work on Linux, Mac and Windows without some kind of interpretation layer. At this stage, I have no plans to write a Vulkan renderer for my game engine. As a Linux based developer, open APIs are definitely at the top of my list, though.

Regarding item 3, the solution I like to pursue is increasing the number of positive narratives and friendly, welcoming resources. There’s a hard line to walk between an empowering “Croteam use Vulkan, so Vulkan must be cool” and a dismepowering “Croteam use Vulkan, but Croteam are Croteam.” I feel like we’ve seen this a bit with Linux support as well – when Valve shipped almost all of their back catalogue on Linux, that wasn’t really seen by the rest of the industry as a demonstration that Linux support is a viable option, it was seen as Valve having resources to do things that most developers don’t. As users, we can shape some of these positive narratives by being patient, supportive and welcoming. Celebrating developers who put effort into supporting the things we care about (even if their first steps aren’t perfect) can help a developer feel like those efforts were worthwhile.

Adopting new technologies always brings headaches, especially if that also means moving into unfamiliar spaces. Moving up to a newer version
of DirectX at least feels familiar to an experienced DirectX developer,
and problems/hurdles/ideosyncrasies are easier to overlook as a result. Moving to an open API without a strong support network of friends who’ve done the same in the past is by nature isolating and intimidating, which makes any problems encountered along the way feel larger than they are. That said, there’s a lot that platform and driver vendors could do to promote positive mindshare for open, cross platform APIs.

If Apple caved and embraced native Vulkan drivers, having one API that could do everything would definitely be a strong selling point (I don’t expect this to ever happen, and with the announced deprecation of OpenGL on MacOS, it’s Metal or nothing). When talking about whether one graphics API is more performant than another, that’s really talking about whether drivers’ implementations of those APIs are more performant than another, so the attention that driver vendors give OpenGL and Vulkan, and the level of prominence they give open APIs in their promotional materials is likely to have an impact as well.

The number one biggest factor in today’s climate though, is having
renderers that use open, cross platform graphics APIs in the engines
that developers are using, and I think we’re already a good way down
that path.

Before I wrap this up, I’d like to share something interesting. Alen Ladavac’s comment about DirectX 12 for XBox One made me ask why not just use Vulkan for XBox One? It is also using a CPU and GPU similar to the ones used in gaming PC’s and it would be beneficial if game developers use Vulkan for gaming consoles and gaming PC’s. Even Nintendo Switch also supports Vulkan. His reply is:

Well, I would certainly love that. Why not? Well guess you have to ask Microsoft about it.
If you know what I mean… 😉

I will write a follow up article to discuss more on Vulkan and why it matters to PC gamers. Follow us on Facebook, Twitter, and YouTube.