A new era of GPU benchmarking: Inside the second with Nvidia’s frame capture tools

Display-level reckoning for GPUs.

This story was brought to you by our friends at The Tech Report. You can view the original story here.

We've come a long way since our initial Inside the second article. That's where we first advocated for testing real-time graphics and gaming performance by considering the time required to render each frame of animation, instead of looking at traditional FPS averages. Since then, we've applied new testing methods focused on frame latencies to a host of graphics card reviews and to CPUs, as well, with enlightening results.

The fundamental reality we've discovered is that a higher FPS average doesn't necessarily correspond to smoother animation and gameplay. In fact, at times, FPS averages don't seem to mean very much at all. The problem boils down to a weakness of averaging frame rates over the span of a whole second, as nearly all FPS-based tools tend to do. Allow me to dust off an old illustration, since it still serves our purposes well:

The fundamental problem is that, in terms of both computer time and human visual perception, one second is a very long time. Averaging results over a single second can obscure some big and important performance differences between systems.

To illustrate, let's look at an example. It's contrived, but it's based on some real experiences we've had in game testing over the years. The charts below show the times required, in milliseconds, to produce a series of frames over a span of one second on two different video cards.
GPU 1 is obviously the faster solution in most respects. Generally, its frame times are in the teens, and that would usually add up to an average of about 60 FPS. GPU 2 is slower, with frame times consistently around 30 milliseconds.

However, GPU 1 has a problem running this game. Let's say it's a texture upload problem caused by poor memory management in the video drivers, although it could be just about anything, including a hardware issue. The result of the problem is that GPU 1 gets stuck when attempting to render one of the frames—really stuck, to the tune of a nearly half-second delay. If you were playing a game on this card and ran into this issue, it would be a huge show-stopper. If it happened often, the game would be essentially unplayable.

The end result is that GPU 2 does a much better job of providing a consistent illusion of motion during the period of time in question. Yet look at how these two cards fare when we report these results in FPS:
Whoops. In traditional FPS terms, the performance of these two solutions during our span of time is nearly identical. The numbers tell us there's virtually no difference between them. Averaging our results over the span of a second has caused us to absorb and obscure a pretty major flaw in GPU 1's performance.

Since we published that first article, we've seen a number of real-world instances were FPS averages have glossed over noteworthy performance problems. Most prominent among those was the discovery of frame latency issues in last Christmas' crop of new games with the Radeon HD 7950. When we demonstrated the nature of that problem with slow-motion video, which showed a sequence that had stuttering animation despite an average of 69 FPS, lots of folks seemed to grasp intuitively the story we'd been telling with numbers alone. As a result, AMD has incorporated latency-sensitive methods into its driver development process, and quite a few other websites have begun deploying frame-latency-based testing methods in their own reviews. We're happy to see it.

There's still much work to be done, though. We discovered a couple of problems in our initial investigation into these matters, and we haven't been able to explore those issues in full. For instance, we encountered concrete evidence of a weakness of multi-GPU setups known as micro-stuttering. We believe it's a real problem, but our ability to quantify its impact has been affected by another problem: the software tool that we've been using to capture frame times, Fraps, collects its samples at a relatively early stage in the frame rendering process. Both of the major GPU makers, AMD and Nvidia, have told us that the results from Fraps don't tell the whole story—especially when it comes to multi-GPU solutions.

Happily, though, in a bit of enlightened self-interest, the folks at Nvidia have decided to enable reviewers—and eventually, perhaps, consumers—to look deeper into the question of frame rendering times and frame delivery. They have developed a new set of tools, dubbed "FCAT" for "Frame Capture and Analysis Tools," that let us measure exactly how and when each rendered frame is being delivered to the display. The result is incredible new insight into what's happening at the very end of the rendering-and-display pipeline, along with several surprising revelations about the true nature of the problems with some multi-GPU setups.

How stuff works

