AMD Frame Pacing Explored: Catalyst 13.8 Brings Consistency to Crossfire
by Ryan Smith on August 1, 2013 2:00 PM ESTCatalyst 13.8 Beta 1: The First Multi-GPU Frame Pacing Driver
The culmination of AMD’s first wave of efforts to manage frame pacing is the Catalyst 13.8 driver (driver branch 13.200). Being released in beta form today, the marquee feature for this driver is the new frame pacing mechanism for Crossfire setups. As with any major new driver branch this also includes some other improvements, and while we don’t have the complete release notes, AMD has mentioned that these drivers will bring about full OpenGL 4.3 compliance (apparently they were missing a couple of items before).
AMD is calling this driver “phase 1” of their frame pacing solution, and for good reason. In implementing frame pacing AMD has tackled the issue in what’s very obviously a triage-like manner, focusing on the most important/significant problems and working out from there. So what’s addressed by this first driver resolves AMD’s biggest issues, but not all of them.
So what’s being addressed in phase 1? Phase 1 is being dedicated to Direct3D 10+ games running on a single display. What’s not being addressed in the first driver are the Direct3D 9 and OpenGL rendering paths, along with Eyefinity in any scenario.
It goes without saying that in an ideal would we would have liked to see AMD hit everything at once, but if they couldn’t do it all at once then choosing to tackle D3D10+ games first was the next best move they could make. This covers virtually all of the games present and future that are graphically challenging enough to weigh down a high-end Crossfire setup. D3D9 games by and large are not that demanding on this class of hardware – we’d have to resort to Skyrim mods to find a D3D9-exclusive title that isn’t CPU limited and/or gets less than 90fps off of a single GPU. OpenGL has even less traction, the last OpenGL game of note being 2011’s Rage which is capped at 60fps and easily hits that at 1080p on even 7800 series hardware.
Catalyst 13.8 Frame Pacing | |||||
Single Display | Eyefinity | ||||
D3D11 | Y | N | |||
D3D10 | Y | N | |||
D3D9 | N | N | |||
OpenGL | N | N |
It’s Eyefinity users who will be the most unfortunate bunch at the moment. Eyefinity is one of the premiere usage scenarios for Crossfire because of the amount of GPU horsepower required, however it’s also the most complex scenario to tackle – splitting work across multiple GPUs and then multiple display controllers – compared to the fairly low user uptake. More so than with D3D9 and OpenGL AMD does need to get Eyefinity sorted and quickly, but for the moment single display setups are it. On that note, 4K displays are technically also out, since the current 60Hz 4K displays actually present themselves as two displays, with video cards addressing them via Eyefinity and other multi-monitor surround modes.
On the plus side, since this is a purely driver based solution, AMD is rolling out frame pacing to all of their currently supported products, and not just the 7000/8000 series based GCN parts. This means 5000 and 6000 series Crossfire setups, including multi-GPU cards like the 5970 and 6990, are also having their pacing issues resolved in this driver. Given the limited scope of this driver we were afraid it would be GCN-only, so this ended up being a relief.
Moving on, let’s dive into the new driver. True to their word, AMD has made the new frame pacing mechanism a user controllable option available in the Catalyst Control Center. Located in the CrossfireX section of the 3D Application Settings page and simply titled “Frame Pacing,” it defaults to on. Turn it off and AMD’s rendering behavior reverts to the low-lag behavior in previous drivers.
As far as technical details go, AMD has not offered up any significant details on how their new frame pacing mechanism works. Traditionally neither AMD nor NVIDIA have offered a ton of detail into how they implement AFR under the hood, so while unfortunate from an editorial standpoint it’s not unexpected. Hopefully once AMD finishes the other phases and enabling the new frame pacing mechanism elsewhere, we’ll be able to get some solid details on what AMD is doing to implement frame pacing. So for the moment we only have the barest of details: AMD is delaying frames as to prevent any frame from being shown too early, presumably relying on backpressure in the rendering queue to stabilize and keep future frames coming at a reasonable pace.
With that said, based on just the frame time measurements from our benchmark suite we can deduce a bit more about what AMD is doing. Unlike NVIDIA’s “organic” approach, which results in frame times that follow a similar pattern as single-GPU setups but with far wider variation, the frame times we’re seeing on 13.8 have a very distinct, very mechanical metered approach.
Accounting for some slight variation due to how back buffer swapping works, what we see are some very distinct minimum frame time plateaus in our results. Our best guess is that AMD is running some kind of adaptive algorithm which is looking at a window of rendering times and based on that is enforcing a minimum frame time, ultimately adjusting itself every few seconds as necessary. NVIDIA doesn’t implement something quite like this, but beyond that we don’t know how the two compare algorithmically at this time. However regardless of their differences what we’re ultimately interested in is how well each mechanism works.
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.krutou - Friday, August 2, 2013 - link
BUT, BUT, BUT, RADEON PRO?!?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".
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.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.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.
Wreckage - Thursday, August 1, 2013 - link
It did not help that certain people were claiming that AMD does not have a stutter problem.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.
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.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.