Star Swarm & The Test

For today’s DirectX 12 preview, Microsoft and Oxide Games have supplied us with a newer version of Oxide’s Star Swarm demo. Originally released in early 2014 as a demonstration of Oxide’s Nitrous engine and the capabilities of Mantle, Star Swarm is a massive space combat demo that is designed to push the limits of high-level APIs and demonstrate the performance advantages of low-level APIs. Due to its use of thousands of units and other effects that generate a high number of draw calls, Star Swarm can push over 100K draw calls, a massive workload that causes high-level APIs to simply crumple.

Because Star Swarm generates so many draw calls, it is essentially a best-case scenario test for low-level APIs, exploiting the fact that high-level APIs can’t effectively spread out the draw call workload over several CPU threads. As a result the performance gains from DirectX 12 in Star Swarm are going to be much greater than most (if not all) video games, but none the less it’s an effective tool to demonstrate the performance capabilities of DirectX 12 and to showcase how it is capable of better distributing work over multiple CPU threads.

It should be noted that while Star Swarm itself is a synthetic benchmark, the underlying Nitrous engine is relevant and is being used in multiple upcoming games. Stardock is using the Nitrous engine for their forthcoming Star Control game, and Oxide is using the engine for their own game, set to be announced at GDC 2015. So although Star Swarm is still a best case scenario, many of its lessons will be applicable to these future games.

As for the benchmark itself, we should also note that Star Swarm is a non-deterministic simulation. The benchmark is based on having two AI fleets fight each other, and as a result the outcome can differ from run to run. The good news is that although it’s not a deterministic benchmark, the benchmark’s RTS mode is reliable enough to keep the run-to-run variation low enough to produce reasonably consistent results. Among individual runs we’ll still see some fluctuations, while the benchmark will reliably demonstrate larger performance trends.


Star Swarm RTS Mode

The Test

For today’s preview Microsoft, NVIDIA, and AMD have provided us with the necessary WDDM 2.0 drivers to enable DirectX 12 under Windows 10. The NVIDIA driver is 349.56 and the AMD driver is 15.200. At this time we do not know when these early WDDM 2.0 drivers will be released to the public, though we would be surprised not to see them released by the time of GDC in early March.

In terms of bugs and other known issues, Microsoft has informed us that there are some known memory and performance regressions in the current WDDM 2.0 path that have since been fixed in interim builds of Windows. In particular the WDDM 2.0 path may see slightly lower performance than the WDDM 1.3 path for older drivers, and there is an issue with memory exhaustion. For this reason Microsoft has suggested that a 3GB card is required to use the Star Swarm DirectX 12 binary, although in our tests we have been able to run it on 2GB cards seemingly without issue. Meanwhile DirectX 11 deferred context support is currently broken in the combination of Star Swarm and NVIDIA's drivers, causing Star Swarm to immediately crash, so these results are with D3D 11 deferred contexts disabled.

For today’s article we are looking at a small range of cards from both AMD and NVIDIA to showcase both performance and compatibility. For NVIDIA we are looking at the GTX 980 (Maxwell 2), GTX 750 Ti (Maxwell 1), and GTX 680 (Kepler). For AMD we are looking at the R9 290X (GCN 1.1), R9 285 (GCN 1.2), and R9 260X (GCN 1.1). As we mentioned earlier support for Fermi and GCN 1.0 cards will be forthcoming in future drivers.

Meanwhile on the CPU front, to showcase the performance scaling of Direct3D we are running the bulk of our tests on our GPU testbed with 3 different settings to roughly emulate high-end Core i7 (6 cores), i5 (4 cores), and i3 (2 cores) processors. Unfortunately we cannot control for our 4960X’s L3 cache size, however that should not be a significant factor in these benchmarks.

DirectX 12 Preview CPU Configurations (i7-4960X)
Configuration Emulating
6C/12T @ 4.2GHz Overclocked Core i7
4C/4T @ 3.8GHz Core i5-4670K
2C/4T @ 3.8GHz Core i3-4370

Though not included in this preview, AMD’s recent APUs should slot between the 2 and 4 core options thanks to the design of AMD’s CPU modules.

