AMD Radeon Software Crimson 15.12 For Linux Released

[bridgman]

Well, answering a question with a question is, let's say, inelegant.

True, but maybe there is a bit of elegance in answering two contradicting questions ("why don't we have the new hybrid driver yet ?" / "why aren't you spending more resources on the old driver ?") with a third question that at least makes the resource tradeoff clear.

Given the reception, however, maybe I'll just make a statement next time.

You've made is clear something's messed up with Catalyst on Linux since it's the only piece of software that I know of that can't afford the effort of documenting changes. And despite being singled out in this position, you still seem to suggest everything's just peachy.

OK, so you know we are in the process of replacing Catalyst Linux with an amdgpu-based solution and so are working on two different driver stacks during the transition, right ? Hopefully it's obvious that working on two stacks in parallel *does* make resources really tight for a while.

Since Catalyst on Linux is the only closed-source GPU driver that is in the process of being replaced with a new open-source-based stack it probably *is* the only comparable piece of software that is under that degree of resource pressure.

You could call that "messed up" if you want, although that would be, let's say, inelegant

I certainly don't think I'm saying "everything's just peachy", this is a big project and everyone is working long hours to get it done. I am asking some questions to understand if better change logs for Catalyst during the transition really would help our users, or whether people are really just saying "hey that other vendor isn't spending time giving us an open source solution like we asked for, how come their change logs are nicer than yours huh huh ?".

If the former is true, then we should probably divert a bit more effort into the change logs. If the latter is true then we should probably ignore the posts about change logs and focus on getting a good amdgpu solution finished.

[Kano]

Do you really want to say that many people work on the Linux layer of the binary driver? I mean community patches for more kernels/gcc problems are often out long ago, until new Xserver support is added this is more or less a copy/paste and little rewrite thing. Selecting an already known profile for a new binary could do anybody who can run benchmarks, so what huge improvements did you see lately?

[bug77]

OK, so you know we are in the process of replacing Catalyst Linux with an amdgpu-based solution and so are working on two different driver stacks during the transition, right ? Hopefully it's obvious that working on two stacks in parallel *does* make resources really tight for a while.

Since Catalyst on Linux is the only closed-source GPU driver that is in the process of being replaced with a new open-source-based stack it probably *is* the only comparable piece of software that is under that degree of resource pressure.

You could call that "messed up" if you want, although that would be, let's say, inelegant

I certainly don't think I'm saying "everything's just peachy", this is a big project and everyone is working long hours to get it done. I am asking some questions to understand if better change logs for Catalyst during the transition really would help our users, or whether people are really just saying "hey that other vendor isn't spending time giving us an open source solution like we asked for, how come their change logs are nicer than yours huh huh ?".

If the former is true, then we should probably divert a bit more effort into the change logs. If the latter is true then we should probably ignore the posts about change logs and focus on getting a good amdgpu solution finished.

