AMD’s Catalyst 11.1a Hotfix

If the first 2 legs of AMD’s GTX 560 Ti counter-offensive were the 6950 1GB and factory overclocked 6870s, then the final leg of that offensive are the drivers. With barely a month between the launch of the 6900 series and today, AMD has only delivered their original launch drivers for the 6900 series. Meanwhile the 6800 series launched with the Catalyst 10.10 hotfix drivers, which due to how AMD organizes their driver branches are little different than the 10.12 drivers currently posted. So in spite of the nearly 2 month gap between the launches of these two card families, AMD is effectively providing the first real driver update for both.

Launching tomorrow will be the Catalyst 11.1a Hotfix drivers. As far as performance goes they contain the usual mix of game-specific performance improvements, with AMD specifically targeting Call of Duty: Black Ops, BattleForge, Metro 2033, and Aliens vs. Predators performance among other games. Having tested these drivers, overall we’re not seeing any significant performance impact in our benchmark suite, even with games that area on AMD’s list. In fact the only area where we are seeing a major change is with our SmallLuxGPU compute benchmark, which looks to be on the receiving end of some shader compiler optimizations by AMD. SLG performance on the 6900 series is up 25%-30%, providing some validity to AMD’s earlier claims that their VLIW4 shader compiler still has some room to grow as AMD learns how to optimize it like they did with the VLIW5 compiler in the past.

The bigger news is what AMD is doing to their control panel, and what it means to you.

Let me first introduce you to a new section of AMD’s 3D Application Settings control panel called Tessellation. With this new control panel feature AMD is implementing a tessellation factor override in to their drivers, allowing AMD and/or the user to clamp down on games and applications using high tessellation factors. The purpose of this feature is to deal with games such as HAWX 2, which uses very high tessellation factors and offers no tessellation configuration besides turning the feature on and off.

As we’ve already well established, NVIDIA has much better tessellation performance than AMD at high tessellation factors even with the 6900 series. This position leaves AMD on the defensive much of the time (“they’re overpowered” doesn’t have the same ring as “they’re underpowered”), but more so than that games like HAWX 2 are particularly damaging to AMD; they don’t just make AMD’s hardware underperform, but they leave users with only the option to accept poor tessellation performance or to turn tessellation off altogether.

The crux of AMD’s argument – and a point that we agree with – is that tessellation is supposed to be easily scalable. It is in fact the basis of tessellation, that a developer can use it to easily scale up a model based on the available hardware, using a combination of mip-chained displacement maps and an appropriate tessellation factor. The end-game of this scenario would be that a game would use low amounts of tessellation on low-end hardware (e.g. APUs), and large amounts of tessellation on high-end hardware such as GeForce GTX 580s and Radeon HD 6970s. But for that to happen game developers need to take advantage of the flexibility of tessellation by having their games and engines use multiple tessellation factors and displacement maps.

Ultimately games like HAWX2 that do not implement these kinds of controls are not easily scalable. This is the choice of the developer, but in long standing tradition both AMD and NVIDIA will override developer wishes in their drivers when they see fit. In this case AMD believes they are helping their customers by having their drivers cap the tessellation factor in some situations, so that their customers can use tessellation without very high tessellation factors bogging down performance.

And while we agree with AMD’s argument, AMD’s implementation leaves us uneasy. Having this feature available is great, just as is the ability to override v-sync, purposely use poor texture filtering quality for speed purposes, and clamping LOD biases .The bit that makes us uneasy is where the default will lie. AMD offers 3 different “modes”: AMD Optimized, which uses an AMD chosen tessellation factor, user control, and Use Application Settings. AMD intends to make the default “AMD Optimized”, which is to say that in the future all games would use the tessellation factor AMD chooses.

We sincerely believe AMD is doing what they think is best for their users even if they also stand to gain in benchmarks, however we find ourselves in disagreement with their choice. While the actions of games like HAWX2 are unfortunate for users, tessellation is well defined in the DirectX 11 specification. We’re more than willing to entertain creative interpretations of matters like texture filtering where the standard doesn’t dictate a single filtering algorithm, but DX11 doesn’t leave any ambiguity here. As such there’s little room in our opinion for drivers to override a game’s request by default. Drivers should not automatically be substituting a lower tessellation factor on their own – this is a power that should be reserved for a user.


Tessellation in action

