After yet another pointless amd file name/path change, I'm not going to spend any more of my times tracking this bullsh#t.

Their latest was to change to a download name of .run.zip, from simple .zip, and to have a file name with a space in it inside the .run.zip package. That's after their previous pointless change of zipping their run package, which had no purpose at all that I could discern.

That's their beta-v9.4 which also added a new beta syntax to the naming.

AMD can go f#ck themselves, I'm sick of wasting my time tracking these utter and total incompetents.

If you have amd stock, sel, it as soon as possible, it appears that they now have absolutely no internal discipline anymore.

Given their last stable release was in 13-4, almost 7 months ago, I'd think very carefully about spending a penny on amd products if you want a non free driver + linux. Well, I wouldn't think carefully, the answer is already here, if you use that stuff you're a fool at this point, they are pulling back from linux, and are manifesting a totally rudderless strategy from everything I see from the outside re sgfxi and the inane amd / ati group changes I have to try to track.

So if they release a new stable, I'll add it, otherwise, unless they stop this ridiculous behavior and start doing things at least slightly predictably, I just am not spending any more time on them. It's gotten to where every single driver release changes one or more simple things that I have to then add code to handle, where competent groups like nvidia thought of one coherent scheme, and stuck to it, years ago, making handling nvidia stuff a breeze when compared to amd fglrx drivers.

To users/sufferers of amd fglrx stuff, I'm sorry, but I tried to support their beta stuff, which is the only way to get current drivers, but they are making it basically impossible for me to do that.

I will continue to support their stuff if it works without my having to recode large blocks of sgfxi each single new driver release, but for stuff that is too complicated to support, like their bs with beta-v9.4, or should I say, beta V9.4, it's gone too far, sorry.

Don't expect much better from the free drivers by the way, watch the support go south when amd stops funding the xorg guys.
Back to top

Is installing the AMD driver this easy?

linuxg.net/how-to-install-the-amd-catalyst-13-11-beta-9-4-on-the-most-popular-linux-systems/

Of course, I would uninstall the current driver, first.


Living with their beta drivers will be mandatory, so it's basically over, unless there's a workaround...

I have tried modifying the script, but get the predictable wget error. Line 330 is not the problem. That's easy. I think the fun starts at 5665 (for set_download_info() on line 5654).

Is there any way that you can mod this once and for all for the user to insert the name of an extracted file - subject to change by the user - so that no one has to worry about AMD's paths? Instead of looking for and not finding ever changing URLs, could you modify it to deal with an AMD download file within, say, the home directory?

If possible, would re-naming the file to whatever standard you set break the installation?
Back to top

chris m, good thinking, in fact, that's pretty much exactly what I was thinking.

The problem here is that each adaptation I have to do requires a DIFFERENT set of logics.

So that's now 3 different download url syntax changes THIS MONTH ALONE!!! for amd. And ignoring their inability to decide between, say, 13-4, 12.11, 13.11 type numbering, which has been ongoing.

The last one was particularly a masterpiece, in fact, it's so ridiculous it's hard to be able to think of any reason for them to do that other than to f#ck with people deliberately. Either that, or we are looking at a group that is basically totally out of control, totally incompetent. Or whatever.

The day after posting this, I debated doing pretty much exactly what you described, downloading to a temp folder, extracting there, renaming extracted file which requires either 'rename' program or some other tricks with mv, and then using that installer file.

The problem of course is that sgfxi expects the name of the download file to be the same as the file extracted from the zip file, minus the zip extension.

Well, it's not that simple, but it's basically like that.

What amd did on this most recent change, was this:

add .run to their already zipped run package file name, making the extension .run.zip instead of just .zip. Since sgfxi has to be able to handle all different ways amd has dribbled out random changes here, that added one more totally pointless set of tests to do in several areas. Also, since sgfxi checks, or tries to check, live beta versions to handle newer versions automatically, that feature would have to be removed from sgfxi.

The number of changes required to handle this basically brain dead retarded last change, .run.zip plus the extracted file NOT being the same, in this case, where the download file name is ...'13.11-beta-v9.4' vs '13.11-beta V9.4' (note the upper cased V and space after beta, not -?) file name - adding the .4 to 9 was another cute feature on their part, they have in the last months drifted between the following:

beta (alone, no number, but actually changing versions)
beta2 (simple number)
beta (back to no number)
betav2 (adding v to number)
and now:
beta-v9.4, adding - and making the number a floating point.

In order to handle amd making their beta the recommended stable since they seem to have given up on releasing stable drivers, I also had to add in a custom hack to force sgfxi to switch to beta installs for the 13.9 driver, ie, a custom hack for a single driver. This is getting patently ridiculous.

There's also been a few other changes in paths for the beta, and for the file names.

This total lack of discipline means NOTHING I do to try to work around this bs can be trusted to work tomorrow, when they do their next totally random download file/path/extracted file name changes.

It's impossible that anyone competent could be in charge of this group at this point because these types of totally random changes could not possibly occur if the linux amd group were run competently, it's just out of the question.

If you compare this to nvidia, which after their last syntax change, which was I think 5 years ago, they simply use a totally simple and coherent numbering scheme, which works like this. Note I can tell you how it works because it's coherent and consistent.

Current driver is the highest first number of the 2 to 3 number sets, for example:

331.20

legacy drivers are an old current driver branch that is maintained until it's too old, say:
304.116 for 6xxx/7xxx cards.

