With GDC 2014 having drawn to a close, we have finally seen what is easily the most exciting piece of news for PC gamers. As previously teased by Microsoft, Microsoft took to the stage last week to announce the next iteration of DirectX: DirectX 12. And as hinted at by the session description, Microsoft’s session was all about bringing low level graphics programming to Direct3D.

As is often the case for these early announcements Microsoft has been careful on releasing too many technical details at once. But from their presentation and the smaller press releases put together by their GPU partners, we’ve been given our first glimpse at Microsoft’s plans for low level programming in Direct3D.

Preface: Why Low Level Programming?

The subject of low level graphics programming has become a very hot topic very quickly in the PC graphics industry. In the last 6 months we’ve gone from low level programming being a backburner subject, to being a major public initiative for AMD, to now being a major initiative for the PC gaming industry as a whole through Direct3D 12. The sudden surge in interest and development isn’t a mistake – this is a subject that has been brewing for years – but it’s within the last couple of years that all of the pieces have finally come together.

But why are we seeing so much interest in low level graphics programming on the PC? The short answer is performance, and more specifically what can be gained from returning to it.

Something worth pointing out right away is that low level programming is not new or even all that uncommon. Most high performance console games are written in such a manner, thanks to the fact that consoles are fixed platforms and therefore easily allow this style of programming to be used. By working with hardware at such a low level programmers are able to tease out a great deal of performance of this hardware, which is why console games look and perform as well as they do given the consoles’ underpowered specifications relative to the PC hardware from which they’re derived.

However with PCs the same cannot be said. PCs, being a flexible platform, have long worked off of high level APIs such as Direct3D and OpenGL. Through the powerful abstraction provided by these high level APIs, PCs have been able to support a wide variety of hardware and over a much longer span of time. With low level PC graphics programming having essentially died with DOS and vendor specific APIs, PCs have traded some performance for the convenience and flexibility that abstraction offers.

The nature of that performance tradeoff has shifted over the years though, requiring that it be reevaluated. As we’ve covered in great detail in our look at AMD’s Mantle, these tradeoffs were established at a time when CPUs and GPUs were growing in performance by leaps and bounds year after year. But in the last decade or so that has changed – CPUs are no longer rapidly increasing in performance, especially in the case of single-threaded performance. CPU clockspeeds have reached a point where higher clockspeeds are increasingly power-expensive, and the “low hanging fruit” for improving CPU IPC has long been exhausted. Meanwhile GPUs have roughly continued their incredible pace of growth, owing to the embarrassingly parallel nature of graphics rendering.

The result is that when looking at single threaded CPU performance, GPUs have greatly outstripped CPU performance growth. This in and of itself isn’t necessarily a problem, but it does present a problem when coupled with the high level APIs used for PC graphics. The bulk of the work these APIs do in preparing data for GPUs is single threaded by its very nature, causing the slowdown in CPU performance increases to create a bottleneck. As a result of this gap and its ever-increasing nature, the potential for bottlenecking has similarly increased; the price of abstraction is the CPU performance required to provide it.

Low level programming in contrast is more resistant against this type of bottlenecking. There is still the need for a “master” thread and hence the possibility of bottlenecking on that master, but low level programming styles have no need for a CPU-intensive API and runtime to prepare data for GPUs. This makes it much easier to farm out work to multiple CPU cores, protecting against this bottlenecking. To use consoles as an example once again, this is why they are capable of so much with such a (relatively) weak CPU, as they’re better able to utilize their multiple CPU cores than a high level programmed PC can.

The end result of this situation is that it has become time to seriously reevaluate the place of low level graphics programming in the PC space. Game developers and GPU vendors alike want better performance. Meanwhile, though it’s a bit cynical, there’s a very real threat posed by the latest crop of consoles, putting PC gaming in a tight spot where it needs to adapt to keep pace with the consoles. PCs still hold a massive lead in single-threaded CPU performance, but given the limits we’ve discussed earlier, too much bottlenecking can lead to the PC being the slower platform despite the significant hardware advantage. A PC platform that can process fewer draw calls than a $400 game console is a poor outcome for the industry as a whole.

Direct3D 12 In Depth
Comments Locked

105 Comments

