Let's see how these dual-card setups take on F1 2012, a game we consider to be platform-limited.

Interestingly, despite this title's reliance on processor and memory performance, we see the largest discrepancy between actual rendered frames (including drops and runts) and the practical output you'd actually experience, a 13.1 FPS delta. It's also interesting that Fraps reports results that come closer to AMD's practical output; in theory you'd think the opposite would be true.
Meanwhile, the GeForce boards don't have the large gap separating them, making this story the first time we've seen quantifiable evidence of Nvidia's effort to deliver consistent frames, rather than pushing frames as fast as they can be rendered.

Illustrating frame rates over time gives us a dramatic visualization of runt and dropped frames causing spikes during the benchmark run.

Regardless of those issues, frame time variance appears fairly modest, even at the 95th percentile.
- Frames Per Second: Why The World Was Wrong
- Multi-Card Graphics Problems, And A Solution: Nvidia's FCAT
- Test System And Benchmarks
- Results: Batman Arkham City
- Results: Borderlands 2
- Results: Crysis 3
- Results: F1 2012
- Results: Far Cry 3
- Results: Hitman Absolution
- Results: Metro 2033
- Results: Elder Scrolls V: Skyrim
- Results: Tomb Raider
- When Frame Rates Aren't What They Seem...
The problem i have with the hardware you picked for this reviews is that even though, RAW FPS are not the main idea behind the review, you are giving a Tool for every troll on the net to say AMD hardware or drivers are crap. The idea behind the review is good though.
FCAT isn't for end users, it's for review sites. The tech is supplied by hardware manufacturers, Nvidia just makes the scripts. They gave them to us for testing.
And actually, it'd be nice to see someone like Beepa incorporate the overlay functionality, taking Nvidia out of the equation.
FCAT isn't for end users, it's for review sites. The tech is supplied by hardware manufacturers, Nvidia just makes the scripts. They gave them to us for testing.
And actually, it'd be nice to see someone like Beepa incorporate the overlay functionality, taking Nvidia out of the equation.
The problem i have with the hardware you picked for this reviews is that even though, RAW FPS are not the main idea behind the review, you are giving a Tool for every troll on the net to say AMD hardware or drivers are crap. The idea behind the review is good though.
But as great as the review is, I feel one thing that review sites have dropped the ball on is the lack of v-sync comparisons. A lot of people play with v-sync, and while a 60hz monitor is going to limit what you can test, you could get a 120hz or 144hz monitor and see how they behave with v-sync on.
And the toughest thing of all, is how can microstutter be more accurately quantified. Not counting the runt frames gives a more accurate representation of FPS, but does not quantify microstutter that may be happening as a result.
It seems the more info we get, the more questions I have.
Yeah, that is a big part of why I'd like to see v-sync used in a review some time. It also removes tearing, and is the primary way I play; v-sync on a 120hz monitor.
Particularly after re-reading pp1-2, please clarify, runts [and drops] are not an issue in single-card setups?
The test is one that AMD wanted as well. Well, at least that is what they are saying now, because it tests the output, not the start of the rendering process. I'm not sure how this type of test could skew results, as it just takes the frames like a monitor does, and shows us what the monitor shows.
The part you could possibly quibble over is what quantifies a runt frame.
There was a interesting AMD-backed story the other day on AT (not that it matters too much, both AMD and Nvidia seem to not like FRAPS that much), AMD apparently uses stuff like GPUView from MS.
http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps
Intel's also got something called Graphics Performance Analyzers, which seems to be similar to GPUView.
http://software.intel.com/en-us/vcsource/tools/intel-gpa
What needs to be done with FPS/FRAPs/whatever is a practical tested and verifiable standard needs to be created which accurately portrays the playable experience. sorta a meta rating which incorporates all these sub criteria into a number... which will let us know how silky smooth the play experience will be with a gaming title.
of course, there is the added issue with an nvidia program being used to measure an AMD part... with the way intel used to (or might still according to some people) influence certain benching programs it's beyond problematic, especially with the way NVidia has played in the past with certain competition, to use a software program made by one of the competitors. if their methodology has value, it should be re-engineered to insure impartiality, and to prevent the obvious and expected fanboy mistrust.
That said I agree with the author's general point... this is an exciting time to be an enthusiasts.
I read an article on Techreport recently that explained another big component to choppy game play is time syncing. One that no review site has ever tried to tackle. It is one thing to have evenly spaced frames, but what if those frames are not synced to the action? That would have more unsettling results.
1. No FRAPS for Nvidia? How do we know FRAPS isn't causing an issue there?
2. The Minimum FPS for the FRAPS measurement is actually lower than the hardware and practical. What's going on there, if FRAPS counts present() calls, then shouldn't it be more than the hardware FPS at the very least (unless i'm missing something, i think it should be the same at least).
No tearing on 120Hz monitors until you get over 120fps and even then tearing is no longer perceivable until you hit the mid 400s.
Also, that is not the point of the article.
This is a great article. It's consistent with others I've read on the subject. It is consistent to what is being published regarding information AMD is also supporting.
I look forward to seeing what you do with the tweaks of the FCAT software to further define what equates to a "runt" frame. Seems like that could make an even greater difference. Defining a runt frame seems somewhat subjective. Seems like many more than 21 scan lines or less could define a runt and would seem dependent on the resolution somewhat?
You can get screen tearing regardless of what FPS you have. You might get it even at 40FPS and you might not get it at 200FPS. Just because you're over 60FPS doesn't necessarily mean that you'll have screen tearing just as being under 60FPS doesn't mean that you won't get screen tearing.