Revisiting the Radeon HD 7990 & Frame Pacing

Before we jump into our full benchmark suite, the launch of a new AMD dual-GPU card makes this an opportune time to revisit the state of frame pacing on AMD’s cards and to reflect on the Radeon HD 7990, so we’d like to take a moment to do just that.

When the 7990 launched last year, for AMD it came at an unfortunate time when the subject of frame pacing was finally coming to a head. With the incredibly coincidental release of NVIDIA’s FCAT tool it became possible to systematically and objectively measure frame pacing, and those findings showed that AMD’s frame pacing algorithms were significantly lagging NVIDIA’s. AMD Crossfire setups, including the 7990, were doing little if anything to mete out frames in an even manner, resulting in a range of outcomes from badly paced frames to dropping frames altogether. Worse, the problem was especially prevalent on multi-display Eyefinity setups, including the pseudo-multi-display methods that are used to drive 4K monitors at 60Hz even today.

The issue of frame pacing had been brewing for some time and AMD was quick to respond to concerns and agree that it needed addressed,  but the complex nature of the problem meant that it would take some time to fully resolve. The result of AMD’s efforts resulted in a series of phases of Crossfire frame pacing improvements. Phase 1 was released in August, 4 months after the launch of the 7990, and implemented better Crossfire frame pacing for games operating at or below 2560x1600.

The 2560x1600 limitation was a significant one, as this essentially limited AMD’s fixes to single-display setups and excluded Eyefinity and 4K setups. This limit in turn was directly related to the technical underpinnings of AMD’s GCN 1.0 (and earlier) GPUs, which used the Crossfire Bridge Interconnect to share data when using Crossfire. The CFBI offered just 900MB/sec of bandwidth, which was enough for 2560x1600 but nothing more. To move larger frames between GCN 1.0 GPUs, AMD has to undertake a much trickier process of involving the PCI-Express bus.

In the intervening period between then and now AMD has released their GCN 1.1 GPUs, which implement the XDMA block to specifically and efficiently handle frame transfers between GPUs. The end result of the XDMA block is that Hawaii based products – including the R9 295X2 – have no trouble with frame pacing. This in turn makes the R9 295X2 all the more important for AMD due to the fact that it’s the first dual-GPU video card from them to utilize this feature. Otherwise for the 7990 and other GCN 1.0 products, utilizing Crossfire with high resolutions involves a great deal more effort under the hood.

It was only finally in February of this year that AMD rolled out their Phase 2 driver, which implemented their high resolution frame pacing solution for pre-GCN 1.1 video cards. But since that same driver also launched support for AMD’s Mantle API and their Heterogeneous System Architecture, we haven’t had a chance to reevaluate AMD’s frame pacing situation until now. In our full benchmark section we’ll include a complete breakdown of frame pacing performance for both AMD and NVIDIA setups, but we first wanted to stop and take a look at frame pacing for pre-GCN 1.1 cards in particular.

So we’ve set out to answer the following question: now that AMD is supporting high resolution frame pacing on cards such as the 7990, has the 7990 been fully fixed?

The short answer, unfortunately, is that it’s a mixed bag. AMD has made significant improvements since we last evaluated frame pacing on the 7990 back at the 290X launch, which at the time saw the 7990 dropping frames left and right. But AMD has still not come far enough to truly fix the issue, as we’ll see.

We’ll starting off with our delta percentage data, which is the average difference in frame times as a percentage. In an ideal world this number would be 0, indicating that every frame was delivered in exactly as much time as the previous one, which would give us a perfectly smooth experience. In practice however this is impossible to achieve even in a single-GPU setup, let alone a multi-GPU setup. So for multi-GPU setups our cutoff is 20%; if a GPU can deliver a frame with a variance of no more than 20% of the time the previous frame took, then the frame delivery is consistent enough that gameplay should be reasonably smooth and below the bounds of human perception, even if it’s not perfect.

Radeon HD 7990 Delta Percentages (Catalyst 14.4 Beta)

The end result, as we saw back in August with Catalyst 13.8, is that AMD’s frame pacing situation has been brought under control in single-display (2560x1440 and lower) resolutions, as AMD was able to continue using the CFBI and merely changed their algorithms to better handle frame pacing.

However the state of frame pacing for high resolution Crossfire, when invoking the PCIe bus, is still fundamentally broken. Of the games we have that scale with multiple GPUs, the best game is Bioshock: Infinite with a 48.5% delta, 3x the variance of 2560x1440. It gets worse from there, going up as high as 70% for Thief. To be clear this is significant improvement over the 7990 that was dropping frames before AMD’s latest fix, but the deltas are still more than twice what we believe the cutoff should be.

