In the last week several of you have emailed us about AMD’s Crossfire Eyefinity frame pacing driver – their so-called “phase 2” frame pacing driver – looking for a status update on AMD’s second major frame pacing fix. The last time we talked to AMD about the driver was in late September, at which time AMD told us at the time that they expected to have the driver out for a November release. November has since come and gone of course, meaning AMD has missed their previous deadline.

Since then we’ve been working on chasing down AMD to get a status update on the phase 2 driver, which they have finally provided. The long and the short of it is that the phase 2 driver has been delayed by roughly an additional two months, with AMD now expecting to have a public release of the phase 2 driver ready at some point in January. Note that January coincides with the CES and the launch of Kaveri (AMD’s first GCN desktop APU), so while AMD hasn’t provided any further guidance we wouldn’t be surprised if the roll-out was post-Kaveri, so that AMD doesn’t have to juggle multiple projects at once.

AMD didn’t provide any insight into the latest delay for the phase 2 driver, so at this point it’s not clear whether the delay is due to technical issues, labor/time issues, or a combination of both. From a public perspective AMD’s driver team has already had a busy last few weeks, having been occupied with post-launch tasks for the R9 290 series including pushing out a driver roughly once a week while also making some very fundamental changes to how fan speeds are handled on the 290 cards to reduce fan speed variance. At the same time Mantle is also still in development – the latest Battlefield 4 Mantle ETA is still this month – as AMD is still hammering out Mantle to prepare it for BF4 and for public development. So it goes without saying that we wouldn’t be the least bit surprised if there’s a manpower issue on AMD’s end, though in our admittedly self-interested point of view it seems to us that the phase 2 driver should be the highest priority item on AMD’s plate.

Anyhow, we’ll have more on the matter once AMD is ready to talk about it in full detail. Hopefully once we’re closer to the launch date AMD will be able to provide us with further information on how the phase 2 fix works. We know from the launch of the 290 series that AMD is going to need to pass frames over the PCIe bus – something the pre-GCN 1.1 cards lack the dedicated XDMA hardware for – so it will be interesting to see how AMD will be implementing this and how it impacts Crossfire performance.

POST A COMMENT

29 Comments

View All Comments

  • S3anister - Wednesday, December 11, 2013 - link

    All's well in the end, I suppose. A month or two really isn't that long to wait especially with the holidays here. Reply
  • DarkStryke - Wednesday, December 11, 2013 - link

    Yeah I mean, it's only been three years of crossfire being noticeably worse then SLI when used outside of artificial benchmarking. What's a couple more months Reply
  • beck2050 - Sunday, December 15, 2013 - link

    Exactly! It illustrates how serious a technical problem they have had in the multi GPU area that its taken so long and STILL no absolute remedy. The way AMD handled it also left a lot to be desired.
    Selling a flagship product that actually didn't work properly for years is not a way to improve one's reputation.
    Reply
  • mikato - Thursday, December 19, 2013 - link

    Seems like they acted pretty quickly to me once enough was known. Since you're complaining about 3 years, where were you to call them on it over those 3 years? Reply
  • milli - Wednesday, December 11, 2013 - link

    Is APU frame pacing also taken care of in phase 2 or that's for phase 3? Reply
  • Despoiler - Wednesday, December 11, 2013 - link

    Frame pacing is for Crossfire setups so neither. Reply
  • psuedonymous - Thursday, December 12, 2013 - link

    It depends on whether switching graphics between APU and discrete invokes this effect too. It shouldn't as the APU is only handling management of outputting frames passed to it by the dGPU rather than sharing any of the rendering itself, but I can't recall any testing done on this.

    For APU-only setups things should be fine though.
    Reply
  • PerroLito - Wednesday, December 11, 2013 - link

    Although linux is never covered at AT, it should be noted that despite still being lower performance, AMDs open source linux driver is much smoothier with regard to frame latency than catalyst.
    http://www.phoronix.com/scan.php?page=article&...
    Reply
  • The Von Matrices - Wednesday, December 11, 2013 - link

    Thank you for checking into this Ryan.

    No thank you to AMD.

    This is ridiculous. It's been almost a year since AMD talked about introducing frame pacing, and yet it's still extremely limited in scope. As an owner of three 7970s and three monitors, I couldn't be more frustrated. AMD has been this way for most of the products in the past half decade - make a promise about performance or release schedule, then not hold up to that promise and pretend nothing is wrong. If it weren't for AMD's advantage in cryptocurrency mining I would have ditched these cards long ago.

    What's even more worrying is that AMD is making its graphics drivers even more complicated with Mantle support and TrueAudio. The company can't even fix issues in its current features and it's putting more duties on its driver team?!
    Reply
  • jasonelmore - Thursday, December 12, 2013 - link

    you still mine cryptocurrency with Graphics Cards? i thought it was pointless. at least bitcoin is pointless. Reply

Log in

Don't have an account? Sign up now