Direct3D 12 In Depth

This brings us to Direct3D 12, which is Microsoft’s entry into the world of low level graphics programming. Microsoft is still neck-deep in development of Direct3D 12 so far – they’re currently targeting it for game releases in Holiday 2015, roughly 18 months off – and as such Microsoft hasn’t released a ton of details about the API to the public yet. But they have given us a broad overview of what the plan to accomplish, with a couple of technical details on how they will be doing this.

At a high level there is no denying the fact that Direct3D 12 looks a lot like Mantle. Microsoft has set out with the same basic goals as AMD did with Mantle and looks to be achieving some of them in the same manner. Which to no surprise then that the end products are going to be similar as a result.

As with Mantle, the primary goal for Direct3D 12 is to greatly reduce the CPU overhead that we’ve talked about previously. As the biggest source of CPU overhead is having Direct3D assemble the command lists/buffers for a GPU, Direct3D 12 will be moving that job over to developers. By assembling their own command lists developers can more easily spread out the task over multiple cores, and this alone will have a significant impact on CPU utilization. At this point we don’t know what Direct3D 12 command lists will look like, and this will likely be one of the design choices that separates Direct3D 12 from Mantle, but there’s no reason at this time to expect them to be much different.

For Comparison: D3D11 Command Buffer

Microsoft will also be introducing a similar concept, a bundle, which is functionally a form of a reusable command list. This again is another CPU saving step, as using a bundle in place of multiple command lists further cuts down on the amount of CPU time spent making submissions. In this case the idea behind a bundle is to submit work once, and then allow the bundle to be executed multiple times with minor variations. Microsoft specifically notes having a character drawn twice with different textures as being a use case for this structure.

Meanwhile it’s interesting to note that with this change Microsoft has admitted that Direct3D 11 style immediate/deferred command lists haven’t lived up to their goals, stating “deferred contexts also do not map perfectly to hardware, and so relatively little work can be done in them.” To our knowledge the only game able to make significant use of the feature was Civilization V, and even then we’ve seen AMD video cards perform very well without supporting the feature.

Moving on, Direct3D 12 will also be introducing pipeline state objects. With pipeline state objects we’re really getting into the nitty-gritty of command buffer execution and how the various graphics architectures differ, but the important bit to take away is that most architectures don’t have the ability to freely transition between pipeline states as much as Direct3D 11 would like. This leads to problems for how quickly the hardware state can be set, as Direct3D must go back and take into account these hardware limitations.

The solution to this will be the aforementioned pipeline state objects (PSOs). PSOs bypass some of these pipeline limitations by using objects that are finalized on creation. Nitty-gritty details aside, the outcome from this is that it further reduces CPU overhead, once again increasing the number of draw calls the CPU can submit or freeing it up for other tasks.

The final major addition to Direct3D 12 is descriptor heaps. Going back to 2012, one of the features introduced on NVIDIA’s then-new Kepler architecture was bindless resources, which bypassed the previous 128 slot limitation on resources (textures, etc). Through bindless an essentially infinite number of resources could be addressed, at a performance penalty, though an additional layer of indirection in memory accesses.

Descriptor heaps in turn appear to be the integration of bindless resources in Direct3D 12. Microsoft does not specifically call descriptor heaps bindless, but the description of slots and draw calls makes it clear that they’re intending to solve the problem with the bindless solution. With descriptor heaps and descriptor tables to reside in those heaps, Direct3D 12 will be able to perform bindless operations, both expanding the number of resources available to shader programs, and even outright dynamic indexing of resources.

Finally, there are a few miscellaneous features that have popped up in Microsoft’s slides that have caught our attention, if only due to the lack of details provided. Specifically, the mention of compressed resources stands out. The resources mentioned, ASTC and JPEG, are not resources formats that we know to be supported on any current PC GPU. In the case of ASTC, Khronos’s next generation texture compression format, it is a finalized standard that will be supported on all GPUs in time as a core part of the OpenGL standard. Meanwhile JPEG is not a feature we’ve seen on any API roadmaps before.

