GeForce GTX 1060 FCAT Frametime Analysis Review - So How Does This Work?

So How Does This Work Again?

Alright, a quick recap for you to get a grasp of what we are doing. We have our traditional game PC with the dedicated graphics card installed. We start up a game or benchmark sequence. The game is rendered, passes several stages and then frames rendered are ready and served towards the monitor. It is precisely at that stage where we make a bypass. The DVI-DL monitor output cable we connect to a Dual Link DVI Distribution Amplifier (or high resolution capable DVI switch). We connect our graphics card to the input of the switch. Now the switch will clone the signal to two outputs on that switch. One output we connect the monitor to but the second output we connect to a framegrabber AKA Video Capture Card. Ours is a Single Channel 4 lane PCI Express bus with maximum data rate of 650 MB/sec and support for a maximum canvas of 4kx4k HD video (we wanted to be a little future proof) capture for all progressive and interlaced DVI/HDMI modes. This card is 1,500 EUR alone. We are not there yet though as we need to place the framegrabber into a PC of course. Fast is good, so we are using a Z77 motherboard with a Core i7 3770K processor. The encoding process is managed by the processor on the framegrabber in real-time too, if I/O is managed fast enough, we'll have less than 10% CPU utilization while capturing 2560x1440 @ 60 Hz streams in real-time.

Are We There Yet?

Nope, now we need to save the rendered frames in real-time, uncompressed as an AVI file. This poses a challenge in itself:

• Capturing at 1920x1080 @ 60 Hz in real-time shows IO writes of roughly 200~250 MB/s.
• Capturing at 2560x1440 @ 60 Hz in real-time shows IO writes of roughly 400~475 MB/s.

Look at the screenshot below, at data rate. The first time I noticed that, yes, I cursed and nearly vomited!

In the example above you can see that each second we are recording a sustained 429 MB per second. So 30 seconds of recording for analysis results in an AVI file of 12.6 GB. For that to happen we need storage volume and fast storage IO alright. A single SSD will not cut it. While doing all this high-end capturing we see a low CPU overhead of less than 10%. Why am I so keen on low CPU utilization you might ask? Because this is precise measuring and analyzing. We want to prevent accidentally recording dropped frames at all times. We've shown you all the hardware we use, but on the software side things are even more complex. To be able to pull this off, we need to spend a lot of time and money alright.