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