Widescreen Gaming Forum

The problem here is not in using FRAPS to measure average framerates over the run of a benchmark, but rather when it comes to using FRAPS to measure individual frames. FRAPS is at the very start of the rendering pipeline; it’s before the GPU, it’s before the drivers, it’s even before Direct3D and the context queue. As such FRAPS can tell you all about what goes into the rendering pipeline, but FRAPS cannot tell you what comes out of the rendering pipeline.
So to use FRAPS in this method as a way of measuring frame intervals is problematic. Considering in particular that the application can only pass off a new frame when the context queue is ready for it, what FRAPS is actually measuring is the very start of the rendering pipeline, which not unlike a true pipe is limited by what comes after it. If the pipeline is backed up for whatever reason (context queue, drivers, etc), then FRAPS is essentially reporting on what the pipeline is doing, and not the frame interval on the final displayed frames. Simply put, FRAPS cannot tell you the frame interval at the end of the pipeline, it can only infer it from what it’s seeing.
.......
Adding weight to the whole matter is the fact that FRAPS is one of the few things both AMD and NVIDIA can agree on. In our talks with NVIDIA and in past statements made to the press, NVIDIA dislikes FRAPS being used in this manner for roughly the same reason. The fact that it’s measuring Present calls instead of the time a frame is actually shown to the user impacts them just as well, and muddles the picture when it comes to trying to differentiate themselves from AMD. Again, not to say that NVIDIA thinks FRAPS is a bad tool, but there seems to be a general agreement with AMD’s stance that beyond a certain point it’s the wrong tool for measuring stuttering.

Stuttering doesn’t just impact the frame intervals, but many of those stalls where stuttering was occurring were also stalling the GPU entirely, reducing overall performance. One figure AMD threw around was that when they fixed their stuttering issue on Borderlands 2, overall performance had increased by nearly 13%, a very significant increase in performance that AMD would normally have to fight for, but instead exposed by an easy fix for stuttering.

In a heartbeat situation the next Present gets delayed coming out of the application for whatever reason, which results in the rendering pipeline feeding from the context queue for a bit while nothing new comes in. Eventually the block is cleared and the application submits the next Present, at which point FRAPS records the Present as having come relatively later. Furthermore, since the context queue has been at least partially drained, there’s still room for one more frame, so rather than idling for a bit the application immediately gets to work on the next frame. As a result the next Present hits the context queue sooner than average, resulting in the early frame as picked up by FRAPS.

Multi-GPU stuttering has become an important issue for AMD just as single-GPU stuttering has, and AMD is working on a resolution for it. That resolution will come in or around a July driver drop, at which point AMD will introduce some new driver options to control how their cards deal with the issue.

The next question from our readers should then be: are there questions about the programs used for this purpose? After having access to the source code and applications for more than 12 months I can only say that I have parsed through it all innumerable times and I have found nothing that NVIDIA has done that is disingenuous. Even better, we are going to be sharing all of our code from the Perl-based parsing scripts (that generate the data in the graphs you’ll see later from the source XLS file) as well as a couple of examples of the output XLS file

Another issue that cropped up with the AMD configurations in CrossFire mode showed its face when we tried 5760x1080 testing. In nearly every case, an AMD CrossFire dual-GPU configuration running an Eyefinity configuration at 5760x1080 showed alternating dropped frames. Whereas with single monitor gaming we were seeing some full game frames being turned into runts at the display, with Eyefinity those frames were missing completely (seen as missing overly colors from the expected pattern).

This actually caused two things to happen. First, our Perl scripts and data generation would sometimes error out completely (after the capture and extraction steps) because the code was never able to find the initial sequence of 16 colors in the correct order to validate the video capture. We are still working on a fix for this in order to present that information in a useable format, but for now we will point out specifically when that occurred. Secondly, the frame rates were smoother! Without the runts getting in the way of the animation sequences the motion on the screen was actually more fluid than it would have been otherwise, but don’t take this as a vindication of what AMD’s Eyefinity is actually doing. While the animation is smoother, you are still not seeing any benefit from the second card in your CrossFire configuration and you could view it simply as wasted investment.
Finally, we saw some interesting visual problems in our captures of Eyefinity that cause us to raise some eyebrows. Because the overlay changes colors with every frame I was able to notice some instances where the digital scan out of the graphics cards were not matching up; frames were being split by other frames.

As I later learned, enabling Vsync actually does not work at all with Eyefinity and that, combined with the results I have seen (of which the screenshot above is an indicator) with our testing, lead me to believe that something is fundamentally wrong with AMD’s Eyefinity implementation. And if it’s not “wrong”, it is definitely counter intuitive. We’ll be asking AMD for more information in the coming weeks and hope to get more information from them as our Frame Rating process evolves.

The microstutter problem we (or at least I) am having is also quite apparent even if the game runs at a constant 60 fps with v-sync on and everything. 'Normal' stuttering from either low or inconsistent fps is fixable by turning v-sync on or lowering the graphical settings. Running a game in eyefinity and with crossfire enabled at 60 fps can feel like 20-30 fps, so that would make a second card useless.

But the thread vom Tech report with Fraps made AMD aware of their deficit. and now according to anandtech AMD is working heavy on getting stuttering solved. And maybe after that they will take a look on Crossfire! And Eyefinity!

One thing to note: this fix does not yet address Eyefinity + CrossFire problems. The prototype and the current implementation of the fix are only going to address single monitor configurations due to the differences in how the multiple rendered images are composited. Resolutions up to 2560x1600 are handled by a hardware compositor while the 5760x1080 and above Eyefinity resolution use a software implementation that is apparently much more complex (and causes quite a few graphical issues we'll dive into later).

There is still the issue of Eyefinity and that problem will not be addressed by this first version of the driver. I have more analysis of that complicated discussion planned in the coming weeks. Stay tuned!