We’ve been following DirectX 12 for about 2 years now, watching Microsoft’s next-generation low-level graphics API go from an internal development project to a public release. Though harder to use than earlier high-level APIs like DirectX 11, DirectX 12 gives developers more control than ever before, and for those who can tame it, they can unlock performance and develop rendering techniques simply not possible with earlier APIs. Coupled with the CPU bottlenecks of DirectX 11 coming into full view as single-threaded performance increases have slowed and CPUs have increased their core counts instead, and DirectX 12 could not have come at a better time.

Although DirectX 12 was finalized and launched alongside Windows 10 last summer, we’ve continued to keep an eye on the API as the first games are developed against it. As developers need the tools before they can release games, there’s an expected lag period between the launch of Windows 10 and when games using the API are ready for release, and we are finally nearing the end of that lag period. Consequently we’re now getting a better and clearer picture of what to expect with games utilizing DirectX 12 as those games approach their launch.

There are a few games vying for the title of the first major DirectX 12 game, but at this point I think it’s safe to say that the first high profile game to be released will be Ashes of the Singularity. This is due to the fact that the developer, Oxide, has specifically crafted an engine and a game meant to exploit the abilities of the API – large numbers of draw calls, asynchronous compute/shading, and explicit multi-GPU – putting it a step beyond adding DX12 rendering paths to games that were originally designed for DX11. As a result, both the GPU vendors and Microsoft itself have used Ashes and earlier builds of its Nitrous engine to demonstrate the capabilities of the API, and this is something we’ve looked at with both Ashes and the Star Swarm technical demo.

Much like a number of other games these days, Ashes of the Singularity for its part has been in a public beta via Steam early access, while its full, golden release on March 22nd is fast approaching. To that end Oxide and publisher Stardock are gearing up to release the second major beta of the game, and the last beta before the game goes gold. At the same time they’ve invited the press to take a look at the beta and its updated benchmark ahead of tomorrow’s early access release, so today we’ll be taking a second and more comprehensive look at the game.

The first time we poked at Ashes was to investigate an early alpha of the game’s explicit multi-GPU functionality. Though only in a limited form at the time, Oxide demonstrated that they had a basic implementation of DX12 multi-GPU up and running, allowing us to not only pair up similar video cards, but dissimilar cards from opposing vendors, making a combined GeForce + Radeon setup a reality. This early version of Ashes showed a lot of promise for DX12 multi-GPU, and after some additional development it is now finally being released to the public as part of this week’s beta.

Since that release Oxide has also been at work both cleaning up the code to prepare it for release, and implementing even more DX12 functionality. The latest beta adds greatly improved support another one of DX12’s powerhouse features: asynchronous shading/computing. By taking advantage of DX12’s lower-level access, games and applications can directly interface with the various execution queues on a GPU, scheduling work on each queue and having it executed independently. Async shading is another one of DX12’s optimization features, allowing for certain tasks to be completed in less time (lower throughput latency) and/or to better utilize all of a GPU’s massive arrays of shader ALUs.

Between its new functionality, updated graphical effects, and a significant amount of optimization work since the last beta, the latest beta for Ashes gives us quite a bit to take a look at today, so let’s get started.

More on Async Shading, the New Benchmark, & the Test
POST A COMMENT

153 Comments

