Amdgpu-pro replaces catalyst, maybe

amdgpu-pro
catalyst
amd
xf86-video-amdgpu

(Fred Talmadge) #2

Would you be downgrading Linux and Xorg for those of us without AMD cards? And as a former AMD user I always used the free driver, as I don’t play games with my laptop.


(Matt Hopper) #3

I may well be in over my head, but seems the word on the street is that AMDGPU-PRO is fast becoming the not recommended driver with the newer kernels? I have since stopped messing with the AMDGPU-PRO installation… (I have an RX 460)

Things move so fast I may be missing something. And they are already talking 4.13 and mesa 17.3-dev but seems there were nice improvements with 4.10 and 17.2

What do we expect our next kernel to be?

http://www.phoronix.com/scan.php?page=article&item=amdgpu-1730-radeonsi&num=1


(Luca Giambonini) #4

@Fred_Talmadge: downgrading the kernel is not a problem, we provide the lts version, but downgrading the xorg stack is almost impossible and we will not do that.

The alternatives are two; use the free driver, were the performance is not that bad, or wait the official release from AMD that support both kernel and new xorg.

@mhop3223: true, but phoronix used the old xorg for the tests (1.18), and the new kernel only to verify the performance of the opensource drivers. We will wait the next AMD release to see if this situation will change.


(Rémy Epke) #5

I’m probably misunderstanding the whole topic, but it doesn’t seem right to downgrade the kernel to cover up for AMD’s failure, especially as not everyone uses that shite.


(Neofytos Kolokotronis) #6

As things are now, we have a planned upcoming upgrade of the Linux Kernel to 4.12.4 and of Xorg Server to 1.19.3, both of which are not supported by the latest amdgpu-pro (non-free) driver.
With catalyst (non-free) now obsolete, this means that Chakra will not be supporting and providing any non-free drivers from AMD, at least until we know they play well with the kernel+xorg combination in our repositories.

So the question is, how much does this affect you? Will you be OK with the free (xf86-video-amdgpu) drivers?

Some further information on supported cards for each driver can be found on Arch’s Wiki:
https://wiki.archlinux.org/index.php/Xorg#AMD


About to build a new rig x370, ryzen 7 1700
(richard.llom) #7

You are missing the radeon driver aka xf86-video-ati, see
https://wiki.freedesktop.org/xorg/radeon/
and you should really keep this one, otherwise you’ll leave a lot of AMD users with broken systems.


(Neofytos Kolokotronis) #8

Good catch. We forgot to point out that xf86-video-ati is of course available in our repos and will be updated to version 7.9.0 as part of the package group updates mentioned above.


(Luca Giambonini) #9

I wrote this tipic to explain the current situation of catalyst and AMD drivers. In the past catalyst was one (or the only one) pkg that prevent us to move to a newer kernel or to update the xorg stack. Not many distribution provide closed drivers in their ISO, and to keep the compatibility with catalyst we had to do some compromises.
But now the situation has changed, catalyst is not maintained, amdgpu-pro is the future and moreover with the new kernel we are not able to compile catalyst anymore.
Is currently a very unfortunate situation for AMD users, only mesa drivers are available at the moment.
The future depends on how AMD wants to handle that, with NVIDIA we don’t have such problems, they keep the driver in sync with the kernel releases.
I hope is more clear the goal of this topic, and please, keep the discussion going we need the user feedback


(Gm30) #10

I use the free version and I agree to update the kernel and mesa.
When will this update be available?


(Neofytos Kolokotronis) #11

The kernel/xorg/graphics drivers groups of packages need to move to [testing] first and if all goes well they will be made available for everyone after some time. Just check the #news or follow Chakra’s social networks, as always it will be announced there.


(Alexander Waldemar Ahjolinna) #12

what I understand about amdgpu-pro and AMD/radeon driver situation in general it seem that it would be better that the MESA drivers would be the default one and amdgpu-pro will only be optional aka it wouldn’t even be added to the ISO
…okay there are maybe some features but I don’t think any of them are mandatory ones (…yet), I’m not sure if MESA drivers support the FreeSync (monitor) feature.

From gaming perspective it doesn’t really provide any benefits …other than Vulkan support which is not that good anyways and its currently pointless as many don’t even support it yet …maybe next year.


(richard.llom) #13

To say the situation has changed “now” is bit euphemistic …

I already started this topic in January 2017
https://forum.chakralinux.org/viewtopic.php?id=15222

and OpenSUSE already took catalyst out of 42.2 (which was released in November 2016):
https://lizards.opensuse.org/2016/12/07/amdati-catalyst-fglrx-rpms-end-of-an-era/

