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 startup 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 towards a Dual Link DVI Distribution Amplifier (or high resolution capable DVI switch). We connect out graphics card towards the input of the switch. Now the switch will clone the signal towards two outputs on that switch. One output we connect the monitor to but the second output we connect towards a framegrabber AKA Video Capture Card. Ours is a Single Channel 4 lane PCI Express bus with maximum data rate of 650MB/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 1500 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 Core i7 3770K processor. The encoding process is managed by the processor on the frame grabber in real-time too, if I/O is managed fast enough, we'll have less then 10% CPU utilization while capturing 2560x1440 @ 60Hz 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. Here's a challenge that poses 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 notice 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 resutls into an AVI file of 12.6 GB. For that to happen we need storage volume and fast storage IO alright. A single SSD wll certainly 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'll shown you all the hardware we used, 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.
An Introduction to HBM - High Bandwidth Memory AMD briefed selected press on HBM - High Bandwidth Memory. This new type of graphics memory is going to change the para dime in the graphics industry when we are talking about using less power, small...
An introduction to FCAT benchmarking In this article we will introduce you towards FCAT benchmarking. The past couple of months we have seen a some new dynamics in measuring the framerate of your games. Basically the framerate of your ...