In Summary: The Frame Pacing Problem

Before we dive into the technical details of AMD’s frame pacing mechanism and our results, we’re going to spend a moment recapping the basis of the frame pacing problem. So if you haven’t been keeping up with this issue, please read on, otherwise feel free to jump a page.

In brief, in multi-GPU setups, be it single-card products like the GTX 690 or multiple cards such as a pair of 7970s, the primary mode of splitting up work is a process called Alternate Frame Rendering (AFR). In AFR, rather than have multiple GPUs working on a single frame, each GPU gets its own frame. This method has over time proven to be the most reliable method, as attempting to split up a single frame over multiple GPUs (with their relatively awful interconnect) has proven to be unreliable and difficult to get working. AFR in contrast is by no means perfect and has to deal with inter-frame dependency issues – where the next frame relies in part on the previous frame – but this is still easier to implement and more consistent than previous efforts at splitting frames.

However due to the mechanisms of AFR, left unattended it can significantly impact the intervals between frames and consequently whether stuttering is perceived. To do AFR well it’s necessary to pace the output of each GPU such that each GPU is delivering a rendered frame at as even a rate as possible; not too soon after the previous frame, and not too late such that the following frame comes up quickly. In a 2 GPU setup, which is going to be the most common, this means the second GPU needs to produce a finished frame when the first GPU is roughly half-way done with its current frame. Should this fail to happen then we have poorly paced frames that will result in perceived micro-stuttering.

Micro-stuttering has been a longstanding issue on multi-GPU setups. Both NVIDIA and AMD have worked on the issue to various degrees, but at the end of the day multi-GPU setups have never proven to be as reliable as single-GPU setups, which is why our editorial position on the matter has been to always favor single powerful GPUs over multiple GPUs when at all possible. Consequently it’s impractical to fully solve micro-stuttering and achieve frame pacing consistency on level with single-GPU setups, but it’s still possible to improve on previous methods and achieve a level of frame pacing that is reasonably effective and “good enough” for most needs. This is what AMD has been focusing on for the past few months.

Moving on, how AMD ended up in this situation is effectively the combination of three factors. The first of course being the innate technical challenged posed by AFR, while the second and third factors have been a poorly realized position on lag vs. consistency and a failure of competitive analysis respectively.

On the former, AMD’s position up until now has been that they’ve favored minimizing input lag in their designs. If you need to hold back a frame to better pace it, then you are by definition introducing some input lag, a quality that is generally undesirable to a user base that usually avoids mechanisms like v-sync for that reason. AMD’s position hasn’t been wrong of course, but it has come at the exclusion of allowing a bit of input lag to better manage frame pacing. AMD’s decision then has been to lighten up on this position and dedicate the resources to deal with both approaches. AMD would introduce advanced frame pacing as an optional control, while leaving the simpler, less laggy approach as another option.

Meanwhile the story with competitive analysis is far less complex. Simply put, AMD wasn’t testing for frame pacing as part of their standard competitive analysis, so when these results first broke AMD was caught flat-footed. This is a business failure rather than a technical failure, which makes it easy enough to resolve. But it’s also the reason why AMD needed time to develop an advanced frame pacing mechanism, as they had never seen the need to develop one before.

Ultimately this is a problem that should have never happened, and it is unfortunate that AMD let it come to this. At the same time however we believe it’s never too late for redemption, and AMD has been making all of the right moves to try to achieve that. They have been clear about their failures and shortcomings, including their frustrations that they’ve left performance on the table by not looking for these issues, and they have been equally clear in laying out a plan for how they would go about fixing all of this. So today we will finally get to see first-hand whether AMD’s initial efforts for resolving frame pacing in multi-GPU setups has paid off.

AMD Frame Pacing Explored Catalyst 13.8 Beta 1: The First Multi-GPU Frame Pacing Driver
POST A COMMENT

102 Comments