So it’s nice you want to hear users feedback, but

  1. This comes a tad late, all major distro (if not all except chakra :wink: already took their decision.
  2. I really don’t see a choice here for chakra. Chakra doesn’t has the manpower to provide an extra/custom kernel for AMDGPU-PRO (like opensuse does) and staying on linux 4.8, x.org 1.17 forever isn’t an option either…

PS:
Sorry, if this sounds so salty, but I just can’t help it …
Also not attacking anyone personal here. I know Chakra is a relaxed distro, so peace out! :slight_smile:


(kepszlok) #14

Yeah, the free Radeon drivers are in good shape, even the games works well with them.

But i have an advise. We are planning this AMD driver switch for months, please do it in two turns. In first, remove catalyst with some script that manages the full switch to free drivers. Some times later will be safe to upgrade xorg and kernel.
I’m sure, doing these things separated are needed for safety.

edit:
seems like i’m 5 days late… I miss the old forum, that was simplier.


(Luca Giambonini) #15

I agree with you @kepszlok, we need to plan this switch and inform the users with the correct procedure to follow, that’s why I opened this discussion, to involve the Chakra users.
We don’t need to do the first “turn” because the user can’t install the new kernel, catalyst requires the old one.

My idea is:

  1. move the current kernel/mesa/xorg group from [staging] to [testing] and inform our users with a proper announce
  2. keep catalyst-lts with kernel-tls for the time being, but will be not installed nor detected in the ISO

My next question is: if we install both xf86-video-ati AND xf86-video-amdgpu driver xorg is able to detect the correc one? someone can confirm?

A summary I found on internet that explain better which xorg driver to use:

amdgpu is for GCN1.2 cards only, which are Fiji (Fury X, Fury, Nano) and Tonga (R9 380/X, R9 285). All other Radeons use the radeon kernel module. That means you need to stick with xf86-video-ati.


(kepszlok) #16

“My next question is: if we install both xf86-video-ati AND xf86-video-amdgpu driver xorg is able to detect the correc one? someone can confirm?”

Yes, because …-ati one is for older cards up to GCN 1.2 while amdgpu handels the rest. Right now afaik they are not overlapping. In the near future, all GCN cards will be supported in amdpgu. I think when that happens, the …-ati (radeon) driver will contain only support for pre GCN cards up to HD6000 series (Terrascale2) cards, withouth overlapping.

So yes, both are needed and xorg will choose the right one.


(Luca Giambonini) #17

thanks, that’s really a good news, it will semplify a lot the ISO creation, less drivers to mess around less complicated will be the next ISO :rofl:

Personal notes:

pacman -S xf86-video-ati or pacman -S xf86-video-amdgpu
pacman -S libtxc_dxtn
pacman -R catalyst-utils


Goodbye catalyst, how to remove it and switch to the free drivers
(Alexander Waldemar Ahjolinna) #18

@AlmAck: btw if you remember there is the Manjaro’s “update script” thing, what they use every time for huge update to handle this manual intervention issue, so users wouldn’t need to do this sort of stuff manually themselves.

its just a simple bash script, and I think this is a perfect opportunity try this out on chakraOS. The implementation does not need to be exactly the same, for example I don’t like that there is only 1 script to handle everything I would rather split it …how? that is another question/conversation.


(Luca Giambonini) #19

nah, I don’t like this kind of update script, we have the .install script already and we can manage them directly there. Having an external script that handle the updates can only become a mess in the future.
Moreover the user should be aware of the changes made on his system, hiding them on a small distro like us is not necessary.


(Alexander Waldemar Ahjolinna) #20

well maybe the real the question should have been that how user friendly does chakraOS want to be?

anyway…

the .install script can only do so much, also isn’t your policy for .install that it shouldn’t really do any “modifications” anyways? plus its not used on pacman 5.x anymore…which I doubt you will move to…so that’s mute.

I don’t think using “external script” for some updates will be problematic if its done correctly and it hasn’t caused any problems for manjaro yet…at least what I know of.
also what I was thinking more about that it should only be used for these kinda of big updates that requires manual intervention…not for every…single…update…

and unfortunately way to few users will check the news feed for what/how they should do when updating their distro, and those that don’t update their distros that frequently is also problematic people. This always mean the possibility of the distro breaking for them will increase and be pissed off and leave.

I also I have to disagree that this means “hiding” changes on their system when those changes are usually mandatory plus if the information is available…its not hiding either.

I would understand this logic more if the PKGBUILD and the scripts and etc was closed/proprietary and you couldn’t see those changes in any form.

also: like H.L. Mencken once said “the common man’s a fool”


(system) closed #21

This topic was automatically closed 170 days after the last reply. New replies are no longer allowed.