Before we move on, we should take a moment to establish how video game animations are produced. At the core of the process is a looping structure: most game engines do virtually all of their work in a big loop, iterating over and over to create the illusion of motion. During each cycle through the loop, the game evaluates inputs from various sources, advances its physical simulation of the world, initiates any sounds that need to be played, and creates a visual representation of that moment in time. The visual portion of the work is then handed off to a 3D graphics programming interface, such as OpenGL or DirectX, where it's processed and eventually displayed onscreen.

The path each "frame" of animation takes to the display involves several stages of fairly serious computation, along with some timing complications. I've created a horribly oversimplified diagram of the process below.

As you can see, the game engine hands off the frame to DirectX, which does a lot of processing work and then sends commands to the graphics driver. The graphics driver must then translate these commands into GPU machine language, which it does with the aid of a real-time compiler. The GPU subsequently does its rendering work, eventually producing a final image of the scene, which it outputs into a frame buffer. This buffer is generally part of a queue of two to three frames, as in our illustration.

What happens next depends on the settings in your graphics card control panel and in-game menus. You see, although the rendering process produces frames at a certain rate—one that can vary from frame to frame—the display operates according to its own timing. In fact, today's LCD panels still operate on assumptions dictated by Ye Olde CRT monitors, as if an electron gun were still scanning phosphors behind the screen and needed to touch each one of them at a regular interval in order to keep it lit. Pixels are updated from left to right across the screen in lines, and those lines are refreshed from the top to the bottom of the display. Most LCDs completely refresh themselves according to this pattern at the common CRT rate of 60 times per second, or 60 Hz.

If vsync, or vertical refresh synchronization, is enabled in your graphics settings, then the system will coordinate with the display to make sure updates happen in between refresh cycles. That is, the system won't flip to a new frame buffer, with new information in it, while the display is being updated. Without vsync, the display will be updated whenever a new frame of animation becomes ready, even if it's in the middle of painting the screen. Updates in the middle of the refresh cycle can produce an artifact known as tearing, where a seam is visible between successive animation frames shown onscreen at once.

An example of tearing from Borderlands 2.

