Frame Time Consistency & Recordings

Last, but not least, we wanted to also look at frame time consistency across Star Swarm, our two vendors, and the various APIs available to them. Next to CPU efficiency gains, one of the other touted benefits of low-level APIs like DirectX 12 is the ability for developers to better control frame time pacing due to the fact that the API and driver are doing fewer things under the hood and behind an application’s back. Inefficient memory management operations, resource allocation, and shader compiling in particular can result in unexpected and undesirable momentary drops in performance. However, while low-level APIs can improve on this aspect, it doesn’t necessarily mean high-level APIs are bad at it. So it is an important distinction between bad/good and good/better.

On a technical note, these frame times are measured within (and logged by) Star Swarm itself. So these are not “FCAT” results that are measuring the end of the pipeline, nor is that possible right now due to the lack of an overlay option for DirectX 12.

Starting with the GTX 980, we can immediately see why we can’t always write-off high-level APIs. Benchmark non-determinism aside, both DirectX 11 and DirectX 12 produce consistent frame times; one is just much, much faster than the other. Both on paper and subjectively in practice, Star Swarm has little trouble maintaining consistent frame times on the GTX 980. Even if DirectX 11 is slow, it is at least consistent.

The story is much the same for the R9 290X. DirectX 11 and DirectX 12 both produce consistent results, with neither API experiencing frame time swings. Meanwhile Mantle falls into the same category as DirectX 12, producing similarly consistent performance and frame times.

Ultimately it’s clear from these results that if DirectX 12 is going to lead to any major differences in frame time consistency, Star Swarm is not the best showcase for it. With DirectX 11 already producing consistent results, DirectX 12 has little to improve on.

Finally, along with our frame time consistency graphs, we have also recorded videos of shorter run-throughs on both the GeForce GTX 980 and Radeon R9 290X. With YouTube now supporting 60fps, these videos are frame-accurate representations of what we see when we run the Star Swarm benchmark, showing first-hand the overall frame time consistency among all configurations, and of course the massive difference in performance.

Mid Quality Performance First Thoughts
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