Drivers & ISV Relations

As we noted last week with the release of the Catalyst 12.1 preview, AMD has a lot of technical and reputational debt to dig themselves out of when it comes to their Catalyst drivers. AMD dropped the ball this fall a number of times, failing to deliver on appropriate drivers for Rage, Battlefield 3, and The Elder Scrolls V: Skyrim in a timely manner. This isn’t something AMD is shying away from either – they know they screwed up and they’ll admit as much – but the question remains of how they intend to improve from there. Now that they once again have the leading single-GPU video card they need to have the leading drivers to run it.

Part of this redemption will come from the addition of new features, if only to reach parity with NVIDIA. Catalyst 12.1 introduced custom application profiles, while as we discussed with Eyefinity, Catalyst 12.2 will add to AMD’s suite of Eyefinity features with custom resolutions and the ability to relocate the Windows task bar. Furthermore AMD has features in the development pipeline for their Catalyst drivers for introduction later this year, but at this point it’s too early to talk about them.

 

But new features alone can’t fix every single thing that has ailed AMD in the past year, so the question remains: how does AMD intend to fix their poor delivery of optimized drivers for new games? It’s a question AMD cannot (or will not) completely answer in detail, but it’s a question for which there’s at least part of an answer.

The fundamental answer is more. More developers, more quality assurance, and above all more money. By all accounts NVIDIA sinks a lot of money into driver development and ISV and it usually shows. AMD is going to spend more resources on driver development at home and this is going to help a great deal, but at the same time it would seem that they’ve finally come to realize that great ISV relationships require that AMD be more proactive than how they’ve been in the past.

ISV relations covers a large umbrella of activities. Not only does this mean providing support to developers who request it, but it means providing cross-promotion marketing, encouraging developers to make use of your features (if only to help spur the creation of the killer app), and actively seeking out important development houses so that AMD’s interests and concerns are represented and represented early. It’s been said that the most important thing NVIDIA ever did with ISV relations was to send out their own engineers to development houses on their own dime to provide free support – essentially investing at least a small amount of money into a major game. The payoff of this was that NVIDIA was literally there to represent their interests, and conversely they had a chance to evaluate the game early and get to work on optimizations and SLI support well before it shipped. Snark about TWIMTBP aside, that’s where NVIDIA has raised the bar with ISV relations. That’s what AMD needs to follow.

To that extent AMD has reorganized the budget process for their ISV relations department. Neal Robison, the director of ISV relations, now directly controls a much larger ISV relations budget, whereas previously the ISV relations budget was apparently controlled by several parties. Having more funding for ISV relations won’t solve AMD’s issues on its own – It’s all about how that money is spent – but clearly AMD is on the right path by being able to afford to be more proactive about their ISV relationships.

Whether these changes will pay off as AMD is expecting them to remains to be seen, but from our discussions it’s apparent that AMD is trying harder than ever before. A great product requires good hardware and good software; AMD has the former in Tahiti, now it’s time to see if they can deliver on the latter.

Closing out the subject of drivers, AMD is also using the Southern Islands launch to outline their plans for Windows 8. AMD is promising that they will deliver drivers for Windows 8 on the same schedule as they have for Windows 7 and Windows Vista – new drivers will be available for the Windows 8 Beta, RC, and RTM releases. Furthermore as Microsoft has continually iterated on the WDDM driver stack since Vista, AMD will continue to be able to offer a single unified driver that covers all of the WDDM OSes (Vista, 7, and 8).

Image Quality: Anisotropic Filtering Tweaks & Tessellation Speed Meet the Radeon HD 7970
Comments Locked

292 Comments