I sometimes like to play games with vysnc enabled, in order to avoid tearing artifacts like the one shown above. However, vsync introduces several problems. It caps frame rates at 60 Hz, which can interfere with performance testing (especially FPS-average-driven tests). Also, vsync introduces additional delays before a frame of animation makes it to the display. If a frame isn't ready for display at the start of the current refresh cycle, its contents won't be shown until the next refresh cycle begins. In other words, vysnc causes frame update rates to be quantized, which can hamper display updates at the very worst time, when GPU frame rates are especially slow. (Nvidia's Adaptive Vsync feature attempts to work around this problem by disabling refresh sync when frame rates drop.)

We have conducted the bulk of our performance testing so far, including this article, with vsync disabled. I think there's room for some intriguing explorations of GPU performance with vsync enabled. I'm not entirely sure what we might learn from that, but it's a different task for another day.

At any rate, you're probably getting the impression that lots happens between the game engine handing off a frame to DirectX and the content of that frame eventually hitting the screen. That takes us back to the limitations of one of our tools, Fraps, which we use to capture frame times. Fraps grabs its samples from the spot in the diagram where the game presents a completed frame to DirectX by calling "present," as denoted by the orange line. As you can see, that point lies fairly early in the rendering pipeline.

Since the frame production process is basically a loop, sampling at any point along the way ought to tell us how things are going. However, there are several potential complications to consider. One is the use of buffering later in the pipeline, which could help smooth out small rendering delays from one frame to the next. Another is the complicated case of multi-GPU rendering, where two GPUs alternate, one producing odd frames and the other churning out even frames. This very common load-balancing method can potentially cause delays when frames produced on the secondary GPU are transferred to the GPU connected to the display. Thornier still, Nvidia claims to have created a "frame metering" tech to smooth out frame delivery to the display on SLI configs—and that further complicates the timing. Finally, the issues we've noted with display refresh sync can play a part in how and when frames make it to the screen.

So.. yeah, Fraps is busted, right? Not exactly. You see, it's situated very close to the game engine in this whole process, and the internal simulation timing of the game engine determines the content of the frames being produced. Game animation is like a flipbook, and the contents of each page must advance uniformly in order to create the fluid illusion of motion. To the extent that Fraps' timing matches the internal timing of the game engine, its samples may be our truest indication of animation smoothness. We don't yet have a clear map of how today's major game engines track and advance their internal timing, and that is a crucial question. Fortunately, we do now have one other piece of the puzzle: some new tools that let us explore these issues at the ultimate end of the rendering pipeline: the display output. Let's have a look at them.

So what do we make of the problems of runt and dropped frames? They're troublesome for performance testing, because they get counted by benchmarking tools, helping to raise FPS averages and all the rest, but they have no tangible visual benefit to the end user.

That may be it. Of course it isn't the first time either has "fudged" things to make their product look good.

Really enjoyed reading this article. When looking at some of the charts evidencing load balancing issues in CrossFire configurations one wonders if AMD knew or understood this problem. I have no doubt that AMD has some of the finest engineers but I could see the engineers being driven to optimize for FPS rather than perception and experience to improve the marketing stance of their products.

AMD has apologized for this stuff, but it's all after-the-fact. They claim they weren't AWARE of this. WTF? They are either lying or incompetent. I.E. either AMD has a serious engineering problem causing these stutters that they have been hiding, or they actually never examined minimum frame rates and looked at the actual per-frame times, which is totally incompetent.

I mean, END users can practically see this stuff with their bare eyes- how can the manufacturer of one of the most complex integrated circuits in existence not test the living crap out of it? Even cursory testing should have shown that this was a problem.

As an engineer, it really brings my opinion of AMD down 3 or 4 pegs. I mean, NVIDIA obviously figured this out years ago, and it is common knowledge among users that AMD had a problem with minimum frame rates.

When in multi-gpu scenarios, AFR just runs the framerate up when it's already up. If a single card can't render a frame fast enough, two won't change that, so in essence, latency is increased just to appear smoother. I'm pretty sure that multi-gpus are the losers here. Maybe they'll discover or invest in something more appropriate than AFR.

Cool work, but it looks like a large dose of brute force is required right now. I think you should be able to get most of the bang for a lot less bucks by just capturing the color stripes on the side, reducing the required bandwidth massively. Does anybody have experience with video capture cards that can capture just parts of the screen? Can they handle these resolutions without dropping frames?

^^ Yeah. I think you have to be a little careful if an Nvidia tool shows there's something the matter with AMD's hardware. I'm not saying it's necessarily wrong, but grain of salt required.

FRAPS isn't a Nvidia tool. ANY framerate tool that can measure minimum frame rates sees this problem to some extent, it's just much clearer when you chart all the frame latencies individually. It depends on how long you average over for a frame rate- equivalent minimum frame rate really ought to be measured over a single frame (then normalized to per second).

This is not really news, it's just been made crystal clear to the point where AMD had to address it. The only real news is that AMD claims they didn't know about it.

AMD has apologized for this stuff, but it's all after-the-fact. They claim they weren't AWARE of this. WTF? They are either lying or incompetent. I.E. either AMD has a serious engineering problem causing these stutters that they have been hiding, or they actually never examined minimum frame rates and looked at the actual per-frame times, which is totally incompetent.

Fully agree. I can't see their engineers and techs being THAT incompetent. I'll bet you a case of beer that some overpaid pointy-haired 'manager' decided the issue 'wasn't relevant.'

Hoping someone with older hardware and drivers has the time to run some fraps numbers and narrow down the time when this issues started to rear its jagged little head.

I take it as a sign that benchmarks (or at least their aspirations) are maturing a bit. Insofar as FPS taken as an average is used as a stand-in for smoothness, now there is a recognition that the variance also matters. (Sticking to the time domain is probably simpler, but one can of course define an "instantaneous" FPS as the inverse of the frame duration.) The average will still generally be the more important factor unless the variance is quite large, and indeed we're talking about "micro-stuttering" and not "unplayable choppiness."

Blatantly speculating, I'd guess that Nvidia believes it has done enough clever engineering that it can encourage developing a way of measuring these things and turn it into a marketing advantage for at least a generation or two. After all, if consumers care most about megapixels (as for a long time with cameras) that tends to be what is created and trumpeted, for better or worse. If consumers start to care about a shiny new benchmark that shows Nvidia cards ahead, then at least for a while that will probably be over-weighted in reviews, even if it makes a miniscule difference for the average consumer. And even if reviewers take care to stress how minor a difference it makes, that subtlety doesn't hurt Nvidia. Especially not compared to a simple number from that benchmark that says the Nvidia card is k times better. Product differentiation, full stop.

Right now I think the FPS wars are, to some extent, where the megapixel and gigahertz wars of ages past were. We'll probably get better products out of this in the long run (assuming AMD doesn't fold) because the issue is real. I just hope we'll keep things in perspective when pitted against marketers that desperately want us to care a lot. Expect some breathless articles at second-rate technical sites.

