AMDGPU-PRO 17.50 Now Bundles Open-Source Components, Lets You Mix & Match Drivers

[cRaZy-bisCuiT]

All I'd ask for is an "AMD GPU Open" package in Arch Linux "Extra" repository. Like those both, radv and AMDs solution could be easily installed and I could add an environment variable for each Vulkan game to use the driver which is working better with it.


Who on earth would install a driver from the website of AMD on Linux? Except for companies maybe.

[agd5f]

Who on earth would install a driver from the website of AMD on Linux? Except for companies maybe.

Lots of people coming from windows.

[Brutalix]

Lots of people coming from windows.

Any chance of getting AMD link to linux as well? .. I actually like to monitor all computers via a nice little app, and it seems able to be run locally with no external net, just your local lan.
Tested it on some windows pc's and it worked very well.
Well to be honest opengl, opencl and vulcan functions/speed are more important i guess.

Kind regards.
B.

[duby229]

Lots of people coming from windows.

Which is good and expected, but AMD really should have a helpful and informative document explaining to those windows uaers how desktop Linux uses package management to maintain local package installations. There are very good reasons to encourage users to never install anything outside of package management. You know what those good reasons are I'm very sure. I haven't looked at it at all though, so this really is just a reaction to your comment.


Windows users are especially vulnerable to breaking their linux installations due to installing things outside of package management, so it's especially them that should be encouraged to not do so.

[Kombatant]

Which is good and expected, but AMD really should have a helpful and informative document explaining to those windows uaers how desktop Linux uses package management to maintain local package installations. There are very good reasons to encourage users to never install anything outside of package management. You know what those good reasons are I'm very sure. I haven't looked at it at all though, so this really is just a reaction to your comment.


Windows users are especially vulnerable to breaking their linux installations due to installing things outside of package management, so it's especially them that should be encouraged to not do so.

It's not that easy to educate Windows users, they are just used to another way; and it's not their fault, mind you. What I usually do, is draw parallels to the various appstores they use for their mobile devices in order for them to understand the logic behind how modern distros deal with software (and politely point out that Microsoft is building a package manager within Windows right now, so they'd better wait for it).

[twriter]

This is getting so complicated! I think I need a fucking flowchart to understand all the options.

Do you consider the following instructions complicated?

1. Add AMDGPU package repository to /etc/apt/sources.list.d
2. Run "sudo apt update"
3. Run "sudo apt install amdgpu"

That's pretty much what the amdgpu-install script does. It's a simple script wrapper around the native package manager. The main difference is you have to download an archive of the package repository first so that amdgpu-install can set it up as a local repository for you. Next step is on-line package delivery. A lot of commenters in these forums use the oibaf ppa (which is a great resource, by the way). This is no different...except the packages have been validated by AMD and we install everything in /opt to avoid conflicts with distro-provided packages.

I have to disagree with Michael when he says, "Part of what would make it more intuitive is if AMDGPU-PRO offered an installation GUI...." Most Linux users are already familiar with native package management so we're trying to take advantage of what you already know, rather than forcing you to learn something different. I agree the documentation could be better and we'll improve it over time.

[twriter]

Which is good and expected, but AMD really should have a helpful and informative document explaining to those windows uaers how desktop Linux uses package management to maintain local package installations. There are very good reasons to encourage users to never install anything outside of package management.

I agree which is why we're using native package management. Try this:

dpkg -l >/tmp/before
amdgpu-install
dpkg -l >/tmp/after
diff /tmp/{before,after}
apt-cache search amdgpu

[twriter]

Michael, I'd like to correct this:

If running the amdgpu-install script now without any arguments, unlike before where you would get the closed-source driver stack, it's actually defaulting to shipping the open-source component packages. If you want to use the official/closed-source Vulkan and OpenGL drivers from AMD, you need to pass --pro to the install script.

Previous releases included only amdgpu-pro-install. This release includes amdgpu-pro-install and amdgpu-install. amdgpu-pro-install is synonymous with `amdgpu-install --pro', which installs the Pro stack, just like before. The only difference is OpenCL is no longer installed by default, to allow installation of the desired implementation and to correct a previous inconsistency where only the legacy implementation was installed by default.

[agd5f]

Which is good and expected, but AMD really should have a helpful and informative document explaining to those windows uaers how desktop Linux uses package management to maintain local package installations. There are very good reasons to encourage users to never install anything outside of package management. You know what those good reasons are I'm very sure. I haven't looked at it at all though, so this really is just a reaction to your comment.


Windows users are especially vulnerable to breaking their linux installations due to installing things outside of package management, so it's especially them that should be encouraged to not do so.

Our packaged drivers for Linux use native packages.

[duby229]

Our packaged drivers for Linux use native packages.

But from what I can see a windows user coming to linux will never be able to tell that. He'll download and install your package without ever realizing. To him it'll -feel- like he's installing something outside of package management. He'll never learn and he'll keep doing it while claiming your driver instalation as precedence. I just don't see a problem with posting a helpful informative document explaining it.

I'm just saying it happens. Debianxfce is a forum member here who frequently uses AMD's driver installation as precedence. He alone is responsible for misleading people, but he uses your driver in his arguments about it. For all those people that he and others mislead there should be a c;lear well written document explaining it. right there right next to the download link. It should be the very thing you see right before you click download.

EDIT: And let me just mention the fact that if you use a distribution with an unsupported package manager like Gentoo or Arch it doesn't do jack shit and must be installed outside of package management with third party tools. All these complex ass, highly broken instalation scripts with very limited distribution support is a large part of the problem.

You guys can try to claim its ok but it's not ok. Its not. Out of box support for AMD's products are pretty darn good right now, so for most people on most distributions they won't ever have to worry about this crap. And that's highly highly fortunate for AMD. If every new Linux uaser had to deal with this shit AMD's linux hopes would sink fast as hell.

The sooner Ubuntu dies permanently the better off Linux will be. AMD and Valve and others all need to immediately realize that. It's plainly obvious, the -ONLY- solution is get the rest of your code upstream. Stop relying on complex buggy ass distribution dependent installation scripts. Get all of you code released so that distributions themselves can distribute you code exactly as they are meant to in the first place.