View All Comments

  • The_Assimilator - Monday, March 24, 2014 - link

    The reason for CPUs bottlenecking GPUs is simple: single- vs multi-threaded. Writing a multi-threaded game engine that works properly is extremely difficult. It's even more difficult if you're licensing a graphics (and/or audio, etc.) engine that you need to integrate with your game's core, because you then become dependant on that engine and how it works, whether it's threaded, etc.

    Unfortunately, off-the-shelf game engines - particularly graphics - have remained steadfastly single-threaded, and that's not something DirectX or Mantle will be able to change.

    "To use consoles as an example once again, this is why they are capable of so much with such a (relatively) weak CPU, as they’re better able to utilize their multiple CPU cores than a high level programmed PC can."

    Nonsense. The current crop of consoles use x86-64 and DirectX 11-class hardware, programming games for them is virtually identical to programming games for (a slow) PC.

    "Meanwhile, though it’s a bit cynical, there’s a very real threat posed by the latest crop of consoles, putting PC gaming in a tight spot where it needs to adapt to keep pace with the consoles."

    Consoles with AMD CPUs with their abysmal single-threaded performance? Alrighty then.

    "PCs still hold a massive lead in single-threaded CPU performance, but given the limits we’ve discussed earlier, too much bottlenecking can lead to the PC being the slower platform despite the significant hardware advantage."

    Perhaps you could point to a game that is faster on consoles than PC. What's that, you can't, because such a game doesn't and never will exist? Alrighty then.
  • MrSpadge - Monday, March 24, 2014 - link

    > Unfortunately, off-the-shelf game engines - particularly graphics - have remained steadfastly single-threaded, and that's not something DirectX or Mantle will be able to change.

    What's a game engine using in the end if not DirectX? Of course there's engine work prior to the DX draw calls.. but still, they're there and currently have no alternative. And they are becoming a bottleneck. Rest assured that developers have profiled their engines to see which calls cost most performance.

    > Nonsense. The current crop of consoles use x86-64 and DirectX 11-class hardware, programming games for them is virtually identical to programming games for (a slow) PC.

    Except that on the consoles you have access to those low-level APIs and are free to use them when ever the benefit justifies the extra development work.

    > Perhaps you could point to a game that is faster on consoles than PC. What's that, you can't, because such a game doesn't and never will exist?

    Of course you'd have to compare to approximately similar hardware. Which is difficult, but doable for e.g. the older XBox. What did it have, a Coppermine Celeron 800 MHz and approximately a Gefore 7800? It's going to be challenging to find PC configurations of this class performing as well as late games for that platform.
  • Gigaplex - Monday, March 24, 2014 - link

    "What's a game engine using in the end if not DirectX?"
    A lot of them support OpenGL and other platform specific APIs.
  • Lerianis - Monday, March 31, 2014 - link

    Many graphics cards still support OpenGL because it was a popular API. Personally, I agree with the first poster: The problem is that multi-threaded games are almost unheard of today. Sure, the games do a TOKEN amount of multi-threading (i.e. putting graphics on one thread and sound on another) but anything more than that they do not really do.

    So, in most games, having 4 cores is worthless or less important than having 2 cores at least is.
  • Alexvrb - Tuesday, March 25, 2014 - link

    The ORIGINAL Xbox? It had a 733 Mhz Coppermine PIII with half the L2 cache (but still 8-way so NOT a Celeron). So you were close there. But you're waaaay off on the GPU. It had a Geforce 3.5 (NV2A)! 7800 would be closer to what ended up in the next generation PS3.
  • mars777 - Monday, March 24, 2014 - link

    The latest Fifa :)
  • munim - Monday, March 24, 2014 - link

    I thought all games were faster on console than comparatively spec'ed computers. Is that not the case? Do you have any performance comparison tests off the top of your head?
  • B3an - Monday, March 24, 2014 - link

    It is the case and has always been the case. He's just an idiot. PC will always remain faster, but a slower PC with similar hardware to a console will run a game slower than the console version. This is a well known fact, but that console advantage is something that may disappear with DX12 (or atleast be reduced). This will give PC an even further lead in performance.
  • ninjaquick - Monday, March 24, 2014 - link

    Actually, that isn't a fact at all. Only very low-level, hyper optimized software will run better on consoles, and that is only because the software will generally fail to run at all on PC as the hardware it is made for is not present on the PC.
  • B3an - Monday, March 24, 2014 - link

    It is fact. Ryan knows this, devs know this, everyone with any understanding at all knows this. Developers have been asking for lower level access on PC forever because of this.

    Even ignoring the lower level API console advantage, games on console will already benefit from set hardware, the dev will always target that and get more performance out of it. Look at all the crappy PC ports that make poor use of the hardware. PC always runs games better anyway because of vastly superior hardware, but thats not the case on slower PC hardware thats similar in spec to a console - in that case the console always has the performance advantage there (and you need to remember the latest consoles use very PC-like hardware now so it's a lot easier to compare).

    As a PC gamer DX12 is great news, it will make better use of all my cores, and will give the platform even more of a performance advantage over consoles. It may even help lower the cost of entry-level gamings PC's.

Log in

Don't have an account? Sign up now