I take it as a sign that benchmarks (or at least their aspirations) are maturing a bit. Insofar as FPS taken as an average is used as a stand-in for smoothness, now there is a recognition that the variance also matters. (Sticking to the time domain is probably simpler, but one can of course define an "instantaneous" FPS as the inverse of the frame duration.) The average will still generally be the more important factor unless the variance is quite large, and indeed we're talking about "micro-stuttering" and not "unplayable choppiness."

Blatantly speculating, I'd guess that Nvidia believes it has done enough clever engineering that it can encourage developing a way of measuring these things and turn it into a marketing advantage for at least a generation or two. After all, if consumers care most about megapixels (as for a long time with cameras) that tends to be what is created and trumpeted, for better or worse. If consumers start to care about a shiny new benchmark that shows Nvidia cards ahead, then at least for a while that will probably be over-weighted in reviews, even if it makes a miniscule difference for the average consumer. And even if reviewers take care to stress how minor a difference it makes, that subtlety doesn't hurt Nvidia. Especially not compared to a simple number from that benchmark that says the Nvidia card is k times better. Product differentiation, full stop.

Right now I think the FPS wars are, to some extent, where the megapixel and gigahertz wars of ages past were. We'll probably get better products out of this in the long run (assuming AMD doesn't fold) because the issue is real. I just hope we'll keep things in perspective when pitted against marketers that desperately want us to care a lot. Expect some breathless articles at second-rate technical sites.

True, but the variance IS large, and micro-stuttering can be a lot more than a minor inconvenience. People are seeing occasional frame latencies of large fractions of a second; that's insane; all it takes is a few frames like that and your experience goes right down the toilet.

Really if you think about the way that the dual graphics cards work this makes perfect sense, because their power is not directly additive, but rather they are working to spread out the load. This can be helpful, but obviously if you have a problem with one or the other, you don't actually have twice the power working on it, so your worst frame is likely to be the same as the individual card worst frame unless you set things up to circumvent the issue.

Latency is definitely a useful thing to measure, so thanks for bringing it more to the attention of benchmarkers and benchmark readers.

However, you mention fsync, and I simply refuse to play games without fsync enabled (I find tearing much worse than skipped frames, subjectively). So, I hope you will do something comprehensive with fsync enabled in the future - maybe also testing the effects of triple buffering.

The description of how LCD panels refresh is incorrect. LCD pixels do not behave the same way phosphors do, thus the physical refresh mechanism is not the same as that of a CRT. I am not aware of any panels which physically refresh left-to-right, and many are not line by line.

Any given horizontal line's pixels are refreshed all at once, as the pixel data can be envisioned as sitting in at the top (or bottom) waiting for the next line refresh period. A row refresh signal toggles "on", and all pixels (sub-pixels really) of a given line accept new data values more-or-less simultaneously.

