Dan Baker of Oxide games helped make DX11, and he was also the graphics lead on Civilization 5. Civ 5’s DX11 mode has some of the highest draw calls of any DX11 game ever made, so he knows a thing or two API's and here are his thoughts. A good read.
For this reason, many of the most experienced developers, Oxide included, had for years advocated a lighter, simpler API that did the absolute minimum that it could get away with. We believed we needed a teardown of the entire API rather than some modifications of current APIs. Admittedly, this was after advocating no API at all caused the hardware architects’ faces to pale a bit too much. But if we were to build something evil, at least we could make it the least evil possible.
It was this group of advocates who, with AMD, pioneered the development of Mantle. Mantle was not an API birthed by a hardware vendor, but rather a child born of developers and AMD to create a completely different class of API. AMD selected a small but expert group of developers to help advance it. The intention was not to develop the end-all solution for every developer, but rather to build something that didn’t block our studios from maximizing the very capable GPUs that AMD was building.
This group spent quite a bit of time with AMD going over and helping shape the API. Many of the features and structure of Mantle came from developers, not from AMD itself. For example, we could show that nearly every batch required at least some small data payload, so we built in a specialized fast path just for it.
Much of it was a learning experience for AMD, showing just how many things we as developers really don’t need an API to do. For example, loading textures into GPU memory has to be an asynchronous process, with a few GPU commands called to copy it into place and prepare it before we use it. As it turns out, this task was once owned by the driver, but our engine was perfectly capable of doing it both faster and more reliably than any driver could.
Oxide still remembers the day we did our first tests. We watched as driver overhead, once the dominant chunk of our frame execution time, practically disappeared. We watched as the thick driver threads that often polluted our cache and stole our CPUs disappeared. We watched as the little driver overhead we had linearly scaled across our cores. We saw this, in spite of the fact that Mantle was a very new API, competing against established and optimized APIs. There are still many optimizations that both we and AMD have yet to make!
We heard nothing of the development of a new version of D3D12 until sometime after the early tests of Mantle were indicating that this radically different API model could work, and work well – data which we shared with Microsoft. What prompted Microsoft to redesign DX is difficult to pin down, but we’d like to think that it would never have happened if Mantle hadn’t changed the game. We are delighted in DX12’s architectural similarities to Mantle, and see it is a validation of the pioneering work that Oxide was privileged to be part of.
Does D3D12 mitigate the need for Mantle? Not at all. Though it is difficult to determine without more complete information on D3D12, our expectation is that Mantle will have the edge of D3D12 in terms of CPU performance. This is because the GCN architecture by AMD is the most general of all the current GPUs, and therefore the driver needs to do a bit less.