It appears the process has not changed from the original 14.2 post, which is good, since this is only a minor update. In fact, the reason I’m writing about it so late (it was released on Monday, 3/17/2014) is that I had put off installing it until I updated my mesa libraries (w00t) and it appears a reinstallation is required. I would very much like to learn sufficiently to understand precisely why this is occurring, since it may be feasible to resolve the matter more precisely, perhaps with Dynamic Kernel Module Support (dkms) without a full reinstallation. But, since the reinstallation process is so fast, it’s not exactly a pressing issue.
I knew I needed a reinstallation, by the way, because launching Steam gave me the following error:
OpenGL GLX context is not using direct rendering, which may cause performance problems.
For more information visit https://support.steampowered.com/kb_article.php?ref=9938-EYZB-7457.
I’ve received the error in the past, always after updates (though not strictly kernel updates as I expected; I unfortunately cannot recall the last update transaction which caused the problem, but I didn’t expect it. The mesa drivers are understandable) and reinstalling the drivers always resolves the matter.
I may post some benchmarks but I don’t expect any performance improvements from 14.3. Perhaps from the mesa drivers, though..
The Catalyst 14.2 Beta Linux driver, like the Catalyst 14.1 Beta Linux driver , is downloaded as a zip file named “amd-catalyst-14.X-betav1.3-linux-x86.x86_64.zip” where X is appropriate to the version of the driver. With these versions, the file is unzipped into a single installation file called “amd-driver-installer-13.35.1005-x86.x86_64.run.”
With the Catalyst 14.3 Beta Linux driver, one happily finds that the unzip operation generates a directory named “fglrx-13.35.1005.” Within the folder, one finds the familiar amd-driver-installer-13.35.1005-x86.x86_64.run file, but also a “check.sh” file and a sub-directory named “doc.”
The “check.sh” file explains in its comment header that its purpose is to detect the X server version and the system architecture. It’s short and reasonably well-written, and it does what it says.
That does bring us to the better part, however; the doc directory contains a directory called “articles,” one called “examples,” and one called “user-manual.” There are a couple of html files and a LICENSE.TXT file.
The documentation is great! The user-manual directory contains AMD_Linux_Driver_Specification.pdf which is a nice technical description of the product covering too many subjects to enumerate here (though it’s only 14 pages in length).
The tips-linux.html file clarifies the prerequisites for the driver nicely:
-glibc version 2.2 or 2.3
-one of the following X Window Systems
–XFree86 version 4.3.0
–XOrg 6.8.x, 6.9.x, 7.0.x
So ensure your XOrg server is up to date (a standard yum update will do) and glibc should be the only other prerequisite you need. I’d be interested if anyone attempts an installation with these bare-bones requirements to see if it works properly.
It further reports that there is an rpm installation option! I did not know they packaged the driver as an rpm. I haven’t run into that information online anywhere. It’s somewhat surprising, and the document provides no information regarding the acquisition of the rpm. Quick Googling reveals nothing but outdated information for previous driver iterations (like 13.1 and junk). So, I’ll have to look into that later.
There’s too much for me to cover in this one blog post (largely on account of my desire to play L4D2) but there’s a lot of help here for common errors, so it’s worth looking through if you’re in trouble. As always, let me know if there’s anything I could help to resolve. I’m interested in the education.
Last Note: I am very interested in this support for dual GPU solutions. I wonder if a cheap AMD card set to work with my APU using AMD CrossFire would r0x0r t3h b0x0r…