For high resolution or large panels, two lines may be refreshed simultaneously, one line in the upper half, another line in the lower half. The reason for this is that a large "load" either from large numbers of pixels or a long physical distance cause the pixel values to degrade. You can solve the problem by providing either adaptive drive circuits to compensate *or* by providing two set of column drivers, one on top and the other on bottom.

As for Ye Olde CRT driving the 60Hz rate, it's more a case of economics, Ye Olde Content Providers, and the content infrastructure for making things work at 60Hz. Going beyond those reasons, LCD image quality tends to degrade pretty quickly as you move away from whatever natural frequency the panel is designed for. If you can remember some of the artifacts of multi-frequency CRT monitors, think of those artifacts being exaggerated very noticeably. LCDs are more-or-less are single frequency devices for good reasons.

True, but the variance IS large, and micro-stuttering can be a lot more than a minor inconvenience. People are seeing occasional frame latencies of large fractions of a second; that's insane; all it takes is a few frames like that and your experience goes right down the toilet.

The variance is large (relative to a given player's tolerance) sometimes, for some games, on some setups. I won't downplay it when it is a problem, nor did I try to in my post. I mean, I've played Bethesda games. But we've probably been able to tolerate 15+ years of accelerated 3D gaming because most of the time things aren't that bad, or at least there were bigger fish to fry at the time. When micro-stuttering (which is always present to some degree) passes the limen sufficiently it graduates to plain old stuttering, and I applaud quantifying such things and getting an idea on where the transition tends to occur. Like I said, a sign of maturity in benchmarking.

I'm just not expecting corresponding maturity from marketing, which will want consumers to care about differences an order of magnitude below perception. Or the occasional person who "sees" stuttering a benchmark says exists only because the benchmark says it exists. (And "totally did a double-blind test.") These are not problems with a benchmark as such, they are problems with us.

Correct me if I'm wrong or haven't understood something in the article correctly but crossfire has multiple modes, AFR and one that "splits" the frame into a checker-board with each card doing parts of it ( http://www.xbitlabs.com/images/video/at ... tiling.gif )I would be interested in knowing the performance of this mode compared to AFR, see if the jitter is still an issue.

I'd be more interested if this was a third party suite as I have ZERO faith in Nvidia doing ANYTHING that would help their competitor...

The thing is that this problem exists on the nVidia side as well, though not to the same degree. This exposes flaws not just in hardware and drivers but also the software stack. I suspect instead of using this data to actively compete between nVidia and AMD, those two companies will work together to tag team Microsoft into improving DirectX.

Correct me if I'm wrong or haven't understood something in the article correctly but crossfire has multiple modes, AFR and one that "splits" the frame into a checker-board with each card doing parts of it ( http://www.xbitlabs.com/images/video/at ... tiling.gif )I would be interested in knowing the performance of this mode compared to AFR, see if the jitter is still an issue.

AFR is easy enough to cheat to spread the work load across multiple GPU's. There are problems with DirectX and some titles if tiling or split frame load balancing are used. Both AMD and nVidia have alternatives to AFR but they are not used for this very reason.

So what do we make of the problems of runt and dropped frames? They're troublesome for performance testing, because they get counted by benchmarking tools, helping to raise FPS averages and all the rest, but they have no tangible visual benefit to the end user.

That may be it. Of course it isn't the first time either has "fudged" things to make their product look good.

It's not fuding values at all. If you want to test performance you need to include time spent on dropped frames as well, otherwise your ignoring a big chunk of the performance data. In this case fudging values would be intentionally not including them.

Personally I'm more concerned about the validity of test results when using two programs that detour the Present() call. The Present() call in Direct3D tells it where to render the picture to, what part of the picture to render, as well as blocks the calling thread (unless multithreaded rendering is present and enabled). There is no way to tell whether a frame will be dropped or presented to the screen until after the fact, so even dropped frames are stalling the CPU (or at least one thread on it) until the call succeeds or fails, and you only get a fail if the rendering process produces an error. Even if there is an error it can still return success if the driver or Direct3D silently handled the error (for example Direct3D9 will silently handle bad FVF configurations as long as it only impacts the object it occurred in, but the error still occurs causing the GPU to stall while it recovers).

So what do we make of the problems of runt and dropped frames? They're troublesome for performance testing, because they get counted by benchmarking tools, helping to raise FPS averages and all the rest, but they have no tangible visual benefit to the end user.

That may be it. Of course it isn't the first time either has "fudged" things to make their product look good.

It's not fuding values at all. If you want to test performance you need to include time spent on dropped frames as well, otherwise your ignoring a big chunk of the performance data. In this case fudging values would be intentionally not including them.

Personally I'm more concerned about the validity of test results when using two programs that detour the Present() call. The Present() call in Direct3D tells it where to render the picture to, what part of the picture to render, as well as blocks the calling thread (unless multithreaded rendering is present and enabled). There is no way to tell whether a frame will be dropped or presented to the screen until after the fact, so even dropped frames are stalling the CPU (or at least one thread on it) until the call succeeds or fails, and you only get a fail if the rendering process produces an error. Even if there is an error it can still return success if the driver or Direct3D silently handled the error (for example Direct3D9 will silently handle bad FVF configurations as long as it only impacts the object it occurred in, but the error still occurs causing the GPU to stall while it recovers).

This new testing methods, as it is explained, takes into account the issue with FRAPS present() call logging, while also showing that the difference in result isn't that large but allows a better understanding of runts and lost frames (that are still counted towards higher FPS).

Really enjoyed reading this article. When looking at some of the charts evidencing load balancing issues in CrossFire configurations one wonders if AMD knew or understood this problem. I have no doubt that AMD has some of the finest engineers but I could see the engineers being driven to optimize for FPS rather than perception and experience to improve the marketing stance of their products.

you should read Anand's article, AMD are very aware, he has a good write up on it this week, afaik they had the FCAT tool before anyone else.

Really enjoyed reading this article. When looking at some of the charts evidencing load balancing issues in CrossFire configurations one wonders if AMD knew or understood this problem. I have no doubt that AMD has some of the finest engineers but I could see the engineers being driven to optimize for FPS rather than perception and experience to improve the marketing stance of their products.

you should read Anand's article, AMD are very aware, he has a good write up on it this week, afaik they had the FCAT tool before anyone else.

AMD are very aware about 9 months after Scott @ TechReport pointed out the massive issues that led to every other site having a look as well. AMD should shoulder ALL the blame here and I have a Phenom II and 6870 GPU so no fanboyism. I am inclined to believe jmfirth's version of what happened. Some good engineers working towards the wrong goals and some shitty engineers not bothering to benchmark carefully.

I mean, END users can practically see this stuff with their bare eyes- how can the manufacturer of one of the most complex integrated circuits in existence not test the living crap out of it? Even cursory testing should have shown that this was a problem.

I've stared at the examples multiple times at full screen. I can barely, sort of, kind of make out the issue they're talking about. Half the time I can't even see it. Not sure why, maybe I'm just used to it?

Awesome read, really interesting. I had a 6950 Xfire setup, and could not bear the microstutter in BF3, even though the cards were great performers. I've moved on to a 670 gtx sli setup, and really have not noticed anything along the lines of ANY microstutter. I'm very intrigued by this information, as it does align with what I have experienced.

The description of how LCD panels refresh is incorrect. LCD pixels do not behave the same way phosphors do, thus the physical refresh mechanism is not the same as that of a CRT. I am not aware of any panels which physically refresh left-to-right, and many are not line by line.

Any given horizontal line's pixels are refreshed all at once, as the pixel data can be envisioned as sitting in at the top (or bottom) waiting for the next line refresh period. A row refresh signal toggles "on", and all pixels (sub-pixels really) of a given line accept new data values more-or-less simultaneously.

For high resolution or large panels, two lines may be refreshed simultaneously, one line in the upper half, another line in the lower half. The reason for this is that a large "load" either from large numbers of pixels or a long physical distance cause the pixel values to degrade. You can solve the problem by providing either adaptive drive circuits to compensate *or* by providing two set of column drivers, one on top and the other on bottom.

As for Ye Olde CRT driving the 60Hz rate, it's more a case of economics, Ye Olde Content Providers, and the content infrastructure for making things work at 60Hz. Going beyond those reasons, LCD image quality tends to degrade pretty quickly as you move away from whatever natural frequency the panel is designed for. If you can remember some of the artifacts of multi-frequency CRT monitors, think of those artifacts being exaggerated very noticeably. LCDs are more-or-less are single frequency devices for good reasons.

good story and so on. but the presentation of the data for fraps and fcat, is not visible for the color-blind in some of the graphs, next time use colors that are more different from each other .

And for the story itself if fraps record the frame so early isnt the game engines timing and adjustment algorithm more important than the frame induced deleys from the hardware. what i mean is that most of the test we read is from big title games with big budgets , these game engine can handle a frame shutter hardware problem to some extent and hide the problem. if i buy a graphic card and play a low budget indie game thats has an average algorithm for handling this ,the game might be rendered unplayble just because fraps + big title game hides problem.So if this issue with hardware frame delays are important all test needs to have both fraps + fcat data to get an informed decision or did i misunderstand ?

Nvidia is getting really desperate. AMD is eating their lunch on games in the foreseeable future, so they're trying everything possible to try to paint the competition in a bad light. This is just some fan service for their avid fanbois to wank to.

So keep crying "runt frames", and I'll just keep playing my games.

If you have a CF setup...use a frame limiter. MSI Afterburner comes with a nice one.

Crossfire FuzzinessI think the author accidentally mixed up the Fraps and FCAT results for the Crossfire setup. Without access to the raw data, I can't prove it, but what I find more curious than the "fuzziness" is that every graph in the article uses the darker hue for the FCAT results - except the Crossfire graphs.

The Blame GameI've said this before. While I agree with the premise that smoother gameplay is better, I disagree with the gut reaction to blame the card, the drivers, or the operating system. Many games have either been implicitly (game engine level) or explicitly (game level) optimized for Nvidia cards. In games that have been optimized for AMD, like the DiRT series, the gameplay is very smooth and puts Nvidia to shame. Just look at The Tech Report's own results.

AreWeThereYeti wrote:

AMD has apologized for this stuff, but it's all after-the-fact. They claim they weren't AWARE of this. WTF? They are either lying or incompetent. I.E. either AMD has a serious engineering problem causing these stutters that they have been hiding, or they actually never examined minimum frame rates and looked at the actual per-frame times, which is totally incompetent.

I mean, END users can practically see this stuff with their bare eyes- how can the manufacturer of one of the most complex integrated circuits in existence not test the living crap out of it? Even cursory testing should have shown that this was a problem.

As an engineer, it really brings my opinion of AMD down 3 or 4 pegs. I mean, NVIDIA obviously figured this out years ago, and it is common knowledge among users that AMD had a problem with minimum frame rates.

YEAH!! Burn them at the stake!!!

As a computer scientist, I know there's far more going on here than hardware.

Other

yakumo wrote:

jmfirth wrote:

Really enjoyed reading this article. When looking at some of the charts evidencing load balancing issues in CrossFire configurations one wonders if AMD knew or understood this problem. I have no doubt that AMD has some of the finest engineers but I could see the engineers being driven to optimize for FPS rather than perception and experience to improve the marketing stance of their products.

you should read Anand's article, AMD are very aware, he has a good write up on it this week, afaik they had the FCAT tool before anyone else.

For those who wants to go in deep the topic, think the best way to explain the work of GPU is to look at "distributed computer" on Amazon and consider the hardware as a little p2p network. Concept born in the mid 90's.