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
Comments Locked

102 Comments

View All Comments

  • chizow - Friday, August 2, 2013 - link

    No it makes perfect sense. Use a camera if you have to capture how the frames are updated with Vsync Off normally. You will see the "tear" or refresh line differs from frame to frame, with either the top or bottom being refreshed relative to the previous frame. The key distinctions vs runtframes are that the next frame updates where the last one left off and there is significant differentiation between the frames, giving the sense of motion, with tearing.

    Unlike with runtframes, every other frame is a runt or partial followed by a more fully formed frame, so you basically get the effect of 2 similar frames followed by an updated frame due to the runt. This results in the irregular cadence known commonly as microstutter.

    Please see the videos here at PCPer to better understand, all videos were done with Vsync Off, and as you can clearly see, Vsync Off with runts and without are clearly not the same thing.

    http://www.pcper.com/reviews/Graphics-Cards/Frame-...
  • krutou - Friday, August 2, 2013 - link

    Runts are due to screen tearing...

    What isn't shown in most reviews because it is difficult to evaluate objective, but the most apparent to the average user is animation smoothness. PC Perspective had a whole slew of videos comparing CF to SLI over most 7000 and 600 series cards and the difference in smoothness between the two solutions was obvious, even though there was no screen tearing.
  • vegemeister - Monday, August 5, 2013 - link

    Agreed. It seems to me that this whole kerfuffle is two camps debating what kind of garbage output they'd rather see. The only reasonable way to use frame time logs in a review is discussing the percent of frames that take "too long" at a variety of refresh rates (144Hz, 120Hz, 85Hz, 60Hz, 48Hz, 30Hz, and 20Hz would be a good sampling). Perhaps you would also scale to the refresh rate, to examine how frequently a user would likely see dropped frames.
  • Omoronovo - Thursday, August 1, 2013 - link

    Fantastic article Ryan.

    I did however have a query regarding the comments made regarding the odd issue of FCAT recording high dropped frames and the changes you implemented to prevent this error skewing results. Did you re-run any of the tests on the nVidia results to see if the changes you made to fcat had any noticeable change in the results generated from nVidia cards? Particularly regarding runt frames; as you mention yourself, AMD has reduced runt frames to zero in many cases which is an impressive achievement if accurate, and I would hope by redoing the tests on nVidia data that it proves to remain true (rather than skewing nVidia results as well, which would indicate that the FCAT changes to fix one problem would introduce variancy in the comparion outside the changes made in the driver).

    Like usual, fantastic article from Anandtech, and you in particular Ryan. Hope to read more articles from you soon.
  • Ryan Smith - Thursday, August 1, 2013 - link

    Indeed I did, and it made no difference on NVIDIA cards. The FCAT miscounts only occur on AMD cards with the frame buffer issue as outlined in the article.
  • airmantharp - Thursday, August 1, 2013 - link

    Thanks for the great work Ryan-

    I'm still waiting for TR's results to put this all into perspective (always need multiple datapoints), but this bodes very well for those looking at 4k setups in the future. Before this driver was proven, AMD wasn't even in the running, regardless of price.
  • TheJian - Friday, August 2, 2013 - link

    The statements here are hilarious (expect nothing less from Ryan these days). He frames it as a 7990 problem, but in reality it was every pair of AMD cards you could throw at a PC. ALL MULTI-GPU situations on AMD are affected and have been for at least a year and a half (always?). 2x7950, 2x7970 etc etc...

    And 7990 wasn't a rough launch. It was awful. We are still waiting for Ryan's FCAT articles. I expect we'll start to see more now, just as I said before many times, AFTER AMD FIXES their problems. Here we are...LOL. No bias at anandtech though...ROFL. Still missing FCAT part 2 article from march. IT was promised in 2 weeks, never happened. Tons of FCAT results left out of most articles due to drivers changing, game problems, patches etc...blah blah...PCper does it for every article and had NONE of these issues. Hmm...Funny that...

    This leaves us with 2 options:
    1. You're either too dumb to use the tool and should just lose your job (say it ain't so).
    2. You're hiding the truth from your users and should have your traffic reduced further as Alexa shows it's off half or so since the 660TI article in sept last year when Ryan said silly things like 'a lot of people are buying Catleap 1440p monitors from ebay from some dude in korea'...ROFL. Umm, no they are not. Still not many today since even in your own 1440p article (again with ridiculous conclusions like buy an AMD A8-5600 for any single gpu card - no Buy Intel!) shows the steam hardware survey which shows less than 1.25% of us use above 1920x1200 and most of those use TWO video cards...LOL.

    No driver launch should be important for a company...ROFL. It's extremely important we don't HAVE TO TALK about your crappy drivers because they didn't take a year or two to make them work. Right? The important thing is that the product is launched WORKING out of the box as advertised.

    "What’s not being addressed in the first driver are the Direct3D 9 and OpenGL rendering paths, along with Eyefinity in any scenario."

    So it's still not working for some people in multiple scenarios (all xp users right? They all use DX9). You act as though high FPS=stutter free. NOT SO. Just because you're hitting 60fps in rage or 90fps etc, that does not mean the customer isn't affected. The problem is SEEING the stutter, not if the game is fast enough when it ISN'T stuttering.

    "and is periodic to the point where it occurs at most a few times per minute."
    So a few times per minute you have to deal with this...Get back to work AMD. NV doesn't do this.

    To summarize, AMD is still stuttering a lot at 20% (assuming you picked 15-20 so they could squeak inside for most games...LOL). But reality is they only made it UNDER 20 for 2 games of the 6 right? BF3 and Crysis3, otherwise they are STILL over even your worst end at 20% (nowhere near 15 on the low-end of that range right?). Also note the card runs 5-10% slower now.

    http://www.pcper.com/reviews/Graphics-Cards/Frame-...

    Better off reading the article at PCper above. AMD said Ryan Shrout was wrong 1/2 dozen times...LOL. That's changed now :) Also as they show Skyrim is affected with or without mods even with the new driver. But the point on this is you don't have to mod it to see stutter.

    Pcper also shows it's been affecting 7970CF (and all other CF users) for ages up to now. Finally they get some relief. However TRIPLE card owners still suffer the same problems:
    "there is a lot of work AMD can do to improve the experience for users tripling their investment."
    "I will be curious if its even possible for AMD to fix the frame pacing issues with CrossFire and Eyefinity this generation.

    Even worse though is that with all the excitement over 4K displays and in particular the ASUS PQ321Q 4K 60 Hz monitor I recently reviewed, the Eyefinity limitation will pop up again in this niche case too. "

    So due to bandwidth he doesn't even think they'll be able to fix this..OUCH AMD. An even bigger OUCH to AMD buyers. He notes in the same paragraph AMD didn't want to discuss it (shocking). WOW.
    "Not only does this driver validate everything we have worked on for the last two years but the fact that AMD has decided to enable the frame pacing fix by default emphasizes that fact even more."

    Funny anandtech didn't start saying anything until March and remained mum on FCAT stuff basically until the fix just as I said they would do.

    http://hardocp.com/article/2013/08/01/amd_catalyst...
    Hardocp isn't as kind to AMD either IMHO.
    "Far Cry 3 was the most inconsistent and choppy. Even with Frame Pacing turned on, it was stuttery feeling, but this lagginess was reduced slightly with Frame Pacing."

    Still having issues.
    "This is definitely a foot forward in the right direction from AMD though, but work still needs to be done."

    Let me know when AMD gets done with all these PHASES so users actually get a REAL DONE driver that should have been in the box or downloadable all along. Working products people, is the reason NV owns 65% of the discrete gpu market today despite all the free games AMD gives away to get you to buy & wait for their drivers to work (which also happens to be why they make ZERO on their gpu division). No mention of AMD's quarterly report again here...Too depressing I guess now. I expect Ryan to cover their Q report again if consoles make them some cash...LOL. But he'll continue to refuse to cover NV's quarters because all that shows is they are giving AMD a whipping in each one.

    Some hardocp conclusions:
    "It also has to be said that NVIDIA has been doing this for years. Though we don't know the exact name for what it does in its drivers, it is known that NVIDIA is doing something to smooth out frame times and make SLI feel good while gaming. There is a reason that we have been saying for years how NVIDIA SLI felt smoother. AMD is just now playing catch up, and it is quite late in the game in our opinion to be playing this kind of catch up. In our opinion this type of technology should have employed years ago. If AMD is serious about improving the gameplay experience, this is one area that needs a lot of attention."
    "In our personal gaming observations, we still observe that NVIDIA SLI is smoother and more consistent than AMD CrossFire with Frame Pacing."
    "AMD has improved its own consistency. We still feel that it lags behind whatever NVIDIA is doing."

    Years later AMD finally getting in the game. Jeez. I'll also remind you ~38% of the public is STILL running windows XP so all of these are forced to DirectX 9 paths. So all of them should by Nvidia cards correct? That sort of blows your whole DirectX9 exclusive (as if nobody would run there) titles out of the water. They don't have to be exclusive if the person running the game can't run dx10 or dx11 (at that point it's DIRECTX 9 exclusive for an XP user right?). Get it? Of course you do Ryan, but it sounded better for AMD saying 'um, well, this never happens so who cares about phase two, everyone is solved today'...I digress...
  • boozed - Friday, August 2, 2013 - link

    What happened in your life to cause you to be so bitter and mean?
  • TheJian - Tuesday, August 6, 2013 - link

    No argument with the data though ;) It's comic the first things people do when there is no argument against the data is a personal attack. So stating the facts means you're bitter and mean to you?

    https://en.wikipedia.org/wiki/Ad_hominem
    Please review the chart from Graham, then come back with something at the top of his pyramid instead of the bottom :)
  • DeviousOrange - Friday, August 2, 2013 - link

    TL;DR maybe someone will give you the F&*#s you wanted in posting this crap but im allegic to fanboy troll.

Log in

Don't have an account? Sign up now