The Changing State of Game Development

The entry of Microsoft and Direct3D into this world stands to significantly change the status quo, due to the fact that Direct3D is by far the most widely used PC graphics API. As the maintainer of Direct3D Microsoft gets to set the pace in the PC graphics industry in several ways, so while Direct3D 12 won’t be the first modern low level graphics API, there’s little question after this announcement that it’s going to have the widest impact on game developers.

Perhaps the biggest reason for this is because of the fact that like every version of Direct3D before it, Direct3D 12 is going to be a cross-vendor standard that works on multiple GPUs. Though I don’t think it’s wise to treat Mantle and Direct3D as competitors at this point, the fact that this is a cross-vendor standard and not an AMD standard means that using it targets every video card and not just AMD video cards. So for all of the impact Mantle has had over the past 6 months, and will continue to have over the coming years, the fact that we’re to a point where there’s a cross-vendor standard will be a significant milestone.

That said, whenever we talk about low level programming it’s good to also recall who this model is and isn’t for. The purpose of abstraction is not only to provide wider hardware compatibility, but to outright hide certain types of execution ugliness from programmers. The reduction in abstraction will bring with it a reduction in the amount of this ugliness that gets hidden, and as a result the amount of knowledge needed to efficiently program at a low level goes up. Low level programing should not require a code wizard, but it’s unquestionably harder than straightforward (no optimization tricks) Direct3D 11.

Which is why the launch of Direct3D 12 is poised to increase the number of options available to graphics programmers, but not replace the high level programming model entirely. The development teams best suited for taking advantage of Direct3D 12 will be the well-funded AAA game studios, particularly those doing multi-platform titles across PCs and consoles. If you’re already doing low level programming for Xbox One and Playstation 4 – and more importantly have the staff and institutional knowledge for such an endeavor – then Direct3D 12 is but a small step, mostly one of learning the syntax of the new API. But for smaller game developers that aren’t able to put together large, experienced game development teams, then a need for a high level programming API will remain. Microsoft has not talked about high level programming within the context of Direct3D 12 thus far, but one way or another – be it Direct3D 11 or a high level friendly Direct3D 12 – high level programming will be here to stay.

Though when it comes to development, the role of middleware cannot be ignored. AMD and NVIDIA already target middleware developers for integration of their proprietary technologies, and the same concept applies on a larger scale when we’re talking about making low level programming accessible to more developers. Furthermore with the massive change in middleware licensing terms we’re seeing with this generation – Unreal Engine 4 for example is just 5% of gross revenues for smaller developers that can’t negotiate otherwise – powerful middleware is increasingly accessible to all categories of developers. So even if smaller developers can’t internally develop their own Direct3D 12 code, they will have the ability to target it by inheriting the capabilities through the middleware they use.

Consoles & Mobile Devices Too

The introduction of Direct3D 12 stands to not only change the nature of graphics development for Windows, but on other Microsoft platforms too. With Microsoft’s consumer arm having their hand in everything from phones to consoles, Microsoft is seeking to extend Direct3D 12 and its benefits to these platforms too.

Specifically, Microsoft is already committing to bringing Direct3D 12 to the Xbox One, their current-generation console. Powered by an AMD SoC whose GPU in turn is based on GCN 1.1, the Xbox One is functionally an x86 PC with a modern AMD GPU, so the fact that this is even technically possible is not a surprise. But what does come as a surprise is that the Direct3D12 API is different enough that this is even necessary.

The Xbox One, as you may recall, uses Microsoft’s Direct3D 11.X API. This details of this API are scarce as they’re only open to registered Xbox One developers, but fundamentally it’s said to be a variant of Direct3D 11 with a number of Xbox One additions, including low level API features that would be suitable for programming a console. Having the Xbox One be in alignment with Direct3D 12 is going to be a good thing regardless – it will make porting between the platforms easier – but the fact that Direct3D 12 will bring any kind of meaningful improvement to the Xbox One is unexpected. Without more details on the Xbox One API it’s impossible to say with any certainty what exact functionality isn’t currently available in Direct3D 11.X or what kind of performance benefit this would bring the Xbox One, but it stands to reason that unless most Xbox One programmers have been doing high level programming, the gains won’t be as great as for the PC.

Moving on, we have the fact that Microsoft will also be bringing Direct3D 12 to handheld devices. We’re presumably talking about Windows RT tablets and Windows Phone phones, extending Direct3D 12 to the bottom as well as it goes to the top on the PC. Handheld devices stand to gain just as much from this as PCs and consoles do, due to the fact that handheld devices are even more CPU-bottlenecked than PC laptops and desktops, so a low level API is as much a natural development for these platforms as it is the PC.

The question on our end is what kind of impact this will have on the Direct3D 12 standard with respect to abstraction. SoC-class GPUs are typically years behind PC GPUs in functionality (never mind performance), and at least among current GPUs wildly differ from each other in ways the PC GPU market hasn’t seen in years. So while extending Direct3D 12 to cover multiple PC GPUs should be relatively easy, having to support SoC GPUs certainly muddles the picture. This may mean Microsoft is looking at the long view here, when SoCs such as the Tegra K1 come along with feature sets that match recent PC architectures, coupled with the fact that Windows RT/Phone has not traditionally supported a large number of SoC GPU architectures. In which case only having to cover a handful of SoC GPU architectures instead of all 7 would certainly be an easier task.