Image Courtesy PC Perspective

To that end, the addition of ASTC is not all that surprising. Since it is royalty free and not otherwise restricted to OpenGL-only, there’s no reason not to support it when all of the underlying hardware will (eventually) support it anyhow.

JPEG on the other hand is a very curious thing to mention, as its lack of existence on any API roadmaps goes along with the fact that we’re not aware of anyone having announced plans to support JPEG in hardware. Furthermore JPEG is not a fixed ratio compressor – the number of bits a given sized input will generate can vary – which for GPUs would typically be a bad thing. It stands to reason then that Microsoft knows a bit more about what features are in the R&D pipelines for the GPU makers, and that someone will be implementing hardware JPEG support. So we’ll have to keep an eye on this and see what pops up.

Making a Common Low Level API

The need for a low level graphics API like Direct3D 12 is clear, but establishing a common API is no easy task. Abstraction is both what gives Direct3D 11 its ability to work on multiple platforms and robs Direct3D 11 of some of its performance. So to make a low level API that works across AMD, NVIDIA, Intel, Qualcomm, and others’ GPUs requires a careful balancing act to bring low level API improvements while adding no more abstraction than is necessary.

At this stage in development Microsoft is not ready to talk about that aspect of API development; for the moment that level of access is restricted to a small group of approved developers. But given their hardware requirements we can make a few educated guesses about what’s going on behind the scenes.

Of the big 3 GPU vendors, all of them have confirmed what GPUs will be supported. For Intel their Gen 7.5 GPUs (Haswell generation) will support Direct3D 12. As for NVIDIA, Fermi, Kepler, and Maxwell will support Direct3D 12. And for AMD, GCN 1.0 and GCN 1.1 will support Direct3D 12.

Direct3D 12 Confirmed Supported GPUs
AMD GCN 1.0 (Radeon 7000/8000/200)
GCN 1.1 (Radeon 200)
Intel Gen 7.5 (Haswell/4th Gen Core)
NVIDIA Fermi (GeForce 400/500)
Kepler (GeForce 600/700/800)
Maxwell (GeForce 700/800)

The interesting thing about all of this is what’s excluded: namely, AMD’s D3D11 VLIW5 and VLIW4 architectures. We’ve written about VLIW in comparison to GCN in great depth, and the takeaway from that is that unlike any of the other architectures here, only AMD was using a VLIW design. Every architecture has its strengths and weaknesses, and while VLIW could pack a lot of hardware in a small amount of space, the inflexible scheduling inherent to the execution model was a very big part of the reason that AMD moved to GCN, along with a number of special cases regarding pipeline and memory operations.

Now why do we bring this up? Because with GCN, Fermi, and Gen 7.5, all PC GPUs suddenly started looking a lot more alike. To be clear there are still a number of differences between these architectures, from their warp/wavefront size to how their SIMDs are organized and what they’re capable of. But the important point is that with each successive generation, driven by the flexibility required for efficient GPU computing, these architectures have become more and more alike. They’re far more similar now than they have been since even the earliest days of programmable GPUs.

Wavefront Execution Example: SIMD vs. VLIW. Not To Scale - Wavefront Size 16

Ultimately, all of this is a long-winded way of saying that a bit part of the reason that there can even be a common low level graphics API is because the hardware has homogenized to the point where less and less abstraction is necessary. On a spectrum ranging from a shared ISA (e.g. x86) to widely divergent designs, we’re nowhere near the former, but importantly we’re also nowhere near the latter. This is a subject we’re going to have to watch with great interest, because MS and the GPU vendors (through their drivers) are still going to have to introduce some level of abstraction to make everyone work together through a single common low level API. But the situation with modern hardware means that (with any luck) the additional abstraction with Direct3D 12 over something like Mantle will prove to be insignificant.

