Finally got around to installing fglrx with the latest sgfxi - new download method. Interestingly enough, it downloaded a file not even listed on AMD's site: amd-catalyst-14.5.1-linux-x86.x86_64. The latest and lastest beta is showing: 14.4:

www2.ati.com/drivers/linux/amd-catalyst-14-4-rev2-linux-x86-x86-64-may6.zip as the latest

and ...

www2.ati.com/drivers/linux/linux-amd-catalyst-14.4-rc-v1.0-apr17.zip as the latest beta

Very strange. I did not install the beta. I just did a normal sgfxi. Here's the fglrx-install.log:



The install failed at first. I shutdown and was able to reboot into GUI xfce, but it was way off.

I ran it again and couldn't re-boot in GUI. I ran it again, got it to boot into GUI, but performance is way off - tearing.

The amd-catalyst-14.5.1-linux-x86.x86_64 is very interesting. Given the above file names for 14.4, it's not looking good.
Back to top

There's nothing strange at all. AMD no longer employes prefessionals, and seems to prefer hiring the dregs of the industry, whose skillsets do not include any consistency in file name generation.

Since it's impossible to deal with 100% random file names and incoherent versioning in an automated way, I tried for a few years and gave up, with a decision to make: do I drop sgfxi fglrx support, and accept that amd is no longer a real software company, or do I fix their incompetence for them and simply ignore their randomness and follow a consistent set of file naming rules.

It's not just the file names that are random by the way, the actual fglrx zip file itself is randomly mutating as to its contents as well, and a programmed solution cannot handle full randomness like that.

So sgfxi does not use the random cr#p from amd anymore, it imposes, as do all distro packages too by the way, a consistent schema:

amd-catalyst-[year].[month].[release number that month]-linux-....

This was taken from a brief moment of consistency amd showed a year or so ago.

the so called 14.4 current was released 14.5 and only showed up on the actual download page a few days ago, ergo, it's the 14.5. It's the first driver shipped in may, ergo, it's 14.5.1

Simple. If I tried to in any way adapt to the totally undisciplined methods of amd, who clearly are using outsourced programmers, and probably do not even have a linux driver group working in house any longer, I would once again go insane, and waste days every single release trying to add in yet more random handling.

richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html

If you are at all confused about this, that is written by a guy who has had to deal with the internals of amd fglrx as a developer, and as you can see, the total randomness and cr#p quality and lack of care is equally visible internally as it is on my end in sgfxi, the externals:



In case you are delusional, or on anti psychotics of some sort, vendor b is amd. Vendor a is nvidia.

As a person who does not get paid to follow vendor b's insane behavior, I refuse to endorse or participate any further in their ridiculous plunge to the bottom, and and am fixing what I can fix.

So you will see no beta beta2 -betav1.45 betav:2.343.o or 14.4 14-4 14-4 shipped in may on the driver file names, what you will see is what they are, and the numbers you will see will not include any such nonsense.

While I can't make their version numbers as good as nvidia's, wohse external structure mirrors their internal quality, and one primary number will indicate legacy type, for example, 304 drivers are for 6/7xxx card series, but that doesn't matter because vendor b doesn't actually have legacy card support so it doesn't matter.

In case it's not clear, amd had somewhat been clinging to their year-.month stuff, but decided that too was too consistent, and for 14.5.1 decided just for the freewheeling heck of it to just ignore the actual release month, which is why I stopped using their file names a few months ago, it was driving me insane trying to follow what is clearly a totally bottom feeder group that has nobody competent working for them.

As the author of that article noted, anyone who is good who works for vendor b struggles to leave and get a job with vendor a, and it shows, more and more. I believe amd is very close to dropping linux support, though they will maintain basic support but nothing more.

So you can trust the version numbers, for example, if amd releases a driver and calls it 13.12-betav6, except they release it in jan or feb of 2014, which they in fact did last year, you will never see that, what you will get is say, 14.6.2 if it's released in june, and then sgfxi will be able to compare version numbers, correctly assign drivers, etc, and everything 'just works'.

