Addendum Regarding AMD’s Mobility Catalyst 13.1 Drivers
by Jarred Walton on January 22, 2013 2:30 AM EST
Late last week AMD release their first drivers for 2013, the Catalyst 13.1 drivers. The drivers as noted already are available for both desktops and laptops, but I did some testing on several laptops with the drivers and found a few problems that still needed addressing. AMD contacted me today to provide me with some additional information, which is sort of good news and also somewhat bad. The short summary is this: the 13.1 Mobility Catalyst drivers are intended only for Enduro systems with Ivy Bridge (3rd Generation Intel Core Processor) and Trinity (2nd Generation AMD APU); earlier laptops with Sandy Bridge (2nd Generation Core) or Llano (1st Generation APU) are not supported with this driver. The driver download pages have been updated to clarify this point.
What this means for owners of laptops with the earlier AMD Dynamic Switchable Graphics (e.g. the Sony VAIO C I tested, or HP’s Envy 15) is that short-term you should stick with either the previous driver, or perhaps look to modified drivers like those from leshcatlabs.net in order to get updated drivers for your laptop. Long-term, AMD still appears to be committed to properly supporting PowerXpress 4.0 and 5.0 hardware (aka Dynamic Switchable Graphics), but that will have to wait—again—for another driver release.
The above should help clarify our results with the drivers, as our Trinity and Ivy Bridge systems were all able to install the drivers without any apparent difficulty (though we would still have to go through other channels to get the drivers in the first place on several of the systems). I want to also make it clear that the 13.1 drivers should work fine on any APU-only Llano systems along with any laptops that have discrete-only graphics solutions; the only difficulty is if you have a laptop with switchable graphics. And of course, any older laptops with PowerXpress 3.0 or earlier hardware remain unsupported as far as I can tell, and I expect that to continue.
As I said, then, this is good and bad news. The good news is that the drivers apparently work as intended; the bad news is that AMD has yet to release an updated driver for Sandy Bridge and Llano laptops with switchable graphics. Time is running out, as in another year support for such laptops becomes mostly meaningless anyway—the Turks GPUs found in such systems are already getting rather long in the tooth. Hopefully AMD isn’t hoping that the users of those laptops will go quietly into the night, and the fact that leshcatlabs.net continues to provide modified drivers that generally install without difficulty is particularly damning. Maybe AMD just needs to go ahead and hire Aliaksei Dzenisevich? Then again, they likely prefer to keep him separate from the corporate bureaucracy where he can do things without being required to adhere to strict WHQL standards.
Facebook
Twitter
RSS
16 Comments
View All Comments
CeriseCogburn - Tuesday, January 22, 2013 - link
Well we all know what AMD PR campaigns have said for many years now - it's should all be open source so long as amd's competitors own the proprietary knowledge and software excellence, they should give it to all (meaning amd) for free.
This is just another great and holier than thou open sourcing driver plan. AMD sits on it's stupid butt, and someone else does all the work. AMD doesn't pay them, likely bad mouths them, and embarrassingly, articles need to point out alternatives to amd because they suck so badly.
Open source is the future of amd, the past, and the present, and it sucks.
silverblue - Tuesday, January 22, 2013 - link
Have you ever downloaded Omega drivers in the past?Death666Angel - Tuesday, January 22, 2013 - link
Those were awesome. Some of my first memories of tinkering with my PC. :DCeriseCogburn - Tuesday, January 22, 2013 - link
Still have them all.JPForums - Tuesday, January 22, 2013 - link
Not sure where you are getting this.AMD has never planned to stop releasing proprietary drivers.
AMD isn't open sourcing their proprietary drivers.
They released some information (wish they gave more) for the open source community to use to make it own open source drivers.
However, the closed source nature of their proprietary drivers preclude the use of any GPLed code.
It makes no sense for them to rely on a third party to fix their problems.
There is no guarantee that a third party will do the job.
There is no guarantee that the third party won't screw something else up in the process.
There is no visibility to the general public.
As familiar as I am with the Omega drivers and kX Project, I've only just now heard of leshcatlabs.
I can't imagine your average Joe knows about them when most I've talked to don't even know about Omega drivers.
Many computers that cross my desk have drivers a year or more old, so even AMD drivers didn't have enough visibility until they built automatic driver updates into the control center.
Yeah, AMD has plenty of problems to work out, but you're barking up the wrong tree.
What they really need to work on (and probably are) is acquiring and retaining good low level programmers to better support their increasing commitments.
CeriseCogburn - Thursday, January 24, 2013 - link
So you pretend to, or do completely miss the points (with so little historical knowledge), you admit as much, then completely agree with me anyway, and finally delude yourself into thinking amd's mass firings means they are working on getting good programmers because you admit their drivers do suck...So, you've argued with yourself in clueless fanboy fashion, totally supporting amd anyway with your sideways bull crap.
You're so screwed up it's unbelievable. Get a sarcasm detector.
BTW in this case it did pay to let a 3rd party make a better driver than amd is capable of making. So you got that wrong, too, for example.
The one thing you got right is amd drivers truly suck.
Dribble - Tuesday, January 22, 2013 - link
If before they fired a big % of their driver team mobile support was dodgy, what do you expect it to be like now? Also when times are bad the best devs tend to leave because they can. Bottom line is they simply don't have the capability to support everything they are meant to support.SunLord - Tuesday, January 22, 2013 - link
When did amd fire any part of the gfx driver team? I know they eliminated some of the developers that did linux drivers and compiler stuff for cpus and some other stuff but none of them had anything to do with the graphics divisionCeriseCogburn - Tuesday, January 22, 2013 - link
So AMD cans the linux drivers team and Torvalds gives nVidia the bird...LOL
Ironic, but Torvalds knows amd is such crap he doesn't want "the goods" from them.
CeriseCogburn - Thursday, January 24, 2013 - link
PS - so you know none of their drivers team was lat go in the last 3 mass firings ?I don't think you know jack about it. But, as an idiot amd fanboy blowhole, you'll just pretend it did not occur.