Finally, it’s worth pointing out that last week’s developments with Direct3D couldn’t be happening without a degree of political backbone, too. The problem in introducing any new graphics standard is not just technical, but in bringing together companies with differing interests and whose best interests don’t necessarily involve fast-tracking every technology proposed.

Microsoft to that end currently holds a very interesting spot in the world of PC graphics, being the maintainer of the most popular PC graphics API. And unlike the designed-by-committee OpenGL, Microsoft has some (but not complete) leverage to push new technologies through when the GPU vendors and software vendors would otherwise be at loggerheads with each other. So while Microsoft is being clear this is a joint effort between all of the involved parties, there’s still something to be said for having the influence and power to bring down changes that may not be popular with everyone.

Why Low Level Programming? Game Development, Consoles, and Mobile Devices
Comments Locked


View All Comments

  • B3an - Monday, March 24, 2014 - link

    For anyone interested.. new DX12 graphics features are coming and yet to be announced:

    As i suspected, current hardware will benefit from the DX12 performance gains, but you will need new hardware for the new graphics features. Same as previous DX releases.
  • Tristor - Monday, March 24, 2014 - link

    I should also point out that OpenGL is already more performant in draw calls than Mantle, and is fully multi-threaded. It has been for a LONG time. More importantly, it's cross-platforms. If more game devs start using OpenGL+OpenSDL we will end up with more games available on other platforms (Mac/Linux). I'm hoping the huge push Valve is doing with SteamOS will encourage this and we'll see the benefits across the board in PC gaming.

    Here's an nVidia dev talking at Steam Dev Days about the performance increases gained from simply porting to OpenGL over DirectX (these surpass the gains from moving to Mantle): - AMD already has promised (and started releasing) OpenGL extensions that fully expose the capabilities of GCN hardware which has made OpenGL more performant on AMD than Mantle. - Here's John Carmack himself (one of the few devs who actually embraces OpenGL fully) talking about how nVidia's OpenGL extensions make Mantle irrelevant because OpenGL is faster.

    So basically, OpenGL > Mantle > DirectX and OpenGL is also cross-platform and has been around for ages. But, nobody wants to use it because it's "too hard" or "takes too long". Companies like EA, Activision, and Ubisoft don't want to make well-optimized games, they want to make games quickly while milking profitable franchises so they can take their billions to the bank. For the rest of the games out there that are trying to do something cool (Project CARS, Star Swarm, et al) they should really start investing heavily in OpenGL. End of story.
  • inighthawki - Monday, March 24, 2014 - link

    "I should also point out that OpenGL is already more performant in draw calls than Mantle, and is fully multi-threaded. It has been for a LONG time"
    Being multithreaded doesn't mean anything. In OpenGLs case it just means it's thread safe, so you can go queue up some render commands on thread 2 while you do app work on thread 1. No different than what DX has had for even longer than OpenGL. DX12 is introducing a better multithreading model which OpenGL doesn't have. One where you can actually split rendering work equally across cores.

    "More importantly, it's cross-platforms. If more game devs start using OpenGL+OpenSDL we will end up with more games available on other platforms (Mac/Linux)"
    I'm sure a lot of people will hate me for this, but who cares? OSX+Linux marketshare combined is a tiny fraction of what Windows is, and there's not a lot of money in it.

    OpenGL is a horrible API comprised of a horrible interface trying to retain backwards compatibility with older version that should never even be used, coupled with a bunch of vendor specific extensions that khronos decided to make official because someone did the work for them of figuring it out.

    "AMD already has promised (and started releasing) OpenGL extensions that fully expose the capabilities of GCN hardware which has made OpenGL more performant on AMD than Mantle."
    Why would you ever want extensions that are vendor specific? Half the point of your post is "don't use mantle because tis vendor specific" then you praise OpenGL for gaining the ability to have vendor specific enhancements?

    "Here's John Carmack himself (one of the few devs who actually embraces OpenGL fully) talking about how nVidia's OpenGL extensions make Mantle irrelevant because OpenGL is faster."
    That's not what he said at all, I suggest you re-read it.
  • Lerianis - Monday, March 31, 2014 - link

    Well, that is kinda becoming the new 'normal'..... in order to use the new graphics stuff, you need a new graphics card.
    I'm getting kinda angry in that newer graphics cards sold on Newegg all need a minimum of a 400 Watt power supply. My nearly brand new computer has? 300 watts. So either these companies need to start putting at least a 400 Watt power supply in these machines or the graphics card companies need to make a selection of cards that regular home users can find that they can plug into their old computers that only need 300 Watts.
  • Tristor - Monday, March 24, 2014 - link

    If devs have been asking for lower level access on the PC "forever" why does nobody use OpenGL? OpenGL provides unimpeded lower level access that DirectX does not, it's cross-platform, it's well-optimized for in hardware and drivers on both AMD and nVidia, and with the numerous OpenGL extensions available there's no features available in DirectX which are missing in OpenGL.

    I'll tell you why, because OpenGL is harder to write for. "Low-level access" implies low-level programming, which is more difficult to do, especially to do properly, and it requires higher quality programmers to pull it off. The reason DirectX is popular is because its ridiculously easy to write for, not because it's well-optimized or good. This has always been the case. If game developers were truly interested in low-level access and optimizations they would have been using OpenGL this entire time.

  • Mr Perfect - Monday, March 24, 2014 - link

    OpenGL is probably also a victim of DirectX's popularity. IE; no one uses OpenGL because no one uses OpenGL. Middleware engines all seem to focus on DirectX, hardware vendors only advertise support for new DirectX features, competing games all use DirectX... It reminds me of Windows Phone and how it doesn't receive support because everyone's all busy doing Android and IOS work.
  • DarkXale - Tuesday, March 25, 2014 - link

    It generally doesn't help that (PC) titles haven't really made a good impression.

    RAGE is not exactly a good demonstrator for graphical stability and reliability, and it was supposed to the a showcase for the ID Tech engine and OGL. Needless to say, it failed at that.
    Another game, Brink, was filled with graphical problems; the game was unplayable on AMD systems.

    OGL2 software tends to be more reliable - but the problem you have then is that you're using OGL2. Which isn't exactly modern, and was written in the more... problematic... days of OGL.
  • lmcd - Monday, March 24, 2014 - link

    Tristor, you're off-base. OpenGL isn't lower-level than Mantle and that has been long-acknowledged. OpenGL isn't even significantly lower-level than DirectX. DirectX is popular because it's standardized, not because it's easy to write for, and strong standards are better than weak standards. OpenGL regularly plays catch-up with DirectX feature sets and relies extensively on extensions which are not standardized.

    Different failings.
  • bluevaping - Friday, April 4, 2014 - link

    Big gaming houses use plenty of different API's not just Direct X or Open Gl. Microsoft likes keep things were they are, until the floor drops out. Oh snap gaming PC sales are declining. It's sad that AMD is trying to get more performance from hardware and wrote their own API. Gamers with different priorities are moving away from PC's to Console(simple and less expensive hardware) to Mobile Tablets(great screens with cheaper games). There are Open GL games, some are ports and some are released on multiple platforms at the same time . I have played dozens and dozens of them. We won't see record level of PC Gamers like the past. But developers will try to reach out to other platforms to make up for it. Microsoft little to late. They should be making better tools for Open GL. Just embrace it, Microsoft.
  • ericore - Monday, March 24, 2014 - link

    There are no console advantages.
    I think I abandoned consoles 2 months after purchase, never looked back.

    The games are pricier.
    The load times are significantly greater.
    No modding ability.
    Same price of a PC which can do so much more.
    The AI on consoles is dumbed down.

    Consoles are for kids.
    PCs are for adults.

Log in

Don't have an account? Sign up now