In the last year, stuttering, micro-stuttering, and frame interval benchmarking have become a very big deal in the world of GPUs, and for good reason. Through the hard work of the Tech Report’s Scott Wasson and others, significant stuttering issues were uncovered involving AMD’s video cards, breaking long-standing perceptions on stuttering, where the issues lie, and which GPU manufacturer (if anyone) does a better job of handling the problem. The end result of these investigations has seen AMD embarrassed and rightfully so, as it turned out they were stuttering far worse than they thought, and more importantly far worse than NVIDIA.

The story does not stop there however. As AMD has worked on fixing their stuttering issues, the methodologies pioneered by Scott have gone on to gain wide acceptance across the reviewing landscape. This has the benefit of putting more eyes on the problem and helping AMD find more of their stuttering issues, but as it turns out it has also created some problems. As we laid out in detail yesterday in a conversation with AMD, the current methodologies rely on coarse tools that don’t have a holistic view of the entire rendering pipeline. And as such while these tools can see the big problems that started this wave of interest, their ability to see small problems and to tell apart stuttering from other issues is very limited. Too limited.

In their conversation AMD laid out their argument for a change in benchmarking. A rationale for why benchmarking should move from using tools like FRAPS that can see the start of the rendering pipeline, and towards other tools and methods that can see the end of the rendering pipeline. And AMD was not alone in this; NVIDIA too has shown concern about tools like FRAPS, and has wanted to see testing methodologies evolve.

That brings us to this week. Often evolution is best left to occur naturally. But other times evolution needs a swift kick in the pants. This week NVIDIA has decided to give evolution that swift kick in the pants. This week NVIDIA is introducing FCAT.

FCAT, the Frame Capture Analysis Tool, is NVIDIA’s take on what the evolution of frame interval benchmarking should look like. By moving the measurements of frame intervals from the start of the rendering pipeline to the end of the pipeline, FCAT evolves the state of benchmarking by giving reviewers and consumers alike a new way to measure frame intervals.  A year and a half ago the use of FRAPS brought a revolution to the 3D game benchmarking scene, and today NVIDIA seeks to bring about that revolution all over again.

FCAT is a powerful, insightful, and perhaps above all else labor intensive tool. For these reasons we are going to be splitting up our coverage on FCAT into two parts. Between trade shows and product launches we simply have not had enough time to put together a complete and proper dataset for FCAT, so rather than to do this poorly, we’re going to hold back our results until we’ve had a chance to run all of the FCAT tests and scenarios that we want to run

In part one of our series on FCAT, today we will be taking a high-level overview of FCAT. How it works, why it’s different from FRAPS, and why we are so excited about this tool. Meanwhile next week will see the release of part two of our series, in which we’ll dive into our FCAT results, utilizing FCAT to its full extent to look at where FCAT sees stuttering and under what conditions. So with that in mind, let’s dive into FCAT.

Reprise: When FRAPS Isn’t Enough

Since we covered the subject of FRAPS in great detail yesterday, we’re not going to completely rehash it. But for those of you who have not had the time to read yesterday’s article, here’s a quick rundown of how FRAPS measures frame intervals, and why at times this can be insufficient.

Direct3D (and OpenGL) uses a complex rendering pipeline that spans several different mechanisms and stages. When a frame is generated by an application, it must travel through the pipeline to Direct3D, the video drivers, a frame queue (the context queue), a GPU scheduler, the video drivers again, the GPU, and finally after that a frame can be displayed. The pipeline analogy is used here because that’s exactly what it is, with the added complexity of the context queue sitting in the middle of that pipeline.

FRAPS for its part exists at almost the very beginning of this pipeline. It interfaces with individual applications and intercepts the Present calls made to Direct3D that mark the end of each frame. By counting Present calls FRAPS can easily tell how many frames have gone into the pipeline, making it a simple and effective tool for measuring average framerates.

The problem with FRAPS as it were, is that while it can also be used to measure the intervals between frames, it can only do so at the start of the rendering pipeline, by counting the time between Present calls. This, while better than nothing, is far removed from the end of the pipeline where the actual buffer swaps take place, and ultimately is equally removed from the end-user experience. Furthermore because FRAPS is so far up the rendering pipeline, it’s insulated from what’s going on elsewhere; the context queue in particular can hold up to 3 frames, which means the rate of flow into the context queue can at times be very different from the rate of flow outside of the context queue.

As a result FRAPS is best descried as a coarse tool. It can see particularly egregious stuttering situations – like what AMD has been experiencing as of late – but it cannot see everything. It cannot see stuttering issues the context queue hides, and it’s particularly blind to what’s going on in multi-GPU scenarios.

Enter FCAT