Direct3D 12 In Depth Demos & First Thoughts
Comments Locked

105 Comments

View All Comments

  • ninjaquick - Tuesday, March 25, 2014 - link

    And the second look will wind up the same way. Indipendents who can starve a little longer will probably make sure to release on the Steam Machines, but larger developers, with larger codebases and way more stuff on their minds can't just jump ship without spending way too much time on re-engineering much of their code.
  • martixy - Monday, March 24, 2014 - link

    I see a bright future for the gaming industry...
    On that note, does anyone happen to have a time machine? Or a ship that goes really really fast?
  • Rezurecta - Monday, March 24, 2014 - link

    What piqued my interest is the fact that even MS uses Chrome. ;)

    Seriously though, posted the same on Overclock.net. Given the expected time to launch, it seems that this was only thought about because of AMD and Mantle. It is a shame that AMD paved the way and may not be a vastly supported API.

    Hopefully, Nvidia and Intel accept AMD's open offer to join Mantle and we can put the control in the IHV's instead of the OS maker.
  • errorr - Monday, March 24, 2014 - link

    MS has a lot of work to do if they want to be relevant for mobile. OpenGL ES has been largely optimized for tile-based solutions and takes into account the numerous benefits and flaws compared to desktop GPUs. Just about everything in the mobile space is created to limit memory access which is slow, narrow, and power intensive. The entire paradigm is completely different. Adreno is also VLIW which means any low-level api stuff is bound to be very hard to implement. At least it will work on Nvidia chips I guess but that is still only 10% of the market at best.
  • errorr - Monday, March 24, 2014 - link

    On another note, there was some desire to get some better understanding on mobile GPU chips in the powerVR article and the ARM Mali blog at least did the math on publicly available statements and outlined the capabilities of each "shader core".

    Each Mali has 1-16 shader cores (4-8 usu.). Each shader core has 1-4 Arithmetic pipes (SIMD). Each pipe has 128-bit quad-word registers. The registers can be flexibly accessed as either 2 x FP64, 4 x FP32, 8 x FP16, 2 x int64, 4 x int32, 8 x int16, or 16 x int8. There is a speed penalty for FP64 and a speed bump for FP16 etc. from the 17 FP32 FLOPS per pipeline per clock. So at max with 16 shader cores with 4 pipes per core @ 600mhz that gives a theoretical compute of 652 FP32 GFLOPS. Although it seems like a 16/2 design (T-760) will do 326 FP32 GFLOPS as the more likely.
    There is also a load/store pipeline and a texture pipeline (1 textel per clock or 1/2 textel w/ trilinear filtering)

    Wasn't sure where to put this but they have been sharing/implying a bunch of info on their cores publicly for a while.
  • lightyears - Monday, March 24, 2014 - link

    Please give your opinion about following question:
    What about notebooks with nVidia Optimus? I have a notebook with a GTX680M dedicated graphics combined with Ivy Bridge integrated graphics. So the 680M will support DirectX12, but the Ivy Bridge dedicated probably wont.
    Unfortunately those two are connected by nVidia Optimus technology. A technology that it seems is impossible to put off. I looked already in my usual BIOS but I cant get rid of it. Whether I like it or not I am forced to have Optimus.

    So will Optimus automatically select the 680M for DX12 applications automatically?

    Or wont it work at all. And wont the game be installed because my stupid integrated graphics card doesnt support it?

    The last option would be a true shame and I would really be frsutrated. Given that I spend a lot of money on a high end notebook. And I paid a lot to have a heavy (DX12 capable) 680M in it. And I still wont be able to do DX12 altough I have a DX12 capable card...
  • Ryan Smith - Tuesday, March 25, 2014 - link

    "What about notebooks with nVidia Optimus?"

    There is no reason that I'm aware of that this shouldn't work on Optimus. The Optimus shim should redirect any flagged game to the dGPU, where it will detect a D3D12 capable device and be able to use that API.
  • ninjaquick - Tuesday, March 25, 2014 - link

    Awesome use of the word shim.
  • lightyears - Tuesday, March 25, 2014 - link

    I looked at the internet and it looks like it wont be a real problem indeed. Back in 2011 the same situation existed with DX11. Some Optimus notebooks had Sandy Bridge CPU (DX 10.1 capacle) and GTX 555 (DX 11 capable). By some people the Optimus didnt automatically detect the DX 11 capable device and they had some problem,. But after some changes in the settings they managed to get DX 11 going with the GTX 555 on the Optimus notebooks.Altough the Sandy Bridge was not DX 11 capable.
    So I suppose Optimus also wont be a problem this time with DX12. Good news.
    Altough I truely hate Optimus. It already forbid me to use stereoscopic 3D on a supported 3DTV.
  • ericore - Monday, March 24, 2014 - link

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

    That's absolute BS.
    The reason is 3 fold: 1. For Xbox One 2. To prevent surge of Linux Gaming 3. To fulfill alliance/pack with Intel and Nvidia

Log in

Don't have an account? Sign up now