In a somewhat unusual technical/promotional blog entry called “Raising the Bar with Direct3D”, Microsoft has released some additional details on the version of Direct3D for Xbox One, along with providing a general summary of the state of Direct3D 11.2.

First and foremost, for the Xbox One we finally have an official name for the consoles version of Direct3D along with some confirmation of some general details about the API. The Xbox One’s version of the API is being called Direct3D 11.x – X as in Xbox, not an algebraic X – and as expected it’s a superset of Direct3D 11.2. Microsoft doesn’t go into further detail on what else that superset contains, but traditionally we’d expect to see further API calls that are specifically designed to take advantage of the underlying APU, including of course the low-level programming constructs to do close to metal programming and fully exploit quirks such as the console’s 32MB of eSRAM.

Furthermore it’s interesting to note that Microsoft also took the time to specifically mention API overhead in a high-level context, and that they’ve been doing a lot of work to chip away at said overhead for the Xbox One. This is fairly similar to how Microsoft is said to have approached Direct3D for the 360, being able to exploit the fixed platform to remove some of the overhead from abstraction while maintaining the functionality of the high level API functions.

Moving on to Direct3D 11.2 in general, the next section of the blog is primarily a summarization of the Direct3D 11.2 feature set, with Microsoft primarily reiterating support for tiled resources (the headline feature for 11.2) along with briefly mentioning other features such as pre-compiled headers and CPU/GPU memory sharing improvements. Unlike Direct3D 11.1 and Windows 8, 11.2 is coming with a Windows point update, so it’s a similarly smaller addition to Direct3D.

However it’s the final section of Microsoft’s blog that may be the most interesting, although it’s also the least detailed. In discussing the future of Direct3D, Microsoft specifically mentions their general commitments to improving Direct3D alongside “bringing the lightweight runtime and tooling capabilities of the Xbox One Direct3D implementation to Windows,” though providing no details on how they intend to accomplish the latter. Assuming Microsoft intends to keep up a yearly(ish) development cadence for Windows, this may be something we see as soon as next year. There’s certainly quite a bit of interest in cutting down on the CPU overhead in graphics APIs, due in part to declining improvements in single-threaded CPU performance gains, so this is something that’s going to be worth keeping an eye on.

Finally, in an unexpected move, Microsoft also used the blog to quickly address the subject of AMD’s Mantle API, specifically saying that the Xbox One doesn’t support it nor OpenGL. The fact that Mantle isn’t supported comes as no surprise – Xbox One already has its own low level constructs versus the still in development Mantle – but we weren’t expecting Microsoft to comment on the matter since they aren’t involved in the development of Mantle. Though this unfortunately doesn’t shed any further light on the big question of just what Mantle adopts from the low-level programming constructs in Direct3D 11.x.

Source: Microsoft Windows Blog

POST A COMMENT

36 Comments

View All Comments

  • BMNify - Wednesday, October 16, 2013 - link

    Those who claim wild things need to prove their claims not disprove you idioit, That Direct3D blogpost has soundly smashed the theory that xbox low-level API and Mantle are same or similar, this was just a wild assumption which has become a laughing fodder for normal people with brain whereas creatures like you who possess Pea-sized brain are still supporting this stupid theory. Reply
  • HunterKlynn - Friday, October 18, 2013 - link

    Big man with his big ad hominem. Reply
  • chizow - Tuesday, October 15, 2013 - link

    Thanks for covering the most interesting bits of the blog post Ryan. If anything, I think all the talk of Mantle and especially SteamOS has lit a fire under Microsoft's proverbial ass to improve DX on the PC. I'm really looking forward to the optimizations they can bring from the XB1's version of DX to the PC version.

    Any guesses on how they will do that? Looking on the OpenGL side of things, Valve and Nvidia have been boasting about vendor specific optimizations and OpenGL extensions that expose additional hardware functionality, like bindless graphics, that offer tremendous speed-ups over DX. Do you think it's possible MS incorporates vendor-specific optimizations in DX for the PC going forward?
    Reply
  • jwcalla - Wednesday, October 16, 2013 - link

    Even if MS makes improvements to D3D, will they make them available in Windows 7? A huge chunk of PC gamers are still on Windows 7, and game developers would be forced to target the common denominator. This is another major reason why the industry needs to move over to OpenGL. Having a dependency on a single company with its own narrow motives is insane. Reply
  • chizow - Wednesday, October 16, 2013 - link

    I agree Microsoft's position to force upgrade to Win8 for DX11.1/2 optimizations has been frustrating. But I think the hope, with these revelations about increased DX development on Windows, is that Microsoft will relent from this position and also push these upgrades down to Win7. I think they view the SteamOS/OpenGL threat to Windows/DX as very real on the PC, what better way to disrupt that momentum and prevent widespread adoption than to offer similar performance improvements/optimizations on all existing DX11 platforms? Last I checked, I believe Win7 held an astounding 90% share of Steam survey machines.

    http://store.steampowered.com/hwsurvey/

    I agree with the concerns about a single company holding sway over an entire platform, but I also think in the big picture, a single API/OS for the PC platform is still the better way to go to keep it in a strong position against the console competition. Stratification with multiple platforms, APIs, low-level vendor specific APIs is a bad way to go imo. It reminds me far too much of the early days of PC gaming when you had serious issues with different PC platforms: PC/IBM compatible, Mac, and Amiga.
    Reply
  • Haider - Tuesday, October 15, 2013 - link

    Hmmm like Java and Perl? Pretty similar code... Reply

Log in

Don't have an account? Sign up now