View All Comments

  • BurntMyBacon - Thursday, February 25, 2016 - link

    @anubis44: "nVidia wasn't expecting AMD to force Microsoft's hand and release DX12 so soon."

    I do believe you are correct. Given the lack of ability to throw driver optimizations at the DX12 code path and nVidia's proficiency at doing it, I'd say this will be quite damaging. They've lost one clear advantage they held (at least in DX11).

    @anubis44: "It's beginning to look like nVidia's been check-mated by AMD here."

    I wouldn't go that far. They probably won't have the necessary hardware in Pascal, but you can be sure Volta will have what it needs. Besides, most games will likely have a DX11 code path for the foreseeable future as developers wouldn't want to lock themselves out of an entire market. Also, at the moment, nVidia can still play DX12 fine, they just don't appear to have the advantage at the moment given the small sample set of available data points.

    In conclusion, it is more like they have lost a rook or queen. Of course, they've taken a few of ATi's pieces as well, so lets just wait and see who plays their remaining pieces better.
    Reply
  • rhysiam - Thursday, February 25, 2016 - link

    The other thing I would add to this is that it's not like Nvidia have nowhere to go here. Take the GTX 970 vs the R9 390 for example... they're in a similar price & performance tier. Yet the 970 is smaller with fewer transistors (usually meaning it's cheaper to produce) and generally has a much higher overclocking headroom (because Nvidia wasn't under pressure to clock the card closer to the limit to reach relevant performance). So it's reasonable to expect Nvidia could both lower the price and clock it higher to get a significantly better value card with minimal basically no substantive engineering/architectural changes.

    I'm not suggesting Nvidia will do that with the 970 specifically. Rather, what I'm saying is that if they find Pascal is similarly behind AMD they've got plenty of room to tweak performance and price before we can start calling them "check-mated". But it's certainly good new for us if DX12 performance like this continues and AMD essentially forces Nvidia to lower its margin.
    Reply
  • CiccioB - Sunday, February 28, 2016 - link

    They can do exactly as AMD has done with GCN: they just can start using 30 or 50% bigger GPUs to close the performance gap if they really need to. Reply
  • The_Countess - Thursday, February 25, 2016 - link

    nvidia's entire performance advantage in DX11 is based on game specific driver optimizations. they have a virtual army of developers slaving away on those (and coming up with way to hurt everyone's performance as long as it hurt AMD the most or makes their own latest gen cards look better... but that's a different matter)

    with DX12 however the drivers becomes MUCH thinner and doesn't have nearly as much influence. so basically nvidia's main competitive advantage is gone with dx12 and vulkan.

    as for being relevant: this year pretty much every game where performance matters will have either a DX12 or Vulkan render option. adding in the fact that AMD cards generally age better then nvidia's (those game specific optimizations focus pretty much exclusively only on their latest generation of cards) and i would say that yes it is very relevant.
    Reply
  • BurntMyBacon - Thursday, February 25, 2016 - link

    @The_Countess: "nvidia's entire performance advantage in DX11 is based on game specific driver optimizations. they have a virtual army of developers slaving away on those ..."

    True, they have lost a large advantage. Keep in mind, though, that nVidia's developer relations are still in play. What they once achieved through the use of driver optimizations may still be accomplished through code path optimization and design guidance for nVidia architecture. The first beta for Vulkan (The Talos Principle) showed that merely replacing a high level API (OpenGL/DX11) with a low level one (Vulkan/DX12) does not automatically improve the experience. If nVidia can convince developers to avoid certain non-optimal features or program in such a way as to take better advantage of nVidia hardware in their titles (for the sake of performance on the majority of discrete card owners out there of course) then ATi will be in the same position as they are now. Better hardware, worse software support. Then again, low level API cross-platform titles will most assuredly program to take advantage of the console architectures which happens to be ATi's at the moment.
    Reply
  • nevcairiel - Wednesday, February 24, 2016 - link

    Considering the Fury X just has a tad bit more raw power than a (older) 980Ti, I would say the DX12 numbers are fine, and what is really showing is AMDs lack of performance in DX11? Reply
  • tuxRoller - Wednesday, February 24, 2016 - link

    I don't agree with this. I think this is more a case of nvidia not being able to rely so much on the ENORMOUS number of special cases in their driver.
    IOW, this is about two things: hardware and game design. The drivers are trivial next to d3d11/ogl.
    Reply
  • jasonelmore - Wednesday, February 24, 2016 - link

    Fury X's Architecture is much newer than Maxwell 2's. Lets see what the true DX12 cards can do this summer. Reply
  • tuxRoller - Wednesday, February 24, 2016 - link

    Did you not notice the across the board improvements for all gcn cards?
    The point I was making, and that others have made for sometime, is that AMD makes really good hardware but this is typically masked by poor drivers.
    You can see this by looking at their excellent performance in compute workloads where the code in the driver is more recent and doesn't have the legacy cruft of their d3d/ogl code.
    Reply
  • Despoiler - Thursday, February 25, 2016 - link

    It's not their drivers. It's purely architectural. GCN moved their schedulers into to hardware. GCN requires the API to be able to feed it enough work. What people have been calling "driver overhead" is nothing of the sort. DX11 is just not capable of fully utilizing AMD hardware. DX12 is and that is why AMD created Mantle. It forced MS to create DX12 and that set off the creation of Vulkan. All of the next gen APIs are tailored to exploit AMDs already being sold hardware. Reply

Log in

Don't have an account? Sign up now