For as long as I can remember talking about video cards and GPU performance at AnandTech, there has been debate over the type of benchmarks used to represent that performance. In the old days, the debate was mostly manufacturer driven. Curiously enough, the discourse usually fired up when one manufacturer was at a significant deficit in GPU performance. NVIDIA made a big deal about moving away from timedemos and average frame rates during the early GeForce FX (NV30) days, when its cards might have delivered a decent gaming experience but were slaughtered in most benchmarks. Even Intel advocated for a shift away from most CPU bound gaming benchmarks back during the early years of the Pentium 4 - again, for obvious reasons.

It’s a shame that these revolutions in gaming performance testing were always associated with underperforming products (and later dropped once the product stack improved in the next generation or two). It’s a shame because there has always been merit in introducing additional metrics in order to provide the most complete picture when it came to gaming performance.

The issue lay mostly dormant over the past several years. Every now and then there’d be a new attempt to revolutionize GPU performance testing, but most failed to gain widespread traction for one reason or another. Broad repeatability, one of the basic tenets of the scientific method, was usually cast aside in pursuit of a lot of these new attempts at performance testing - which ultimately limited acceptance.

A year and a half ago, Scott Wasson over at the Tech Report did something no one since Dr. Pabst was able to do: he actually brought about a revolution in the 3D game benchmarking scene.

The approach seemed ridiculously simple - we’ve all had the tools for so very long. Scott used FRAPS to record frame times, and would calculate how long every frame in a benchmark took to render. By focusing on individual frame latencies, Scott’s method could better characterize the little hiccups and stutters that would get smoothed out in an average frame rate. With the new method came a bunch of nifty graphs, and the world changed.

The methodology wasn’t perfect, as FRAPS lacks a holistic view of the 3D rendering pipeline, but it did reveal some surprising issues (in addition to spawning further work that uncovered even more issues on the multi-GPU front). Interestingly enough, many of the issues uncovered by this focus on frame times/latency seemed to primarily impact AMD hardware.

AMD remained curiously quiet as to exactly why its hardware and drivers were so adversely impacted by these new testing methods. While our own foray into evolving GPU testing will come later this week, we had the opportunity to sit down with AMD to understand exactly what’s been going on.

Although neither strictly a defense nor merely an explanation of what we’ve been seeing over the past year, AMD wanted to sit down and better explain their position. This includes both why AMD’s products have been impacted in the manner they were, and why at the same time (and not unlike NVIDIA) AMD is worried about FRAPS being given more weight than it should be. Ultimately AMD believes that it’s to the benefit of buyers and journalists alike to better understand just what is happening, why it’s happening, and just what the most common tools can and are measuring.

What follows is based on our meeting with some of AMD's graphics hardware and driver architects, where they went into depth in all of these issues. In the following pages we’ll get into a high-level explanation of how the Windows rendering pipeline works, why this leads to single-GPU issues, why this leads to multi-GPU issues, and what various tools can measure and see in the rendering process.

The Start: The Rendering Pipeline In Detail
Comments Locked

103 Comments

View All Comments

  • jb14 - Tuesday, March 26, 2013 - link

    Perhaps a small typo: 'without'? Pg 4 para 2.

    "AMD, quite bluntly, has a problem with how FRAPS is being used in some cases. To be clear here FRAPS is a wonderful tool, and withOUT it we would be unable to include a number of different games in our hardware reviews."

    Very interesting article, still digesting it all, thank you for taking the time & effort to share it.
  • Deo Domuique - Tuesday, March 26, 2013 - link

    I told you... AMD Peasants, that's what we are. Stuttering, Microstuttering, Flashing/Flickering black artifacts on DX9 games, many times we're forced to disable GPU acceleration on very few programs outside gaming that use the card, like Firefox, Flash and even Windows...

    I'd seriously prefer sporadic issues on games, but at least all the programs and Windows to be working flawlessly. Even on video occasionally we get problems...

    I guess I learnt the hard way that all "rumors" about bad AMD drivers experience are god damn true... And no, Nvidia isn't like that nor in the slightest. In my many years experience with Nvidia cards, I can only name you one serious problem I faced, but the solution came relatively fast, 275.33 drivers started Browser TDR, it ended with 290.26 drivers.
  • polaco - Wednesday, March 27, 2013 - link

    What are you talking about? I have had ATI / AMD cards for years almost 10 years. Never ever an issue like the one you are describing. Disable GPU acceleration? Serioulsy? that's incredibly ridiculous.
  • alacard - Tuesday, March 26, 2013 - link

    Sanctimonious.

    Guys, i know you think you're Gods one true miracle to tech news, but would it be so much to ask to stop writing your articles as if there were no question as to the veracity of that claim? You sound so pious, so arrogant, so self-righteous in this article. Please tone it down.
  • FriendlyUser - Tuesday, March 26, 2013 - link

    Fantastic article! The presentation is very clear and clarifies the situation, especially the question of whether FRAPS is an appropriate tool. The whole latency has been way overblown by techreport and the nvidia fanboys. Anyway, the AMD engineers have done a great job on improving things.
  • GordonM256 - Tuesday, March 26, 2013 - link

    Very nice "damage control" article for both AMD and Anandtech! Well done with excuses like "FRAPS sux anyways so we will wait for "better tools", giving AMD more time to fix the issues, which aren't really issues anyways because most people won't notice any stuttering" ;-)
    P.S: Yes, I know that FRAPS has issues (Scott himself said that), but you could've said it in more neutral way and much earlier.
  • JonnyDough - Tuesday, March 26, 2013 - link

    Does this mean that they will be updating OLD drivers as well? Specifically for a VERY LARGE base of HD4800 series users?
  • croc123 - Tuesday, March 26, 2013 - link

    Totally NOT about the article.... You had a comment regarding Dr. Pabst, that (being blue) I thought might be a link to something bearing some information regarding the venerable Dr. Tom... But no... It just linked back to Tom's hardware, which I am sure Dr. Pabst would have considered an insult. Tsk Tsk...
  • StevePeters - Tuesday, March 26, 2013 - link

    Great write up.
    Can someone explain why it is not possible to hook into the interrupt that the GPU generates after rendering a frame to provide the measure that's FRAPS is missing?
  • pandemonium - Wednesday, March 27, 2013 - link

    Superb article! The detail of explanation and the reference citing - absolutely excellent. Thanks, Ryan!

Log in

Don't have an account? Sign up now