Admittedly this is a minefield – modern GPUs are all about taking shortcuts, as these are necessary to get reasonable performance with the kind of complexity modern games are shooting for. But it’s our opinion that there’s no better time to take a stand than before an optimization like this is implemented, as once it’s done then it’s almost impossible to change course, or even to have a meaningful discourse about the issue.

At this time AMD has not defined any tessellation factors in their profiles, and as a result the AMD Optimized setting is no different than the Use Application Settings setting. At some point this will change. We would like to see AMD build this feature in to their drivers and leave the choice up to the user, but only time will tell how they proceed.

On that note, tessellation factors are not the only minefield AMD is dabbling in. With the Catalyst 10.10 drivers AMD began playing with their texture filtering quality at different levels. Previously at High Quality (previously known as Catalyst AI Off) AMD would disable all optimizations, while at the default setting of Quality (Catalyst AI Standard) AMD would use a small set of optimizations that had little-to-any impact on image quality, and at Performance (Catalyst AI Advanced) they would use a number of optimizations to improve performance. Texture filtering optimizations are nothing new (having been around practically as long as the 3D accelerator), but in a 2-player market any changes will make a wave.

In the case of AMD’s optimizations, for Quality mode they picked a new set of optimizations that marginally improved performance but at the same time marginally changed the resulting image quality. Many tomes about the issue have already been written, and there’s very little I believe we can add to the subject – meaningful discourse is difficult to have when you believe there’s room for optimizations while at the same time believing there is a point where one can go too far.


AMD Radeon HD 6870, Catalyst 10.10e

In any case while we have found very little to add to the subject, this has not been the case elsewhere on the internet. As such after 3 months AMD is largely reverting their changes to texture filtering, and will be returning it to similar quality levels as what we saw with the Catalyst 10.9 drivers – which is to say they’re now once again shooting for a level of texture filtering quality similar to NVIDIA.

As we have little to add beyond this, here are AMD’s full notes on the matter:

The Quality setting has now been improved to match the HQ setting in all respects except for one – it enables an optimization that limits trilinear anisotropic filtering to areas surrounding texture mipmap level transitions, while doing bilinear anisotropic filtering elsewhere.  Sometimes referred to as “brilinear” filtering, it offers a way to improve filtering performance without visibly affecting image quality.  It has no impact on texture sharpness or shimmering, and this can be verified by comparing it visually with the High Quality setting.

We continue to recommend the Quality setting as the best one to use for competitive testing for the following reasons:

  • It should be visually indistinguishable from the High Quality setting for real textures (with the exception of special test patterns using colored mip levels)
  • Visual quality should now be equal to the default setting used on HD 5800 series GPUs with Catalyst 10.9 and earlier drivers, or better when used on HD 6800/6900 series GPUs due to other hardware filtering improvements
  • It matches the default texture filtering quality setting currently implemented on our competitor’s GPUs, which make use of the same trilinear filtering optimization
Meet The Radeon HD 6950 1GB and XFX Radeon HD 6870 Black Edition The Test & Gaming Performance
Comments Locked

111 Comments