So you can trust sgfxi version numbers, and ignore amd ones. If this bothers you, fine, nobody pays me to do sgfxi, and it was either impose structure and discipline on their driver names, or drop amd support. There was no other option, I picked the former to be nice to sgfxi users.
Back to top

Now as to amd fglrx 14.5.1 (notice how easy it is to refer to that driver now?) not supporting kernel 3.14 that's the first I've heard of it, can't tell you if that's a general thing or not, see if you can find some info.

Their external file name has nothing to do with the actual driver version, it's actually some number, I forget what, like 800.23.21, their internal numbering schema is fine, they just don't use it anywhere visible.

i could use that I guess if I wanted to, though it would take more work, which I am not going to do.

run: sgfxi --debugger
which will upload all the stuff I need to see the error etc, or don't.

While I have added a ton of debugging stuff to sgfxi, if a driver doesn't support a kernel, I can't make it, and if a patch is needed, give me a link for it so I can add it.

I'm not spending much more of my very finite life supporting a company that clearly has no interest at all in linux or spending money on their driver, I will offer basic support, and I will help users who offer some energy and time re search and offering links to patches and so on, but I won't spend my own time and energy on it. Life is too short.

And I will update the support tests if you can show that 3.14 plus 14.5.1 fails on all systems with 3.14, to exit with error until a patch is applied, or not.
Back to top

Just to be clear:

if amd releases a new stable driver in june, it's called: 14.6.1
It makes no difference at all what the driver zip file is called, or the run file inside the zip file, sgfxi no longer uses any of the amd file naming unless by chance, because that is quite frankly impossible to do at this point in the game, amd has lowered the bar too far, in terms of competence, or raised it too high, in terms of overall project incompetence levels.

If amd releases a beta driver after that, in june, it's called: 14.6.2

No beta6 or betav2.14 or beta1.3.45-may12, just a new number, just like all the other numbers from now on.

if they release another one, it's called: 14.6.3

Now the actual sgfxi internal beta or stable logic can work for amd too, like it always has for nvidia, if you ask for -B in sgfxi, sgfxi will compare the numbers, now that it has numbers to compare, and say, ok, 14.6.2 is greater than 14.6.1, therefore the request for a Beta is valid and will be used. If say there was a beta 14.5.2, and then they released stable 14.7.1, and you asked for -B, sgfxi would say, beta is older than current, so I will not honor the -B request, and offer the current stable, which is in fact the real latest release.

Nvidia, being vastly superior programmers and company, of course, sgfxi can offer a lot more, so it actually supports beta versions for each legacy branch, as well as current or newer than stable. Ie, 3 or 4 beta branches, so sgfxi is a bit more sophisticated with nvidia driver version tests. amd only ships one stable branch, and has no legacy support, they pretended for a month or two to have one legacy branch, but given they never actually did any work on it, that was a joke, so sgfxi treats fglrx exactly as it is, a single branch, that has betas now and then. it's only, by the way, fairly recently, that amd even did public releases of their beta drivers, before that you had to sign an NDA to even download it, which of course meant that almost nobody did beta testing on their drivers, which has predictable quality outcomes, since the entire point of a beta release is collect bug reports and fix them, neither of which amd generally actually does.

sgfxi can also query for newer betas using nvidia driver version file data, that they put online for exactly such reasons, so sgfxi can query that file as well for beta, see if there is a newer beta from nvdia, then use that instead of the local sgfxi version. Since amd driver file names for download and comparison are totally random, not numeric, and totally incoherent release to release, sgfxi of course cannot offer such a service, also because sgfxi cannot work with their randomized file names for download or extraction or operating on, that's not an option I can offer with sgfxi and fglrx, though my solution to their file name randomness is a HUGE burden lifted off my brain and spirit, believe me.

See how that works?

the 3 numbers have now only a coincidental resemblance to amd's file naming.

[2 digit year][dot, not dash, not dot OR dash, but DOT][month, no zero padding][DOT][number of release that month].

the release date is based on when it appeared on their download page. For example the filename for 14.5.1 shows 14-4, then some refernce to revision 2, then a date, may 6. This is how you can see that literally no professionals are left in amd linux group, they literally can't even follow their own version system over a single release cycle, let alone over a year.

