AMD Frame Pacing Explored: Catalyst 13.8 Brings Consistency to Crossfire
by Ryan Smith on August 1, 2013 2:00 PM ESTIn 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.
Facebook
Twitter
RSS
102 Comments
View All Comments
waldoh - Thursday, August 1, 2013 - link
Its unfortunate it a competing company to shine light on an issue for another to address it.waldoh - Thursday, August 1, 2013 - link
took*tackle70 - Thursday, August 1, 2013 - link
I'd say it's more like expected than unfortunate. This is why competition is a good thing and why you never want one company to blow away another - competition makes all companies serve their customer better.Big time kudos to AMD for their work on this; it's nice to see real competition available again in the $500+ market.
Rezurecta - Thursday, August 1, 2013 - link
Excellent and well said.HisDivineOrder - Thursday, August 1, 2013 - link
I think he was referring to the fact that this issue was present for many years and not only did reviewers not catch on despite common complaints (and HardOCP) discussing the issue, but the company making the card was apparently completely blindsided by it after years and years of Crossfire sales. That's why people who own only one company's cards should try the other side to see that sometimes when someone says something like, "The nVidia cards are smoother in SLI than CF," sometimes--just sometimes--that's not fanboyism. Sometimes, it really is just smoother.No, I think the, "it took a competing company to shine a light on an issue," was more in reference to the fact that nVidia had to basically take AMD by the hand and slowly walk them through how to detect a problem highly prevalent on their products after years and years of waiting for them to get it.
They had to take out their own measurement software they built custom in-house and actually hand it over to the other team just to help them get it. This isn't typical competition teaching the other guy what to do.
This is like Pepsi-Cola taking Coca-Cola by the hand and saying, "Okay, so soda is supposed to have sugar and caffeine. Here is where you get it. Here is our supplier. Try it."
That's why he's saying it's sad. If AMD had figured it out on their own and fixed it, then yeah, that's competition because they FIGURED IT OUT. Instead, they didn't. It took TechReport slamming them on it with DATA after years of HardOCP just slamming them without data and thousands upon thousands of users saying, "Crossfire is not very good compared to SLI" and then nVidia hand delivering them FCAT for them to get it.
Before that, they were clueless. AMD is a company that produces discrete GPU's for the gaming market and not only did they have no clue how to test for this problem, they didn't even know there WAS a problem they were so clueless.
And that truly is very sad.
Galidou - Thursday, August 1, 2013 - link
Not sure that it was as much present in past products, I owned crossfire 6850s for a while then switched to a single 660ti to gain not much except lower temps and a little more FPS. Only game I could tell there was a real noticeable difference in smoothness was Skyrim and that was mainly because of thextures taking more than the mere 1gb my 6850s had.chizow - Friday, August 2, 2013 - link
Can't really agree with this, microstutter was documented and covered significantly in the German press for years, largely ignored by the NA press. 4870X2 microstutter problems were the first time the issue was really brought to light by PCGamesHardware, there's tons of documentation about it about if you search, here's the original test by PCGH:http://www.pcgameshardware.com/aid,653711/PCGH-pro...
Death666Angel - Saturday, August 3, 2013 - link
Multi GPU stuttering was well known about pretty much a few months into having multi GPU solutions. The issue with single GPUs also experiencing uneven frame pacing is much newer. And the believe among AMD was that it was an issue that affects AMD and nVidia equally, which is why they never thought about changing it in their drivers. Until Scott made the revelations.taltamir - Monday, August 5, 2013 - link
I personally documented single GPU multistuttering years ago (caused by lack of CPU power (C2D 8400, problem resolved going to a Q6600; using nvidia GPU), with hard data. (fraps individual frame render times record).I posted it on anandtech forums and there was a brisk discussion of it. It wasn't well known, but it shouldn't have completely blindsided the so called professionals. HisDivineOrder really said it best
chizow - Wednesday, August 7, 2013 - link
Yes I remember, there was a lot of user testing that stemmed from the initial reports on PCGH and the FRAPS frametime methodology became standard in allowing virtually any user who could download FRAPs and work a spreadsheet illustrating microstutter.I do agree though, the pros and press kept ignoring and sweeping it under the rug as if it didn't exist despite countless requests from end-users asking for more detail on it.