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

  • boot318 - Thursday, August 1, 2013 - link

    I've read a couple people got "black screened" when they did this update on one GPU. I'm not saying that will happen, but you better prepare for it if you do. Reply
  • Bob Todd - Thursday, August 1, 2013 - link

    I may have missed this when I skimmed through the results, but have you heard anything about rough estimates from AMD about a frame pacing release supporting Eyefinity (e.g. Q4, H1 2014, etc.)? I know it's still a tiny percentage of users, but there are relatively cheap 1080p IPS panels now so building a nice looking 5760x1080 setup is pretty affordable these days. After playing games this way, it's something I wish I had done earlier, and I'm eager to see a frame pacing driver supporting this setup. Reply
  • Ryan Smith - Thursday, August 1, 2013 - link

    Sorry, AMD didn't give us an ETA on that one. Let me see if I can still get one out of them. Reply
  • DanNeely - Thursday, August 1, 2013 - link

    HardOCP says DX9 and Eyefinity support should be available in a driver update later this month.

    http://www.hardocp.com/article/2013/08/01/amd_cata...
    Reply
  • DeviousOrange - Thursday, August 1, 2013 - link

    I am hoping this will also improve Dual Graphics, will give it a test over the weekend. Reply
  • Homeles - Thursday, August 1, 2013 - link

    Well I'll be damned. They did it. Not quite as good as Nvidia, but at this point, the difference isn't really one worth mentioning. Reply
  • xdrol - Thursday, August 1, 2013 - link

    The link is bad for the driver, please remove "-auth" from the URL. Reply
  • chizow - Thursday, August 1, 2013 - link

    Like watching a baby crawl. Good first step for AMD, but still a long way to go.

    AMD and their fans can thank the press (mainly TechReport and HardOCP, sorry Derek, you guys were way late to the party and still not fully onboard with FCAT measurements) and Nvidia fans for making such a big stink of this. Lord knows AMD and their fans were too busy looking the other way to address it, anyways.

    Hopefully AMD and their fans take something away from this: if you want to improve your product, don't try to sweep it under the rug, address it, own it, and demand a fix for it.
    Reply
  • chizow - Thursday, August 1, 2013 - link

    Sorry my above post should reference the author Ryan, not Derek (was thinking of your predecessor), when referring to AT not being at the forefront of this runtframe/microstutter issue.

    Also, I feel the accolades given to TechReport, while not completely undeserving, should also be given to PCPer's Ryan Shrout and some of the German publications like PCGamesHardware. While TechReport did start the ball rolling with some new ways to measure frame latency/microstutter, Ryan Shrout really harped on the runtframe issue until Nvidia worked with him in unveiling FCAT. Also, the German sites have been hammering AMD for years about their much worst microstuttering in CF, largely ignored by the NA press/blogs. And finally Kyle at HardOCP has said for years SLI felt smoother than CF with some Pepsi challenge type user testing, but not so much hard evidence as presented here as well as other sites.

    Finally Ryan, are these new metrics you've done an excellent job of formulating going to make it into future benchmarks? Or are you going to just assume the issue has been fixed going forward? I would love to take AMD's word on it but as we've seen from both vendors in the past, driver regression is commonplace unless constantly revisited by users, reviewers, and the vendors alike.
    Reply
  • Ryan Smith - Friday, August 2, 2013 - link

    "Finally Ryan, are these new metrics you've done an excellent job of formulating going to make it into future benchmarks?"

    They'll be in future articles in a limited form, similar to how we handled the GTX 780 launch. It takes a lot of additional work to put this data together, which isn't always time we have available. Especially if it becomes doing hours of extra work to collect data just to say "yep, still no stuttering."
    Reply

Log in

Don't have an account? Sign up now