So you guys are doing the best job you possibly can. If I want to buy an AMD card today (290/390/Fury), where do I go for first-class Linux support? Catalyst or amdgpu?
Will you start providing proper changelogs once amdgpu is in place? Do you have a rough target date for when AMD cards will start supporting new X servers and kernel faster? (Wild guess: you're not commenting on future actions)
Because I need reasons to start considering AMD when upgrading my video card and currently there are none.

[Kano]

Don't buy AMD hardware this year, not even on Windows those chips are future proof. Ok, now you could buy DP to HDMI 2.0 adapters but you don't need a new gfx card for those. Also AMD does not even provide a hybrid decoder for HEVC Main 10 (verified with Windows). Nvidia supports HDMI 2.0 for all Maxwell chips (i think even the GTX 750) and at least with Windows all current codecs with GTX 950/960. I am looking forward to the 2016 generation of chips - Intel Kaby Lake, Nvidia Pascal and AMD whatever...

[bug77]

Don't buy AMD hardware this year...

Don't worry, I'm not gonna.
I was just undescoring the status quo of AMD GPUs on Linux: 9 years after their open source efforts started, the open source driver still hasn't reached feature parity with Catalyst, while Catalyst still doesn't support new kernels and X servers in a timely manner.
It's ok, Linux is a tiny market and AMD should prioritize their efforts as they see fit. In the meantime, I do not see a point in buying AMD AND I'm irked by people praising AMD for supporting open source (I'm not against open source, I'd just rather see something worthwhile come out of these efforts first).

[bridgman]

So you guys are doing the best job you possibly can.

... and continually looking for ways to improve. I'm not on here talking about change logs because it's fun...

If I want to buy an AMD card today (290/390/Fury), where do I go for first-class Linux support? Catalyst or amdgpu?

In the very short term it depends a bit on what your priorities are. There are still some games (typically ones which were just recently enabled by new code in the open drivers) where the first round of "huh ? why is <game> so slow ? Oh, OK, I can fix that" performance examination hasn't happened yet, so in those cases you're probably going to want Catalyst. Same for games which require compute shaders for now, but for everyone else amdgpu seems to be approaching that "I use it and it does what I want" level.

Will you start providing proper changelogs once amdgpu is in place?

Most of the code will be in public repos with full commit history, just like it is today. For the remaining closed source bits we'll certainly have more time to work on change logs, and I won't feel bad about pushing (or helping) to improve the documentation at that point.

Do you have a rough target date for when AMD cards will start supporting new X servers and kernel faster? (Wild guess: you're not commenting on future actions)

The amdgpu driver provides immediate support for new kernels and OSes today. That won't really change when the closed components move on top, since all of the bits which interface with X server and kernel will be upstream. We may continue to do binary releases for workstation if only for ISV cert requirements, but most of those products get used on older enterprise distros with really old base kernel anyways, so support for new X/kernel may not be as aggressive there.

[bridgman]

Well, my response was blocked by the stupid auto-moderator-spam-filter thingy. Will wait to see if it shows up before writing it all over again.

[duby229]

Don't worry, I'm not gonna.
I was just undescoring the status quo of AMD GPUs on Linux: 9 years after their open source efforts started, the open source driver still hasn't reached feature parity with Catalyst, while Catalyst still doesn't support new kernels and X servers in a timely manner.
It's ok, Linux is a tiny market and AMD should prioritize their efforts as they see fit. In the meantime, I do not see a point in buying AMD AND I'm irked by people praising AMD for supporting open source (I'm not against open source, I'd just rather see something worthwhile come out of these efforts first).

There is no doubt at all that AMD has the best current OSS drivers. And if Steam would enforce minimum requirements, most people could game on it without any problems at all. The trick there is to effectively prevent people from installing games that don't work. It's a fact that there are a lot of new linux ports that don't work. They don't deserve to get paid for.

[bug77]

Well, my response was blocked by the stupid auto-moderator-spam-filter thingy. Will wait to see if it shows up before writing it all over again.

It will. Michael usually unblocks them as soon as he sees them.

There is no doubt at all that AMD has the best current OSS drivers. And if Steam would enforce minimum requirements, most people could game on it without any problems at all. The trick there is to effectively prevent people from installing games that don't work. It's a fact that there are a lot of new linux ports that don't work. They don't deserve to get paid for.

Well, I have this habit of buying hardware. And I'm so nitpicky I buy hardware that works. So for me "the best current OSS driver" doesn't mean much. I go for the best current driver instead.

[duby229]

It will. Michael usually unblocks them as soon as he sees them.



Well, I have this habit of buying hardware. And I'm so nitpicky I buy hardware that works. So for me "the best current OSS driver" doesn't mean much. I go for the best current driver instead.

That's just a matter of opinion. You are free to it of course. But nobody wants the desktop itself to be so slow and buggy that it's effectively unusable. The desktop experience is way better with the OSS drivers.