This is what sgfxi will give you, take it or leave it, there is no option B in this case, except dropping fglrx totally.
Back to top

There's a new beta fglrx, try it and see if it works. sgfxi -B, they call it, just to be fanciful, 14.6 but it's not june, so sgfxi calls it 14.5.2 ie, the second driver release in may.
Back to top

I knew you came up with a new download and renaming scheme. I just didn't know exactly how. Solid logic applied here.

www.phoronix.com/forums/showthread.php?99422-AMD-Catalyst-14-4-Is-Now-Officially-Available&p=418141#post418141

It's a mess, for sure. So I installed the beta, and got the same issue. I got the same install problem. Then I installed dkms because I remembered that I had better results before if dkms was installed. Results of the 1st and 2nd attempt:



I appreciate your work on this, but I have reinstalled the radeon driver again, and plan to live with that - at least for a while. After installing my new SSHD, I was hesitant to mess with fglrx. It was dominating my linux experience. I'm not a gamer, and the radeon driver is "good enough" without all the drama.

This is a nice card, but certainly not top end, so I'll just live with radeon. If I have to scratch the itch again, I'll report back. Thanks
Back to top

dkms cannot be used with the direct installed fglrx, it should only be used with this single scenario:

standard distro kernel + standard distro fglrx driver packaged with dkms.

No other scenario can be relied on to work.

I finally found a patch, it was not correctly generated, but it was close enough.

That patch is added to the 14.5 series drivers, note, by the way, how I can now offer things like this? No beta cr#p, no weird strings, just say:

pally this patch to the 14.5.* series drivers.

Note that all I test is that the patch applies correctly. It does.

It looks to me like it will work because it's very simple logic.

You could ask, with a driver released well into the 3.14 series of kernels, why amd didn't just add this into the file themselves, there is no real logic change I can see, just telling it to use something else if it's >= kernel 3.14 version.

This should probably fix both 14.5.1 and 14.5.2 beta.
Back to top

OK on dkms.

It's amazingly sloppy work. What else can be said.

You put out the effort, so I reinstalled the beta. It took 2 installation attempts, but it worked. No problems.

But with the above in mind, I'm at the ready for a radeon reinstall (for the next xserver-xorg update). Thanks

Edit: Hope springs eternal...

www.phoronix.com/scan.php?page=news_item&px=MTcwNTk
Back to top

thanks for the status report on xorg support, it's hard to track that because for some reason both nvidia and amd refuse to clearly state what xorg / kernel versions are actually supported with each driver in the release notes.

amd makes it even more amusing by claiming to not support newer kernels at all, which is simply false, it's like they want you to think they are worse than they actually are for some weird reason. Honestly I think it's simply because they forgot to update the support data.

I still do not know why it takes some users 2 tries to get the stuff working, with the exception of required reboots, it shouldn't take 2.

Of course, I also didn't ask you what distro you run, which I really need to do first step always on bug reports. If it's mint, they screwed up something or other that makes that 2 attempt thing frequent, no idea what.

You are right that with new xorg 1.16 fglrx will not work, that's correct. Basically with fglrx you want to always be a few releases of xorg/kernel back, then you will usually have very fine or adequate or at least working sort of support with fglrx. they have never supported rolling releases or latest anything, that at least has not changed at all over the years.
Back to top

What I really don't get is why it's so sloppy. Unless they have 1 guy doing too many things (which come to think of it, is probable), how do you consistently blow a release by forgetting to update support data? I know you think there are many hands involved. But to me, it still looks like the work of one guy who would rather be doing something else. I get that there's a lot of "vender B" performance code that's messed up. I don't get the constant need for patches for basic functionality.

Anyway, you talked me into straight debian a few months ago. I download their XFCE testing ISO, do a base install in expert mode, and then, at the command line, update the sources.list, install firmware, gksu, lighdm, xfce4, apt-xapian-index, synaptic, xfce4-terminal, and then re-boot.

I ran bleachbit, so I only have 1 sgfxi.log:



Recently, it has taken a couple installations to get it right.
Back to top