Arch Linux User Repository

Note for anyone who has a Polaris GPU (Radeon RX 5xx) debugging issues with this package; Packages that use OpenCL like clinfo or davinci-resolve-studio will need you to downgrade opencl-amd to 1:5.7.1-1 as well as amdgpu-pro-oglp to 23.10_1620044-1 to avoid coredumps & segfaults.

DVR would not open unless these 2 packages were downgraded (along with their dependencies). Had to figure it out the hard way after hours using valgrind and rebooting over and over. Hopefully someone else will not have to pull their hair out trying to resolve their issue.

Current release is for ROCm 6.1.2 opencl-amd package includes only OpenCL / HIP runtime. You also need to use opencl-amd-dev package for ROCm LLVM compiler, OpenCL and HIP SDK. Please relog / reboot after installing so your PATH gets updated

There are now official packages available: rocm-opencl-sdk for OpenCL and rocm-hip-sdk for HIP - You might have better luck with these packages depending on your GPU.

I'm preparing the new release and I noticed there is already a EULA for any proprietary component we use, since probably forever. So I guess we are already violating that. Maybe it's better to add it in the description of the package.

No issues with amdgpu-llvm, except it takes up allot of space. Even though rocm-llvm is a "depends" of the hip-runtime-amd .deb its probably best it's left in opencl-amd-dev. No idea about EULAs and the proprietary opencl-legacy-amdgpu-pro-icd sorry. Thanks for the hard work!

In the 5.1 release notes there is a notice that the use of closed source rocm parts requires an agreement with their EULA. I wonder how other packages are dealing with this, if there is an example I can check before I make the release (if the closed source parts are necessary)

5.1 / 22.10 has just appeared at https://repo.radeon.com/

Nice, I will try to take a look later in the evening.

Fingers crossed the Blender HIP implementation doesn't require the rocm-llvm provided in the opencl-amd-dev.

Why do you say that? Because of disk size required? Or did you have any other issues with it

Here we go again... 5.1 / 22.10 has just appeared at https://repo.radeon.com/ This version should eventually work with Blender nightly 3.2 compiles. Fingers crossed the Blender HIP implementation doesn't require the rocm-llvm provided in the opencl-amd-dev.

Or somebody does not create a binary repo/pkgbuild for that.

Even if they do (ROCm is already available on the arch4edu repository), there are still some things that will keep opencl-amd alive, I believe. First it would need to have a good level of trust (who builds the package, how does it build, and does the source code match with the binary), second it would need to be updated fast, and from what I can see, it's a gigantic effort to keep it updated. opencl-amd provides updates fast because it just copies files, but of course that comes with a few disadvantages.

The only thing, this should be indicated to users. Can you then please mark it in the description and in ArchWiki? Currently it says that it is ROCr, but better maybe something like "ROCr OpenCL and legacy/orca OpenCL repackaged from AMD's ubuntu releases".

Sure, I will update the description on the next release with the descriptions from the amdgpu-install documentation.

opencl-amd follows the pattern of the amdgpu-install deb file It provides the whole Compute package for AMD GPUs

I think you mean running it amdgpu installer with opencl=rocr,legacy.

If you think the legacy libraries should be it's own package, you are free to create one.

Of course.

Until AMDGPU / ROCm binaries end up in the official repositories, there will always be a need to provide a binary of that compute package.

Or somebody does not create a binary repo/pkgbuild for that.

I don't think there is a reason to continue debating it further.

I am not blaming you. I understand your position. Just wanted to know what that is, because there were lots of comments here, and I did not followed them carefully.

The only thing, this should be indicated to users. Can you then please mark it in the description and in ArchWiki? Currently it says that it is ROCr, but better maybe something like "ROCr OpenCL and legacy/orca OpenCL repackaged from AMD's ubuntu releases".

@Ashark

That is some nice inside details Jeremy got for us, and thanks for contacting him, but I'm afraid it does not affect opencl-amd. As fun and entertaining this discussion has been, and we both gained some extra knowledge, reminder that opencl-amd follows the pattern of the amdgpu-install deb file, which is what I described in my previous comments. I don't intend to change that, unless AMD changes that pattern.

And with arch's rules we should replace ahyphen with underscore.

In order to be better compliant with the Arch rules, and the build id is not really needed (I explained the reason in the previous comments), I think it's better I remove the build id on the next AMDGPU / ROCm release to avoid any further confusion. So it will be 21.51.50100 going forward.

Why do you repack the rocm itself? As it is open source, there is no point in that. Jeremy also does not recommend that.

Is there a reason to explain again why this package exists? It provides the whole Compute package for AMD GPUs, and I (and I think other people too) find it useful. If you think the legacy libraries should be it's own package, you are free to create one. Until AMDGPU / ROCm binaries end up in the official repositories, there will always be a need to provide a binary of that compute package. The advantage of this package is that people can trust it, because it comes from AMD directly (we are only copying their files)

p.s This is getting repetitive and we are clearly have very different opinions on how to deal with the packages, I don't think there is a reason to continue debating it further. All the users of the opencl-amd and opencl-amd-dev packages can express their opinions on how and what it packages and I've modified it in the past to include their suggestions, but in the end of the day it's my responsibility (as long as I maintain / co-maintain the packages) to provide my best effort solution for them.

@luciddream, Jeremy Newton explained the versioning, see previous comment. He does not recommend to use 50002 in version, also we should use amd's identifier to be precise. And with arch's rules we should replace a hyphen with underscore. He suggests 21.50.2_1384495-1 for that.

But here another question arises. Why do you repack the rocm itself? As it is open source, there is no point in that. Jeremy also does not recommend that. There are already rocm-opencl-runtime and rocm-hip-runtime packages. This package should only package the legacy (a.k.a. orca) opencl I think.

About versioning scheme used by amd (thanks to Jeremy's explanation):

Example of package name: amdgpu-pro_21.50.2-1384495_amd64.deb

21.50.2 - This is the release number.
21 - this is the year it started development.
5 - fifth release branch created in 2021 from amd's development trunks (resets to 1 each year). Not dependent on months.
0 - is added to allow inserting more releases if required (see below).
2 - this is revision (fix) fox the release. The release originally has no revision (21.50). Then the revision of it may be released (21.50.1).

in rocm packages:
50002 - This is to show that it's tied to the 5.0.2 release of ROCm (5.00.02), this serves very little value to amdgpu-pro binaries.

in amdgpu-pro packages:
1384495 - This is just a unique identifier. Amd stick it in the release field of packages they releases (it is debian_revision, identical meaning as pkgrel in pkgbuilds).

Q: Why/when after 20.40 would amd release 20.45 or 20.40.1 instead of 20.50?
A: When 20.50 was already branched, but it was delayed due to issues, so 20.45 was branched from an earlier point.

Q: Then when it is not applied the logic of second revision like 20.40.1?
A: It is similiar to how mesa has a "21.3" branch, and tags mesa-21.3.0 through mesa-21.3.8 representing different git commits on that branch. Amd has an internal 21.50 branch, and 21.50/21.50.1/21.50.2 represents different points on that branch.