View All Comments

  • chizow - Saturday, August 3, 2013 - link

    Written on the walls at AMD Driver HQ I'm sure, quickly referenced when questioned about microstutter being worst on CF. Reply
  • krutou - Friday, August 2, 2013 - link

    BUT, BUT, BUT, RADEON PRO?!? Reply
  • LordOfTheBoired - Saturday, August 3, 2013 - link

    Took them by the hand? Looks more to me like "waited until people cared, then released a benchmark to prove they didn't have the problem, while offering no constructive commentary."

    And the hell of it is... AMD's stance makes sense. This IS a market that hates VSync because ZOMG LAG. "The market" has made it ABUNDANTLY clear that they have no interest whatsoever in technologies that improve the visual experience at the (real or imagined) cost of responsiveness.
    But apparently that's only true when there's the visual equivalent of a record skip on your screen and not when it's a subtle frame rate fluctuation. The former is a good thing because it means you "aren't lagged", the latter is a horrible thing because it means you "aren't lagged".
    Reply
  • chizow - Wednesday, August 7, 2013 - link

    @LordOfTheBoired - this is the type of indignant attitude that got AMD and their fans in this predicament to begin with. Reply
  • mikato - Wednesday, August 7, 2013 - link

    Well one result of Nvidia releasing the software was to allow tech journalists to shine a bright spotlight on a problem of their competitor's products. Your "holding AMD by the hand" idea is pretty amusing. Reply
  • novastar78 - Wednesday, August 7, 2013 - link

    What's sad is that AMD has ripped ATi to shreds to the point where they are spread pretty thin. Just getting a working product out the door is a task. You are being waaay too hard on them.

    They were using traditional methods to test and frankly it's not so unimaginable that they were caught by this. Granted, maybe it should have been caught sooner, but to demonize them or put them down for it seems a bit harsh.

    They know now that it's a big problem are definitely committed to fixing it. You can clearly see that they are trying to stabilize the company and there is lots of turmoil. The moves they are making and the people being brought on board are a good sign. There is definitely a process change that needs to happen but when the tree is being shaken so many times too many apples can fall.

    Give it some time, I think we will see great things form them over the next few years.
    Reply
  • Wreckage - Thursday, August 1, 2013 - link

    It did not help that certain people were claiming that AMD does not have a stutter problem. Reply
  • DanNeely - Thursday, August 1, 2013 - link

    The problem is that AMD didn't think they had a stutter problem; or more precisely, until 3rd parties shoved the reality in their face they assumed (without testing) that they and nVidia had equal amounts of the problem.

    I suspect at one point in the past they were right; and that the genesis of nVidia's "years in the making" tool to measure the problem dates back to when they discovered it was a problem internally and began working on fixes so that they could announce the same tool at the same time that their drivers had a negligible impact from it. It'd be interesting to see what would happen if someone tested SLI card/driver configurations from a few years ago to see how well nVidia did at the time.
    Reply
  • BrightCandle - Friday, August 2, 2013 - link

    NVidia has had this fixed for a lot longer than that. The 680's were noticeably smoother on their release day compared to the 7970 crossfire. NVidia has claimed they have been fixing this since the 8800 and there is no reason not to believe them as HardOCP and other review sites have been noting the difference for years. Reply
  • HisDivineOrder - Friday, August 2, 2013 - link

    Exactly. This has been a problem for as long as there has been Crossfire. I think a lot of people are so shocked by this fact (because some of them owned Crossfire and just dealt with it and didn't realize they were getting shafted) they can't accept it.

    Yes, you got reamed. Yes, for years, you were using Crossfire and suffering from microstutter when you needn't have to. Yes, AMD took you for a ride. It's so infuriating it drives people not to want to believe it because to believe it would be so horrible as to suddenly be intolerable.

    Do what most people do. Just stick with nVidia since you know they do proper testing. Boycott AMD for a five year period and come back once you're sure AMD's got their act together.
    Reply

Log in

Don't have an account? Sign up now