SCIENTIFIC-LINUX-USERS Archives

May 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Fri, 25 May 2012 12:08:37 +0900
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
On 05/25/2012 11:56 AM, Phong X Nguyen wrote:
>
> On 24 May 2012, at 0544, zxq9 wrote:
>>
>> 	A digression about the driver on SL6:
>> The annoying thing is that every time you update your kernel you'll need to rebuild the drivers against the new kernel headers. The awesome part is that the driver building process is mostly automated for you, AMD has lately done a very nice job of maintaining its driver set for Linux, games, CAD, and anything else graphical you want to do really fly on an A8, and all this is free (both types of "free" -- AMD opensourced its Linux drivers, so the Catalyst package is no longer "evil", or at least not as evil as it once was).
>>
> Can you use DKMS to automate driver building on kernel update?
>

I haven't messed with it myself, but it certainly should work fine if 
you just want to keep the same version of Catalyst around.

Since the AMD driver release updates nearly as often as the Kernel 
itself, I've been building new fglrx rpms with the latest driver against 
each new kernel as they come out and keeping them in our repo. Some of 
the driver updates bring significant performance imrovements that 
actually matter to us, so we try not to miss any.

I haven't found a way to completely automate away keeping track of the 
new AMD releases yet, though, so keeping fglrx rpms up to date is a lot 
like packaging a high-frequency project for a distro (as in, treating 
AMD Catalyst essentially the same way you would an upstream project).

Anyway, DKMS is simple enough to set up that feeding it new Catalyst 
releases as they come out shouldn't be too difficult. (Well, from my 
understanding anyway. Again, I haven't done this myself yet, though I 
might give it a shot if I can get some time to play with it -- though 
even if any part of it is difficult the situation should be routine 
enough that wrapping any needed re-configuration process in a script 
should be trivial.)

ATOM RSS1 RSS2