DirectX 12: Single-GPU : FCAT latency performance

Frametime and latency performance

With a benchmark technology called FCAT on the following two pages, we will look into Frame Experience Analysis. Basically with the charts shown we are trying to show you graphics anomalies like stutters and glitches in a plotted chart. Lately there has been a new measurement introduced, latency measurements. Basically it is the opposite of FPS.

• FPS mostly measures performance, the number of frames rendered per passing second.
• Frametime AKA Frame Experience recordings mostly measures and exposes anomalies - here we look at how long it takes to render one frame. Measure that chronologically and you can see anomalies like peaks and dips in a plotted chart, indicating something could be off. 

We have a detailed article (read here) on the new FCAT methodology used, and it also explains why we do not use FRAPS anymore. Frametime - Basically the time it takes to render one frame can be monitored and tagged with a number, this is latency. One frame can take say 17 ms. Higher latency can indicate a slow framerate, and weird latency spikes indicate a stutter, jitter, twitches; basically anomalies that are visible on your monitor.

What Do These Measurements Show?

Basically, what these measurements show are anomalies like small glitches and stutters that you can sometimes (and please do read that well, sometimes) see on screen. Below I'd like to run through a couple of titles with you. Bear in mind that Average FPS matters more than frametime measurements. 

Frame Pacing / Frametime - Single GPU

FCAT then, FCAT is always definitive in the sense as to what you see on-screen compared to what numbers are crunched in the game engine. Above a plotted frame-time results of the test run @ 2560x1440 performed with a single Radeon R9 Fury (4GB) in 2560x1440.

Now who can tell me what that is ?

Correct see the frames bouncing into sync with that middle straight line at roughly 16~17ms ? Do the math with me: 1000/16,5  =  ~60 FPS. This pattern is 100% VSYNC. All Radeon cards (and yes seriously we tested ALL cards) render with VSYNC on. Now we contacted the Ashes devs about this one. Unfortunately it has become a rather sizable discussion with the developer who claims this to be a DX12 issue. Here's the thing, if your GPU is fast enough the numbers the benchmark produces exceed 60 FPS / 60 Hz. The game measures at the rendering port (and not the display end), then is post processed, passed to DX12 and the output rendered. So if at that stage your score can be like 92 FPS. However after that segment in the pipeline a lot of other stuff happens. In our case a 60Hz / FPS framerate . Where we measure with FCAT is definitive though, it's what your eyes will see and observe.  As stated we cannot turn this VSYNC like behaviour off, the feedback from Stardock is that Vsync on/off works differently in D3D12 then D3D11 due to changes in Windows, so they will not be apples to apples. In D3D12 you can only flip the backbuffer, not blit into like D3D11. Thus, you may not see the same type of screen tearing or present behavior that you will in D3D11.

"However, our tests do show D3D12 exceeding 60 fps which would not be possible with Vsync off." - Stardock

The claim from Stardock is right - but the final results from their benchmark are flawed for all Radeon cards. Internally at the 3D engine you might even be rendering 900 frames per second, but if at the end of the pipeline VSYNC remains to be enabled, 60 FPS (or something similar to your refresh rate) will be your upper limited and VSYNC itself will have an effect on the overall framerate as demonstrated in the FCAT above. With one and the same DX12 code-path behaviour then to be the same for both AMD and NVIDIA right ?:

Above a GeForce GTX 980 Ti in green at 2560x1440. This test run lasts roughly 30 seconds. As you can see the output renders properly with Nvidia graphics cards. This the measured frame latency is representative of what is actually rendered. Lower is better, we see a few stutters and three frame-drops. No massive spikes above 40ms, so overall that is a reasonably decent frame rendering experience.

Our concerns with the Radeon cards have been forwarded towards both Stardock and the AMD ISF team, it is under investigation but up-to this point the dialog remains silent and inadequate. On the next page some FCAT Multi GPU renderings.

Update: hours before the release of this article we got word back from AMD. They have confirmed what we are seeing. Radeon Software 16.1 / 16.2 does not support a DirectFlip in DX12, which is mandatory to solve to this specific situation/measurement. AMD intends to resolve this issue in a future driver update. Once that happens we'll revisit FCAT.