Radeon R9 295X2 Delta Percentages (Catalyst 14.4 Beta)

The Radeon R9 295X2 by comparison fares much better. Not only are AMD’s deltas below 20% on everything but Crysis 3 (where it’s essentially skirting that value), but in most of our games the variance drops with the increased resolution, rather than massively increasing as it does with the 7990. This is the kind of chart we’d like to see for the 7990 as well, and not just the R9 295X2.

Our final graph is a plot of frame times on both cards on the main menu of Thief, showcasing how the cards compare and giving us a visual for just what’s going on. As our delta percentages picked up on, the 7990’s frame times are all over the place, with the card frequently cycling between 15ms frame times and 30ms frame times. This is as opposed to the R9 295X2, which is relatively consistent throughout.

What makes this all the more interesting though – and is something we’ve seen on other charts – is that the 7990’s variance drops towards the end. It’s still unquestionably worse than the R9 295X2 and exceeds our 20% threshold, but compared to the worst point on the chart it has come close to being halved.

This data indicates that for the pre-GCN 1.1 cards AMD is relying on some kind of long term adaptive timing mechanism that takes quite some time (at least a minute) to kick in. Only after which do AMD’s frame pacing mechanisms exert enough control to better regulate frame timings. We’ve known since the launch of the 290X that AMD is using some kind of short term adaptive timer for the 290X and single-display resolutions on pre-GCN 1.1 cards, but this is the first time we’ve seen a long term adaptive timer in use.

The end result is that in extended play sessions the frame pacing situation on the 7990 should be better than what we’re seeing with our relatively short benchmarks. However it also means that the initial frame pacing situation will be very bad and that in the best case scenario even after a few minutes the frame timing variance is still much higher than the 20% threshold it takes to make the frame times reasonably consistent.

To that end, though the 7990 is much improved, it’s hard to say that the frame pacing situation has been fixed. To be sure single-display is fine and has been fine since August, but even with AMD’s most recent changes the 7990 (and presumably other pre-GCN 1.1 cards) are still struggling to display frames at an even pace. Which for a card originally touted as the perfect card for 4K, is not a great outcome.

Meet the Radeon R9 295X2: Build Quality & Performance Expectations The Test
Comments Locked

131 Comments

View All Comments

  • Dustin Sklavos - Tuesday, April 8, 2014 - link

    Single cable is beyond spec for the connector. We've been hearing connectors actually melting. "Crappy" isn't really relevant here; this is the *only* card on the market that causes these kinds of problems.
  • Anders CT - Tuesday, April 8, 2014 - link

    500 watt power consumption is insane. It should come with an on-board dieselgenerator.
  • Blitzninjasensei - Saturday, July 12, 2014 - link

    The thought of this made my day. Thanks for the joke, needed it.
  • therfman - Tuesday, April 8, 2014 - link

    This is all very nice, but unless case space is at a premium, I fail to see the advantage of this card over two 290X cards with good coolers. The PowerColor PCS+ version of the 290X runs at 1050 MHz, is much quieter than the reference boards (40-42 dBA under load at 75cm), and is available for under $600. Is having a single-slot solution worth $300 extra? Not unless you really want have everything in a small form factor case.
  • Peeping Tom - Tuesday, April 8, 2014 - link

    Is that a giveaway I hear coming? ;-)
  • silverblue - Tuesday, April 8, 2014 - link

    Please, don't... I don't think I could stand to see a card of this calibre being offered only to those in the States... :|
  • JBVertexx - Tuesday, April 8, 2014 - link

    Is there any way to tell the temperatures of each of the two GPUs? Where does the temperature reading for the testing come from - is it an average of the 2, the hotter, or the cooler one?

    Reason I'm asking is I was skeptical a 120mm rad could effectively cool two of these GPUs. Given they are connected in series, one is bound to be measurably hotter than the other.

    Otherwise, this looks to be a winner. I was considering upgrading my uATX rig so I could do SLI. But with this card, I could keep the compact form factor.
  • JBVertexx - Tuesday, April 8, 2014 - link

    After some additional research on the web, it looks like the difference in temps between the 2 GPUs is only about 2 degrees under load, so pleasantly surprised with how well the 120mm radiator handles the cooling.
  • Ryan Smith - Tuesday, April 8, 2014 - link

    The temperature readings come from MSI Afterburner, which is capable of reading the temperatures via AMD's driver API. And unless otherwise noted, the temperature is always the hottest temperature.
  • srsbsns - Tuesday, April 8, 2014 - link

    The point of this driver was improvements the the HD7000 series and their rebrands... Anandtech missed this by benching an already optimized 290x dual card?

Log in

Don't have an account? Sign up now