CPU: Intel Core i7-4960X @ 4.2GHz
Motherboard: ASRock Fatal1ty X79 Professional
Power Supply: Corsair AX1200i
Hard Disk: Samsung SSD 840 EVO (750GB)
Memory: G.Skill RipjawZ DDR3-1866 4 x 8GB (9-10-9-26)
Case: NZXT Phantom 630 Windowed Edition
Monitor: Asus PQ321
Video Cards: AMD Radeon R9 290X
AMD Radeon R9 285
AMD Radeon R7 260X
NVIDIA GeForce GTX 980
NVIDIA GeForce GTX 750 Ti
NVIDIA GeForce GTX 680
Video Drivers: NVIDIA Release 349.56 Beta
AMD Catalyst 15.200 Beta
OS: Windows 10 Technical Preview 2 (Build 9926)

Finally, while we’re going to take a systematic look at DirectX 12 from both a CPU standpoint and a GPU standpoint, we may as well answer the first question on everyone’s mind: does DirectX 12 work as advertised? The short answer: a resounding yes.

Star Swarm GPU Scaling - Extreme Quality (4 Cores)

The Current State of DirectX 12 & WDDM 2.0 CPU Scaling
Comments Locked

245 Comments

View All Comments

  • tipoo - Friday, February 6, 2015 - link

    They'd still be relatively slower than the i3, but just higher in absolute terms relative to themselves.
  • Sivar - Friday, February 6, 2015 - link

    Has no one informed Microsoft?
    They will never actually release DirectX 12:
    http://tech.slashdot.org/story/13/04/12/1847250/am...
  • HighTech4US - Thursday, February 26, 2015 - link

    WOW, who would have thought that NEVER would only last 2 years.
  • jwcalla - Friday, February 6, 2015 - link

    So it took MS three years to catch up to OGL? I guess better late than never. ;-P
  • tipoo - Friday, February 6, 2015 - link

    Oh, so that's why the consortium is dropping OpenGL in favor of a from-the-ground-up API called GLNext? OpenGL hasn't been better than DX in many years. OpenGL holdouts like Carmack even said so themselves, that they only still use it because of inertia, but DX was better recently.
  • jwcalla - Friday, February 6, 2015 - link

    Yeah, whatever. BMDI has been available in OGL for years now and now DX is finally getting it.

    glNext will likely just be the AZDO stuff w/ a more developer-friendly API + some marketing hype.
  • tipoo - Friday, February 6, 2015 - link

    That's one feature. Total API performance was still not in OGLs favour.
  • jwcalla - Friday, February 6, 2015 - link

    Sure it was. Look at Valve's comparison in their L4D2 ports, and that's with OpenGL 2.x/3.x vs. D3D9.
  • nulian - Saturday, February 7, 2015 - link

    Which was vs DX9 and even valve said they could have improved DX 9 performance if they wanted to. DX 10+ is very different.
  • killeak - Sunday, February 8, 2015 - link

    As a developer that shipped all my games in both D3D and OpenGL (some also in OpenGL ES), I think OpenGL issues are fare more complex than a feature or two.

    What Khronos does with OpenGL it self is just defining the interface and its ideal behavior behind it. The issue is, the actual implementation is not done by Khronos but the IHVs in their drivers. Which means that every combination of OS + GPU + driver can behave different, and in practice this happens a lot!

    With D3D, you have one single implementation: The one done by MS in their OS. Sure, each Windows version has it's own implementation, and each GPU has different drivers, but the RunTime of D3D handles almost everything. Which in practice mean, that if the games run on a GPU in a particular version of Windows, it will run on every other GPU with that version of Windows (as long the GPU has the required features). It could happen that with advanced features and back doors/extensions this is not the rule, but that is an exception in the world of DX, in OpenGL is always like that.

    So, sure, I want OpenGL to be in parity feature wise with D3D (if is more advance better), but I am more worried about things like shader compilation, where you have hundred of different compilers in the market, since each GPU + OS + Drivers has its own. In PC is not that bad (is still bad), but on mobile is a disaster.

    Also it doesn't help that IHVs want to sell HW, not software, in fact they only make software (drivers) because they have to, is not their business, so they optimize their drivers for benchmarks and the like, but the actual implementation is never solid. In that regard, I am happy to see that the presentation of glNext at GDC, is done by developers and not IHVs.

    To be honest, I will be more pleased if Valve made their runtime for SteamOS, and Google for Android, and let the drivers do just the interface with the HW, nothing else. In the end, Apple does that for Macs (but is also true that they also control the HW). Maybe they could have, at least, something like the Windows WHQL in order to keep all implementation for their OS in line.

    And just as a note, I never shipped a game on Windows that runs better on OpenGL that on Direct3D, ever, even when I invested more time on the OpenGL implementation.

Log in

Don't have an account? Sign up now