Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Living with Vulkan and DirectX 12

by Brad Wardell on 10/07/19 10:53:00 am   Expert Blogs   Featured Blogs

1 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Since Stardock released the first DirectX 12 game, Ashes of the Singularity, we have been steadily working on improving our engine to support Vulkan and optimize DirectX 12.

Some observers have noted that Stardock's most recent two releases, Star Control: Origins and Siege of Centauri were DirectX 11 only. 

What gives? 

The answer, not surprisingly, has to do with the cost of support in the age of ever tighter margins versus the intrinsic benefit of the new APIs.

DirectX 11 vs. DirectX 12 and Vulkan in theory

Before I get too far, let's talk about Vulkan and DirectX 12. How are they different than DirectX 11?

In the most oversimplified sense, the biggest difference between the two new graphics stacks and DirectX 11 are that both Vulkan and DirectX 12 support multiple threads to send commands to the GPU simultaneously.   GPU multitasking. Hooray.  i.e.  ID3D12CommandQueue::ExecuteCommandLists  (send a bunch of commands and they get handled asynchronously).

In DirectX 11, calls to the GPU are handled synchronously. You could end up with a lot of waiting after calling Present(). Don't get me wrong, DX11 is still way better than DirectX 9. In DX9, the main thread had to call the GPU. 

So theoretically, DX12 and Vulkan have some huge advantages. You can imagine some cool things that become possible if multiple threads can be sending commands to the GPU at the same time.  As an AI guy, I dream of sending all my AI stuff to the GPU. 

But not all is sunshine and lollipops in DX12 and Vulkan.  You are given the power but you also get handed a lot of responsibility.  Both stacks give you a lot of rope to hang yourself.  DX11 is pretty idiot proof. DX12 and Vulkan, not so much.

Some examples of power and responsibility:

  • You manage memory yourself.
  • You manage various GPU resources yourself.
  • All the dumb things people do with multiple threads today now apply to the GPU

How does that translate to real-world experiences in games?  Here's one: Long load times in DirectX 12 games by default.  Is that DX12's fault? No.  It's just that many developers will do shader compiling at run-time -- all of them.  

It takes time and experience to learn what things you need to handle yourself.  Being smart about when and where to compile shaders takes some trial and error.

What about memory management? In DirectX 11 if I overallocate memory for someone's 2GB GPU, it just throws the rest into main memory for a slow-down.  On Vulkan and DX12, if you're not careful, your app crashes.

The performance advantage

DirectX 12 and Vulkan give you the keys to the kingdom.  This is terrific if maximizing performance is your objective and you have the in-house technical expertise (and budget) to use them.

The power that you get with DirectX 12 and Vulkan translates into an almost effortless 15% performance gain over DirectX 11.  In when we put our GFX engineers onto it, we can increase that margin to 20% to 120% depending on the game.

The real world of game development

Which brings us back to the question: Why didn't Stardock's new games stick with DirectX 11?  And the answer is: The performance gain you get from Vulkan or DirectX 12 comes down to the type of game it is.   

Case in point: Stardock has DirectX 12 and Vulkan versions of Star Control: Origins. The performance gain is about 20% over DirectX 11.  The gain is relatively low because, well, it's Star Control.  It's not a graphics intensive game (except for certain particle effects on planets which don't benefit much from the new stacks).   So we have to weigh the cost of doubling or tripling our QA compatibility budget with a fairly nominal performance gain.  And even now, we run into driver bugs on DirectX 12 and Vulkan that result in crashes or other problems that we just don't have the budget to investigate.

Gamers, not developers, will drive DirectX 12 and Vulkan demand

So what about future titles? Well the good news is that the drivers and tools have gotten a lot better.  

Moreover, Vulkan is a requirement for platforms like Stadia and native Linux support which is driving further refinement there as well.

Other trends coming to games will essentially require Vulkan and DirectX 12 to be viable.  Ray Tracing, OSL, Decoupled Shading, Compute-Shader based physics and AI only become practical on Vulkan and DirectX 12. And they're coming.  

Vulkan and DirectX 12 also give us a lot of cool toys and flexibility like AMD's FidelityFX, Async Compute, low-level HDR tuning, Freesync. Not to mention, high-refresh monitors are pretty irresistible once you use one.

When gamers start to see the benefits of these features that will in turn push game developers to adopt the new APIs in order to compete.

What should developers support today?

Should you, a game developer support Vulkan and DirectX 12 today? 

It depends. 

What platforms are you supporting? How many entities does your game need to handle? How much QA and support bandwidth do you have?  If you're an XBOX developer it's a no-brainer.  But on the PC? It's less clear.

When Vulkan and DirectX 12 arrived, they were touted mostly for their performance benefits.  But given how fast GPU performance improves, it's been tough to get developers to justify the cost of supporting additional APIs simply for a nominal performance. 

But frame-rate differences are, I think, the wrong area to emphasize.  If a gamer is that focused on frame-rate they'll just buy a faster video card.  

Instead, it's when developers are able to deliver games that do things, on existing hardware, that just aren't possible with DirectX 11 and there is a market demand for those things by the buying public.  Frame-rate isn't enough.

For us, it's a right tool for the right job.  If DirectX 11 gets it done, we'll use that.  On the other hand, some of our upcoming projects may not support DirectX 11 at all simply because of the mainstreaming of 8+ core CPUs which are making it irresistible to not design new types of games that require massive parallelism to work and being able to team those cores up with modern GPUs means DirectX 12 and Vulkan.

Ultimately, these APIs are tools for developers.  Pick the one you need to make the game you want to make.

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States

Engine Programmer
Legends of Learning
Legends of Learning — Baltimore, Maryland, United States

Senior Gameplay Engineer - $160k - Remote OK
Bytro Labs GmbH
Bytro Labs GmbH — Hamburg, Germany

Senior Product Owner / Live-Ops Owner (f/m/x)

Loading Comments

loader image