• What
    is this?
    You've landed on the AMD Portal on AnandTech. This section is sponsored by AMD. It features a collection of all of our independent AMD content, as well as Tweets & News from AMD directly. AMD will also be running a couple of huge giveaways here so check back for those.
    PRESENTED BY

Catalyst 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.

In Summary: The Frame Pacing Problem The Test
POST A COMMENT

102 Comments

View All Comments

  • waldoh - Thursday, August 01, 2013 - link

    Its unfortunate it a competing company to shine light on an issue for another to address it. Reply
  • waldoh - Thursday, August 01, 2013 - link

    took* Reply
  • tackle70 - Thursday, August 01, 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.
    Reply
  • Rezurecta - Thursday, August 01, 2013 - link

    Excellent and well said. Reply
  • HisDivineOrder - Thursday, August 01, 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.
    Reply
  • Galidou - Thursday, August 01, 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. Reply
  • chizow - Friday, August 02, 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...
    Reply
  • Death666Angel - Saturday, August 03, 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. Reply
  • taltamir - Monday, August 05, 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
    Reply
  • chizow - Wednesday, August 07, 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.
    Reply

Log in

Don't have an account? Sign up now