Originally Posted by SKYMTL
The reasoning behind it is straightforward:
- FRAPS tells a PART of the story. Not all of it. Frame capture tells PART of the story. But not all of it. If I were you'd I'd read beyond the statements and actually see if these measurements actually have an impact upon the actual in-game EXPERIENCE. Some do, many don't.
- AMD is launching their HD 7990 in the next little while. The timing of these frame capture articles (which makes AMD solutions out to be worse then they actually are IMO) is perfect from a marketing standpoint.
- It is the experience which matters. Frame rates, frame times and everything in between is pointless unless an end-user can actually SEE a difference between two different solutions.
Sky your opinion about the 3d guru boss and his opinion about frame capturing?Warning: Spoiler! (Click to show)
Originally Posted by Hilbert Hagedoorn
Actually its on par with what I always have stated. See the reason we started so late with frametime measurements is that FRAPS measures at gametime. Therefore it's bound to miss some stuff but can also show stuff that you as an end user can not see. However it is indicative of issues at hand, just not 100% precise. Its the reason why I really didn't want to use it. But an indication is always better then nothing, and combined with the request from you guys I inserted frametime recording as of recent.
However with that in mind -- Here's what I have been working on and wrote down in blog style as part of a future article:
For a couple of weeks now I have been working on a method as exposed on another website, with a framegrabber.
On my testing 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 each frame rendered is 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 (basically high resolution capable DVI switch). We connect out graphics card towards the input. 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 was 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 prices is managed by the processor on the frame grabber in real-time, to if IO is managed fast enough we'll have less then 5% CPU utilization while capturing 2560x1440 @ 60Hz streams in real-time.
Now we need to save the rendered frames in real-time, uncompressed as an AVI file. Now here's the problem:
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.
Correct - That's ~450 MB each second continuesly (!)
The first time I notice that, yes I cursed and nearly vomited. At 2560x1440 The only way to tackle the real-time writes without clogging up system IO for the recording PC is to get multiple SATA3 SSDs setup in RAID Stripe mode. That will still create a CPU load somehow. So there is a more easy solution.
We contacted OCZ and asked them to send out the RevoDrive 3 X2. These PCie 4x based products have their own Hardware SSD and Raid controllers, thus lowering a lot of overhead for the PC. They can write sustained 500 MB/sec quite easily. And with 450 MB/sec writes (nearly a full GB for 2 seconds of recording, you'll need some storage volume space as well. So we got the 700 EUR 480 GB version. Which in theory will record 4-5 minutes before it's full.
But that's sufficient for our purposes. While doing all this high-end capturing we see a low CPU overhead of only 3-4%. 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. But yeah at this point we have spend like 3500 EUR alone on the frame grabber PC and a switch.
Once we have setup all the hardware we install the framegrabber. With supported software we can now tap in on the framegrabber and record the frames fired at us from that Game PC.
Recording an AVI and 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 date 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 is is doing, each frame that the GPU is rendering will get a colored bar assigned, example:
Frame 1 gets a Yellow colored bar top the left.
Frame 2 gets a Green colored bar top the left.
Frame 3 gets a Red colored bar top the left.
Frame 4 gets a Purple colored bar top the left.
Frame 5 gets a Blue colored bar top the left.
And so on ... so each rendered frame will have a color tag, that's simple enough to understand right ? Now we go back to the frame grabber PC and record our game play. The output of the Game PC including the color tags per frame from the overlay application is now recorded. Once we look at the AVI file, we can indeed see that with each frame that we pass we see a colored tag on the left side of the frame.
But that is still not enough right ? So here's where I'll simplify the explanation a little bit. We now fire off a perl script at the AVI. The Perl scrip will analyze the AVI file, 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 date in an XML file. And once data is in an XML file, we can chart it.
We fire off another 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.
So above just a quick part of that article. Unfortunately we are running into many issues software and hardware related. See if we want to catch frame experience / stutter issues then the above method is the only valid one. Unfortunately there is so much hardware and software involved that currently I see anomalies in the charts that should not be there. Even the RevoDrive 3 X2 is not fast enough as we see IO issues causing framedrops ... and that is the one thing that may not happen.
It will take a while (months) to get this refined. However I am fighting another problem, my work week is already 60+ hours, the methodology described above seriously EATS away time into tremendous numbers. So we're not sure how, if and when this new method will become effective. It would be a 2-3 page addition towards (on top of) our current reviews next to average framerates, for the sole reason to hunt down graphics anomalies.
Okay ... this post is too long ... but that said, we are working on a method that is accurate, measuring at DVI output is literally what you'll see on the monitor and thus on the charts. It's however complicated x10 and very time consuming.
Its worth all this money for frame capturing? Its 100% accurate?What kind of anomalies can create a io issue?Thank you