View All Comments

  • CeriseCogburn - Thursday, March 8, 2012 - link

    Interesting, amd finally copied nvidia...
    " This problem forms the basis of this benchmark, and the NQueen test proves once more that AMD's Radeon HD 7970 tremendously benefits from leaving behind the VLIW architecture in complex workloads. Both the HD 7970 and the GTX 580 are nearly twice as fast as the older Radeons. "

    When we show diversity we should also show that amd radeon has been massively crippled for a long time except when "simpleton" was the key to speed. "Superior architecture" actually means "simple and stupid" - hence "fast" at repeating simpleton nothings, but unable to handle "complex tasks".
    LOL - the dumb gpu by amd has finally "evolved".
  • chizow - Thursday, December 22, 2011 - link

    ....unfortunately its going to be pitted against Kepler for the long haul.

    There's a lot to like about Southern Islands but I think its going to end up a very similar situation as Evergreen vs. Fermi, where Evergreen released sooner and took the early lead, but Fermi ultimately won the generation. I expect similar with Tahiti holding the lead for the next 3-6 months until Kepler arrives, but Kepler and its refresh parts winning this 28nm generation once they hit the streets.

    Overall the performance and changes AMD made with Tahiti look great compared to Northern Islands, but compared to Fermi parts, its just far less impressive. If you already owned an AMD NI or Evergreen part, there'd be a lot of reason to upgrade, but if you own a Fermi generation Nvidia card there's just far less reason to, especially at the asking price.

    I do like how AMD opened up the graphics pipeline with Tahiti though, 384-bit bus, 3GB framebuffer, although I wonder if holding steady with ROPs hurts them compared to Kepler. It would've also been interesting to see how the 3GB GTX 580 compared at 2560 since the 1.5GB model tended to struggle even against 2GB NI parts at that resolution.
  • ravisurdhar - Thursday, December 22, 2011 - link

    My thoughts exactly. Can't wait to see what Kepler can do.

    Also...4+B transistors? mind=blown. I remember when we were ogling over 1B. Moore's law is crazy.... :D
  • johnpombrio - Wednesday, December 28, 2011 - link

    Exactly. If you look at all the changes that AMD did on the card, I would have expected better results: the power consumption decrease with the Radeon 7970 is mainly due to the die shrink to 28nm. NVidia is planning on a die shrink of their existing Fermi architecture before Kepler is released:

    http://news.softpedia.com/news/Nvidia-Kepler-Is-On...

    Another effect of the die shrink is that clock speed usually increases as there is less heat created at the lower voltage needed with a smaller transistor.

    The third change that is not revolutionary is the bump of AMD's 7970's memory bus from 384 bits (matching the 580) from the 6970's 256 bits along with 3GB DDR5 memory vs the GTX580's 1.5GB and the 6970's 2GB.

    The final non revolutionary change is bumping the number of stream processors by 33% from 1,536 to 2,048.

    Again, breaking out my calculator, the 35% bump in the number of stream processors ALONE causes the increase in the change in the benchmark differences between the 7970 and the 6970.

    The higher benchmark, however, does not show ANY OTHER large speed bumps that SHOULD HAVE OCCURED due to the increase in the memory bus size, the higher amount of memory, compute performance, texture fill rate, or finally the NEW ARCHITECTURE.

    If I add up all the increases in the technology, I would have expected benchmarks in excess of 50-60% over the previous generation. Perhaps I am naive in how much to expect but, hell, a doubling of transistor count should have produced a lot more than a 35% increase. Add the new architecture, smaller die size, and more memory and I am underwhelmed.
  • CeriseCogburn - Thursday, March 8, 2012 - link

    Well, we can wait for their 50%+ driver increase package+ hotfixes - because after reading that it appears they are missing the boat in drivers by a wide margin.
    Hopefully a few months after Kepler blows them away, and the amd fans finally allow themselves to complain to the proper authorities and not blame it on Nvida, they will finally come through with a "fix" like they did when the amd (lead site review mastas) fans FINALLY complained about crossfire scaling....
  • KaarlisK - Thursday, December 22, 2011 - link

    What is the power consumption with multiple monitors? Previously, you could not downclock GDDR5, so the resulting consumption was horrible.
  • Ryan Smith - Thursday, December 22, 2011 - link

    "On that note, for anyone who is curious about idle clockspeeds and power consumption with multiple monitors, it has not changed relative to the 6970. When using a TMDS-type monitor along with any other monitor, AMD has to raise their idle clockspeeds from 350MHz core and 600Mhz memory to 350MHz core and the full 5.5GHz speed for memory, with the power penalty for that being around 30W. Matched timing monitors used exclusively over DisplayPort will continue to be the only way to be able to use multiple monitors without incurring an idle penalty."
  • KaarlisK - Thursday, December 22, 2011 - link

    Thank you for actually replying :)
    I am so sorry for having missed this.
  • ltcommanderdata - Thursday, December 22, 2011 - link

    Great review.

    Here's hoping that AMD will implement 64-bit FP support across the whole GCN family and not just the top-end model. Seeing AMD's mobile GPUs don't use the highest-end chip, settling for the 2nd highest and lower, there hasn't been 64-bit FP support in AMD mobile GPUs since the Mobility HD4800 series. I'm interested in this because I can then dabble in some 64-bit GPGPU programming on the go. It also has implications for Apple since their iMacs stick to mobile GPUs, so would otherwise be stuck without 64-bit FP support which presumably could be useful for some of their professional apps.

    In regards to hardware accelerated Megatexture, is it directly applicable to id Tech 5's OpenGL 3.2 solution? ie. Will id Tech 5 games see an immediate speed-up with no recoding needed? Or does Partially Resident Texture support require a custom AMD specific OpenGL extension? If it's the later, I can't see it going anywhere unless nVidia agrees to make it a multivendor EXT extension.
  • Ryan Smith - Thursday, December 22, 2011 - link

    Games will need to be specifically coded for PRT; it won't benefit any current games. And you are correct in that it will require and AMD OpenGL extension to use (it won't be accessible from D3D at this time).

Log in

Don't have an account? Sign up now