View All Comments

  • Stuka87 - Tuesday, January 25, 2011 - link

    Why does every single ATI card get the EXACT same FPS in Civilization 5? Did the company that made it get paid off by nVidia to put a frame cap on ATI cards or what? It makes zero sense that 2 year old ATI cards would get the same FPS as just released ATI cards.

    So... What gives?
  • Ryan Smith - Tuesday, January 25, 2011 - link

    Under normal circumstances it's CPU limited; apparently at the driver level. Just recently NVIDIA managed to resolve that issue in their drivers, which is why their Civ 5 scores have shot up while AMD's have not.
  • Stuka87 - Wednesday, January 26, 2011 - link

    Hmm, interesting.
  • WhatsTheDifference - Wednesday, January 26, 2011 - link

    please forgive me, Ryan, as I know this sounds abrasive and a little too off-topic from your response here. but speaking of 'score', what's the absolutely mind-boggling delay with including the 4890. quite frankly, if even one of any performance test over the relevant life of the 285 had not the 285 in it, nvidia would burn this site to the ground right after your nvidia-supporting readers did some leveling of their own. so honestly, for every 2xx series that finds its way into a benchmark, where in the world is ATI's top pick of that generation? site regs have posted about anandtech's nvidia-leaning ways, say, a few times, and this particularly clear evidence rather deserves an explanation - in my opinion. or, my spotty attendance contributed to missing at least one fascinating story.
  • 7Enigma - Wednesday, January 26, 2011 - link

    4870 has been in most of the tests (see launch article) which can be used as a slightly lower-performing card. Use that as a guide.
  • erple2 - Thursday, January 27, 2011 - link

    I agree with 7Enigma - the difference between the 4870 and 4890 are no longer significant enough to warrant inclusion in the comparison. I seem to recall that the performance of the 4890 was between the 4870 (shown) and the nvidia 285 (also shown). Couple that with the relative trouncing 30%+ increase in performance) that the newer cards deliver to the GTX285, plus that the frame rates of the GTX285 isn't that high (+30% of 20 fps is 26 fps, which is still "too slow to make it relevant"), I'm not sure that it becomes relevant anymore.
  • cheese319 - Tuesday, January 25, 2011 - link

    It should be easily possible to unlock the card through manually editing the bios to unlock the extra shaders (like what is possible with the 6950 2gb) which is a lot safer for the ram as well.
  • mapesdhs - Tuesday, January 25, 2011 - link


    Talk about not being consistent. :\ Here we have a review that
    includes an oc'd 6870, yet there was the huge row before about the 460
    FTW. Make your minds up guys, either include oc'd cards or don't.
    Personally I would definitely like to the see the FTW included since
    I'd love to know how it compares to the new 560 Ti, given the FTW often
    beats a stock 470. Please add FTW results if you can.

    Re those who've commented on certain tests reaching a plateau in some
    cases: may I ask, why are you running the i7 at such a low 3.33GHz
    speed?? I keep seeing this more and more these days, review articles on
    all sorts of sites using i7 CPU speeds well below 4, whereas just about
    everyone posting in forums on a wide variety of sites is using speeds
    of at least 4. So what gives? Please don't use less than 4, otherwise
    it's far too easy for some tests to become CPU-bound. You're reviewing
    gfx cards afterall, so surely one would want any CPU bottleneck to be
    as low as possible?

    Any 920 should be able to reach 4+ with ease. And besides, who on earth
    would buy a costly Rampage II Extreme and then only run the CPU at
    3.33? Heck, my mbd cost 70% less than a R/II/Extreme yet it would easily
    outperform your review setup for these tests (I use an i7 870 @ 4270).
    For a large collection of benchmark results, Google "SGI Ian", click
    the first result, follow the "SGI Tech Advice" link and then select, "PC
    Benchmarks, Advice and Information" (pity one can't post URLs here now,
    but I understand the rational re spam).

    Lastly, it's sad to admit but I agree with the poster who commented on
    the use of 1920x1200 res. The 1080 height is horrible for general use,
    but the industry has blatantly moved away from producing displays with
    1200 height. I wanted to buy a 1920x1200 display but it was damn hard
    to find companies selling any models at this res at all, never mind
    models which were actually worth buying (I bought an HP LP2475W HIPS
    24" in the end). So I'm curious, what model of display are you using
    for the tests? (the hw summary doesn't say, indeed your reviews never
    say what display is being used - please do!). Kinda seems like you're
    still able to find 1200-height screens, so if you've any info on
    recommended models I'm sure readers would be interested to know.

    Thanks!!

    Ian.
  • Ryan Smith - Tuesday, January 25, 2011 - link

    Our 920 is a C0/C1 model, not D0. D0s can indeed hit near 4GHz quite regularly, but for our 920 that is not the case. As for our motherboard, it was chosen first for benchmark purposes - the R2E has some features like OC Profiles that are extremely useful for this line of work.

    As for the monitor we're using, it's a Samsung 305T.
  • mapesdhs - Wednesday, January 26, 2011 - link


    Ryan writes:
    > Our 920 is a C0/C1 model, not D0. D0s can indeed hit near 4GHz quite
    > regularly, but for our 920 that is not the case. ...

    Oh!! Time to upgrade. ;) Stick in a 950, should work much better. My point
    still stands though, some tests could easily be CPU-bottlenecking when
    things get tough.

    > As for our motherboard, it was chosen first for benchmark purposes - the
    > R2E has some features like OC Profiles that are extremely useful for this
    > line of work.

    So does mine. :D No need to spend oodles to have such features. Your's
    would of course be better though for 3-way/4-way SLI/CF, but that's a
    minority audience IMO.

    > As for the monitor we're using, it's a Samsung 305T.

    Sweeeet! I see it received good reviews, eg. on the 'trusted' of the
    'reviews' dot com.

    Hmm, do you know if it supports sync-on-green? Just curious.

    Ian.

Log in

Don't have an account? Sign up now