View All Comments

  • Unwinder - Friday, March 29, 2013 - link

    Thanks, Ryan. I've already received hex reference colors from NV. MSI Afterburner with FCAT overlay support (3.0.0 beta 8) is expected to be released on Monday, EVGA Precsion 4.1.0 with FCAT overlay support will be available on the next week too. Reply
  • wingless - Thursday, March 28, 2013 - link

    Battlefield 3
    Guide: How to Fix Low FPS - Stuttering - Lag

    There is a well documented stuttering fix for both Nvidia and AMD users on multiple forums. I've tried this for my HD 4870 Crossfire setup and it works. This particular user from the above link has a NVIDIA GTX 470.

    5.Open notepad and paste this into it and save it as "user.cfg" inside your "program files/origingames/battlefield3" folder:

    RenderDevice.TripleBufferingEnable 0
    RenderDevice.ForceRenderAheadLimit 1
    WorldRender.SpotLightShadowmapResolution 256
    WorldRender.SpotlightShadowmapEnable 0
    Render.DrawFps 1

    With this applied to the game, are there any differences? Render Ahead seems to really affect these results and it would be nice if it were tested with FCAT.

  • JeBarr - Thursday, March 28, 2013 - link least now Ryan can keep his job :D

    A marriage of fraps/fcat will sure be convenient to have for all unqualified reviewers everywhere.
  • bill4 - Friday, March 29, 2013 - link

    i dont like the spin, lots of sites were left flat footed by scott wasson's work, and this article tries to spin it like "well we always wanted to do this, but we never had a good enough tool, until now" how convenient. it reminds of countless corporate bs. when beaten to a trend, a corporation will usually say something like "well we always wanted to do what out wildly popular competitor did, but only NOW can it be done properly, by us, we're not copying guys, no really"

    Nonsense. You never cared (much) before, Wasson's work started exposing you, so you jumped on the bandwagon, late, like a lot of sites.

    Mind you I like Anandtech, and dont even really like Wasson lol, but a spade's a spade.

    and this fcat is probably a better tool, all that may be true. but again, call a spade a spade.
  • Shark321 - Friday, March 29, 2013 - link

    Amen brother! Reply
  • Panta - Saturday, March 30, 2013 - link

    Missing here is pcper Ryan Shrout contribution
    to the creation & the development of Fcat & a the new card testing methodology.
    he spent last 12months working hard on this with Nvidia.

    i think you should Credit him here.
  • drpcusa - Saturday, March 30, 2013 - link

    Thank you for that article!
    <a href=”” target=“_blank“>Computer Repair and IT Services in Thousand Oaks, CA</a>
  • Samy0806 - Tuesday, April 2, 2013 - link

    Nice article, but i'm just a bit concerned about using another piece of hardware to get the results. What i also don't like is that the capture takes place at 60Hz. What about the ones that are "overclocking" their monitors (run them at more than the default 60 Hz refresh rate, for example my monitor now runs at 75 Hz) or the ones that have high refresh rate monitors, 120 Hz for example.
    Also what i would really really like to see is an in depth analysis of VirtuMVP. In theory it should generate a more responsive and/or smoother experience, but most of the games i've run with VitruMVP had, more or less, some form of stuttering.
  • wingless - Tuesday, April 2, 2013 - link

    AMD systems feel 'smoother' than Intel systems:

    I feel the topic of the OP relates to all of this new frame time testing directly. AMD systems may in fact be SMOOTHER than Intel system. I have a Core i7 2600k/Z77 system running crossfire. I can play Battlefield 3 on High at 60 to 120fps....albeit with a ton of stutter/dropped frames/runt frames. My coworker has a measly AMD FX-4100, with the same HD 6850 crossfire on an AMD 970 chipset. His system allows for CrossfireX to be enabled (Crossfire through the chipset/PCIe AND Crossfire cable simultaneously). His system ran only between 30 and 65fps during gameplay but clearly had no stutter/dropped frames/runt frames. At a reported 35fps his system played smoother than mine at 75fps. His 970 chipset was also pushing 1 card at PCIe 2.0 16x and the other at 4x, yet he was still 'smoother'.

    This irked me... AMD systems may very well be smoother in Crossfire configurations given the added features that support crossfire on their chipsets. I urge Anandtech members to please write Techreport, Anandtech, and PCPer to do more testing with AMD systems vs. Intel systems. Reviewers tend to only use Intel systems when doing all testing, but this may not be showing the entire picture (literally). Also let's continue this discussion given this new frame time point of reference and get to the bottom of this.

    Thanks folks.
  • Shark321 - Monday, April 8, 2013 - link

    What happened to part 2 of the analysis. What it not supposed to be released last week? Reply

Log in

Don't have an account? Sign up now