It Doesn't Sound Like The Current AMD Binary Driver Will Ever Support X.Org Server 1.18

[phoronix]

Phoronix: It Doesn't Sound Like The Current AMD Binary Driver Will Ever Support X.Org Server 1.18

Earlier this week was the news that Catalyst/fglrx was being deprecated in Ubuntu 16.04. While there was some hope that one could simply install the driver manually on Ubuntu 16.04, it doesn't look like that will be supported as it sounds like there won't be any new Catalyst / Radeon Software release to support X.Org Server 1.18...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Blob-Server-1.18

[boxie]

As an AMD user (R9 380) I am cautiously happy. I know it is going to be a bit of a rough ride in the next few month, but it will be worth it in the long run!

[bug77]

So 16.04 (an LTS release) will have no proper support for anything AMD, unless at some point someone updates the kernel or backports changes from amdgpu. This must be the worst possible upgrade path.

[boxie]

So 16.04 (an LTS release) will have no proper support for anything AMD, unless at some point someone updates the kernel or backports changes from amdgpu. This must be the worst possible upgrade path.

They are back porting amdgpu from 4.5 to their 4.4 LTS kernel.

The short of it is "Out of the box support is up / Performance and capability takes a hit"

[bug77]

They are back porting amdgpu from 4.5 to their 4.4 LTS kernel.

The short of it is "Out of the box support is up / Performance and capability takes a hit"

Or, the way I see it: we don't have enough resources for both amdgpu and fglrx. Shall we screw ourselves (cost-wise) and get more resources or shall we screw the user and let them miss some functionality (for an undetermined period)? Let's go with the latter.

[FireBurn]

Has anyone tested what happens when the API bump is reverted from Xorg Server?

[boffo]

Or, the way I see it: we don't have enough resources for both amdgpu and fglrx. Shall we screw ourselves (cost-wise) and get more resources or shall we screw the user and let them miss some functionality (for an undetermined period)? Let's go with the latter.

No, the fglrx team now works on amdgpu. Sooner o later it would had happen and it did. There is no point in having 2 drivers. The reason there is an opensource driver is because the community wanted it, therefore fglrx would slowly be unsupported.

[RussianNeuroMancer]

No, the fglrx team now works on amdgpu. Sooner o later it would had happen and it did. There is no point in having 2 drivers. The reason there is an opensource driver is because the community wanted it, therefore fglrx would slowly be unsupported.

Hopefully nVidia will go same route with nouveau.

[peppercats]

Uhhh maybe you shouldn't deprecate software when half of your available hardware still runs like shit on the open source drivers...

Most of the cards aren't even supported by amdgpu, are they?

[bridgman]

So 16.04 (an LTS release) will have no proper support for anything AMD, unless at some point someone updates the kernel or backports changes from amdgpu. This must be the worst possible upgrade path.

bug77, this is not what we are doing.

Installing amdgpu hybrid will replace kernel modules but not the entire kernel... same idea as installing a proprietary driver but open source.

Uhhh maybe you shouldn't deprecate software when half of your available hardware still runs like shit on the open source drivers...

Two separate issues here:

1. Does it make sense to include Catalyst Linux in the 16.04 LTS release if we are going to replace it with amdgpu hybrid almost immediately ?

I think it's fair to say the answer here is "no". If 16.04 were not an LTS the answer might be different.

2. Should we be extending Catalyst Linux just to cover the period between 16.04 launch and initial availability of amdgpu hybrid, or should we use the resources to get amdgpu hybrid out sooner/better ?

The answer here depends on whether the replacement will be out and working by the time existing 14.04.x releases hit EOL (Aug 2016) and force a move to 14.04.5 or 16.04. If yes, then we're probably better off focusing on amdgpu hybrid; if no then we'll need to pull resources back from amdgpu hybrid and spin fglrx one more time to make sure everyone has a solid migration path.