The same V8 with half the weight: One dev's experience with DX12

First announced back in 2014, Microsoft plans to officially launch DirectX 12 later this year alongside Windows 10.

The company's stated goals for the tech include distributing an API that works across all platforms and devices to provide a lower level of hardware abstraction, but what does that mean for game developers -- and how will it affect their workflow?

For now, the company is keeping a tight leash on what it's like to actually work with the tech: curious developers can apply to join the DX12 Early Access Program, but otherwise you're limited to keeping tabs on updates from Microsoft itself and its handful of DX12 partners, including Intel.

"it’s hard for me, even today, to specifically go ‘here are the top four bullets, the top four DX features you should be focusing on,'" says Intel's Matt Ployhar, who once worked directly on the DirectX team at Microsoft. 

"Here’s four good takeaways for a game developer, if you want to get into the nitty-gritty: you can scale up your battery life, you can scale up your framerate, you can scale up your meshes -- more units, higher polycount characters, richer environments -- and scale up your rendering algorithm."

For more practical examples we turned to Microsoft -- who basically told us to wait until the company's Build conference at the end of the month. So we contacted Dan Baker, a partner at Stardock-funded Oxide Games (developers of the Nitrous Engine) and an experienced engineer who previously worked on graphics tech at Firaxis and DirectX itself at Microsoft.

Oxide is working in conjunction with Stardock on Ashes of the Singularity, a Nitrous-powered RTS that uses DirectX 12 tech, and Baker -- who spoke about DX12 alongside Microsoft and AMD engineers -- offered the following thoughts on how the new tech may change the way developers make games in a conversation with Gamasutra.

You've spent some time working with DX12; what's new, and how has it specifically changed the way you work?

Baker: DirectX 12 is a radical software change to accommodate high throughput and threaded engines. The easiest description of DX12 is just a comparison with the size of the API between it and DX11. DX11: 41 interfaces, 274 methods, 168 structs, 71 enums, d3d12: 17 interfaces, 129 methods, 127 structs, 68 enums. By an objective measure, DX12 is literally half the size of DX11, and yet is a super-set (from a GPU standpoint) of every feature of DX11.

Physical comparisons between software and hardware can be dangerous, but in this case analogies are applicable. Imagine you bought a sports car, it had a big supercharged V8 engine with 500 horsepower, but it weighed 4500lbs. It has a full automatic transmission, stability control, heated seats, big stereo system, navigation, etc. Let’s call this car DX11. It might be a very nice street car, but if you give this thing to a professional (or even amateur) race driver they are going to hate it because fundamentally it's slow.

Now imagine the same V8 engine, but it's in a car that's only 2500lbs. It's a manual transmission, lacks a few of the things like heated seats and all the other luxury items that add weight. The car is technically more difficult to bring to its maximum potential, but it doesn't matter because it's so ridiculously fast and we already had a professional driver anyway.

This is a relevant analogy to the changes being made between DX11 and DX12. Certainly, some studios will find it more difficult to take advantage of what DX12 offers. But for many of us, and for many of the big games that players care about, we'll see huge improvements in both performance and consistency.

What sort of challenges have you and your team faced in moving over to DX12?

We had very minimal challenges moving to DX12. In many ways, supporting DX12 was simpler than supporting DX11 even though we wrote our DX11 path first and have spent a great deal of time optimizing for it (more then we have for any other API).

The reason for this is that DX12 is actually not a difficult API; what is difficult is a fully threaded, asynchronous engine. Like many next-generation focused studios, we've heavily invested in multi-core, asynchronous design. DX11 is a mismatch for this type of architecture. With Nitrous, we were increasingly handicapped by architectural problems at the API and driver level. That is, while our engine could handle high throughput, the API could not.

There are many techniques to make DX11 faster, such as state sorting and instancing. State sorting is the most critical thing you can do, and we do this very well; instancing is murkier because it isn't always applicable depending on the scene. For example, with Ashes of the Singularity it may be the case that the player has created thousands of the same unit. In this case, it might be possible in theory to instance them.

But imagine the same player instead creates one of every type of unit and building in the game, all on screen at the same time, and in such a pattern that it's impossible to instance them. What ends up happening is that these techniques to get higher throughput in DX11 only tend to benefit the fastest frames, not the slowest frames. Thus, with DX11 you often end up spending considerable engineering resources making the game go from 60 to 90 frames per second on your best-case scenarios, but only from 20 to 22 FPS on the slowest ones.

With DX12, this is not the case. We get even performance gains on the slow frames and the fast frames. Thus, it makes achieving high performance far less expensive. For many projects, there is an inflection point at which if your game is sufficiently complex it is actually cheaper to use DX12 then DX11, in some cases by a wide margin. DX12 allows us to spend more time worrying about the game design than API constraints. There is nothing more frustrating than going into a meeting with the designer and telling him or her that their design is great, but we can't do it because of driver overhead issues.

So how does that affect your game design going forward? Looking back, how does this compare to previous DirectX updates?

This is the first DirectX update that has been largely restricted to a software change. Normally, DirectX updates add considerable hardware features. In this case, however, the hardware capabilities of modern GPUs are actually pretty good so we aren't desperate for radical changes here.

Game design changes can be profound, as we expect it will enable us to design games that are far bigger and more varied then we've been able to do before. It will allow content to be made more cheaply, with more customization. Driver overhead is a huge cost in game development, reaching all the way down to the production artist. We really would prefer our artists to be worrying about the art, not the driver overhead involved in a particular asset.