Once we have setup all the hardware we can install the framegrabber. With supported software we can now tap in on the framegrabber capture pin and record the frames fired at us from that Game PC. We can now record a game sequence / timedemo.
Recording An AVI & Then What?
Good question, we have the ability to grab and thus record all frames fired at the framegrabber PC. We record them in an AVI file. But that alone is not enough as how are you going to analyze data from an AVI file? So here science starts. We leave the framegrabber PC to rest for a minute and go back towards the Game PC that is rendering our game, benchmark or whatever.
On the game PC we have installed a small overlay utility with extremely low CPU overhead. Here's what it is doing, each frame that the GPU is rendering will get one of 16 colored bar assigned, as examples:
Frame 1 gets a Yellow colored bar to the left.
Frame 2 gets a Green colored bar to the left.
Frame 3 gets a Red colored bar to the left.
Frame 4 gets a Purple colored bar to the left.
Frame 5 gets a Blue colored bar to the left.
And so on
And so on... so each rendered frame will have a color tag, that's simple enough to understand right ? And sure, obviously the overlay and the methodology behind it is far more complicated, but we'll keep it simple okay? So we activate the overlay and run our game sequence on the Game PC.
Now we go back to the frame grabber PC and record our game play slash frag fest. Freeware tools FTW, VirtualDub is used to capture content. So the output of the Game PC including the color tags per frame from the overlay application is now recorded and saved on our nice and fast storage solution.
Once we look at the AVI file, we can indeed see that with the recorded frames we pass have colored tags on the left side of the frame. Now we need to extrapolate the data. An extractor tool will play back the video, analyzing the overlay colors to determine how the game frames were delivered to the screen during the capture. That data derived from this will be saved into an Excel file (.XLS), and can then be used with FCAT Perl scripts to generate the stats and charts.
But that is still not enough as we need to process the created data. So here's where I'll simplify the explanation a little bit. We now fire off a perl script at the XLS file we just created with the analysis tool. The Perl scrip will analyze the data, each frame has a certain latency, each frame has a certain color and that way it can differentiate and distinguish frames and thus values from each other. It will output the data in an XML file. And once data is in an XML file, we can chart it.
We fire off a Perl script to make a nice chart out of the XML data and boom. We have output that represent the frame experience you guys see and observe on your monitor. Now I need to teach you guys how to interpret the charts. Next page please where we'll look at some examples of what we just recorded and then charted.
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 ...