betas are larger numbers than the stable / legacy branches, in the case of the legacy, a new beta might be, say:
304.120 (or prerelease testing, which they also do)
then, when that's stable, you'll see a new one released:
304.125, say.

No nonsense about beta's in the file name/download path, it's a number.

I actually cannot even remember all the changes that amd did over the last 5 years, you can see their traces all over sgfxi comments and commit messages for svn.

I very grudgingly added beta amd support about 11 months ago if I remember right when amd first decided to actually release public betas, hoping they'd actually start doing things right or consistently, but that dream was shortlived.

AMD also, by the way, made it basically impossible to actually track their 'legacy' releases, which aren't updated or maintained anyway as far as I know, by just giving them the same download number as the stable one, I think it was 12- something for the older amd cards, I don't remember, but I could never actually use that for testing so I didn't implement any legacy card handling or support for amd because I knew they'd never actually do any meaningful updates on their stupid 'legacy' driver, and that turned out to be correct, so that's already a place where I dropped amd handling to basic levels due to their predicable failures. In case it's not clear, since the driver for legacy would be, say, 12-8, they can't update the numbers, even as they update the driver, if they had, which is one of many problems with releasing a stupid driver download numbering scheme like year-month in the first place. The problems with that stupid scheme became most evident one month when they hadn't figured out what to do with the newer betas released that month so they didn't change the numbers at all for new versions...

When you look at the time I spend on amd vs nvidia, it's about 10 to to 1, literally, over the last years, yet I already know that amd sucks, I know their non free driver sucks, and I know that amd has no competent people in charge. I also know that the very best thing users can do is switch to the xorg free radeon driver, and then forget about any performance, which means, anyone buying amd cards for performance at this point are never going to get it, so it's a waste of money.

I honestly did not expect amd to simply drop current driver support, or at least reasonable current driver support, thus pushing beta driver support to the forefront, something I only did this very month, and then, after that, I did not expect those undisciplined people to randomly engage in changes so ridiculous that it simply become too absurd to consider tracking them.

The only actual solution I can think of is to simply bypass amd completely and just download/extract their drivers somewhere else, manually, since it's literally random each time, turn off all the amd handling, including auto checks for newer beta versions, and then just use that processed file.

But that's a royal pain in the butt, and I'm not wanting to go that way.

Basically, all the existing programming will work for up to 13-11-beta6, and one backend thing is updated to handle yet another possible syntax option of -v9.4 type, but I'm not updating sgfxi internally to handle that because I can't trust amd anymore to actually deliver their stupid driver in a coinsistent manner. If I were paranoid, I'd think that amd is in a petty and childish fit actually trying to deliberately break methods like sgfxi uses....
Back to top

That simple install method did work. AMD must have improved their installer? Maybe it's been that way for a while.

I did have to rename “amd-catalyst-13.11-beta V9.4-linux-x86.x86_64.run” to “amd-catalyst-13.11-beta-v9.4-linux-x86.x86_64.run”, so that space between beta and V was an issue ("particularly a masterpiece").

If that installation method is good to go, I understand not wanting to mess with this.

But smxi-sgfxi was still very handy in that it automated the installation of the radeon driver - automated the uninstall of fglrx.

Whenever I install fglrx, the console font is unmanageably large. I don't know if it's this way after installing the nVidia driver also. Is there a more elegant way to deal with this than: raspberrypi.stackexchange.com/questions/3543/how-do-i-increase-the-terminal-font-size ?

The available font sizes are still too large/ugly, and it makes working with your scripts tougher than it should be.

Thanks. Maybe AMD will get it together. I think they're simply in a rush to throw out bug fixes. It's probably a one man operation.
Back to top

the randomness suggests that it's not a one man operation, but an outsourced operation, being handed to various programmer drones with little planning or ongoing discussion at any higher level. Individuals tend to do stuff in patterns, even if they are stupid patterns, although I have to admit, I have seen outsourced stuff done totally random by one person, who had no clue about the task they had been assigned, that was great fun.

You can do each change amd does manually of course, but doing things manually is a heck of a lot easier than doing it with programming.

Given I have done 3 hacks this month alone for amd betas, caused by their changes and inconsistencies, I decided enough is enough.

the beta6 will work for most people at this point, so I'll just wait to see what amd's next random move is to make a final decision on what to do with this phase of amd randomness.

I figured out how to solve THIS particular thing, but decided that solving it involved so many ridiculous steps that should have been totally unnecessary that I had to draw a line somewhere.

I also had to update smxi gfx installer library to handle the last amd changes as well, something I almost never have to touch in general, usually the only times I touch that is when nvidia releases a new legacy level for older cards, 304 in this case, then I have to change the text of the installer to reflect what each driver does.

To put this siimply, when I spend time on the nvidia part of sgfxi, the outcome is usually a new feature or option which in turn is often enabled by a new feature of the nvidia installer package, and that feature in general remains supported for a long time.

While both amd/nvidia driver installers require patches at times, handled by the patching logic, what worried me about this recent amd stuff was the requirement to add in yet another pre driver install set of hacks, the levels of programming required now to just simply assemble the file download name/path, and now, to handle the extracted name as well, are just getting ridiculous, and given I really dislike this driver in the first place, my motivation is not high, to put it mildly, this corporation in their ongoing incompetence is wasting my, and other people's time.

If their goal is to start pulling out of active linux development without admitting that is what they are doing, I could see few better ways to do that than what they are doing now.
Back to top