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.

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.

@luciddream Thanks, I asked Jeremy by email. I will write what is his opinion.

@Ashark I agree with keeping the build number for now, but to be honest I don't think it is needed. I was looking for conspiracies, but with a clearer mind now, the versioning for AMD is much simpler than I tried to make it. They just concatenate the two release versions: AMDGPU (21.50.2) and ROCm (50002). So this is actually the release version of the driver as a whole. As a filename, it doesn't make much sense, because they have never released the same AMDGPU release with a different ROCm release, and I doubt they plan to. I guess it's easier for them to just make a new release for both AMDGPU and ROCm stacks, when they want to update either of them. The version numbers seem to align on every release since the first one (21.40). So the next version for ROCm 5.1 will have AMDGPU 21.51, and the installation file will be amdgpu-install_21.51.50100-1_all.deb

How the repositories are structured is documented here but it's very simple and vague. What each number represents is documented here

I've also found Jeremy's email at the AMDGPU Stack documentation. Maybe we can ask him for more information on how they plan to continue making releases, but I don't think they plan to change it, since it already works as it is. (AMDGPU dot ROCm version)

I think it is required to register there to be able to see his email. Probably yes, too much effort for just version number. You know, let's then keep the versioning as it is now. As you said, keeping 50002 is meaningful for rocm. And I also wish that build number 1384495 to be presented, so I can check if this package matches my packages (amdgpu-pro-libgl). I have just replaced needed parts of string in my checker.

@Ashark I guess the closest you could get to an AMD employee that has also packaging knowledge would be Jeremy Newton

Then maybe the Debian mail list for comments from other packagers. But maybe this is too much effort for just a version number.

Do you know where is their mailing list? Another source of communication with them I think may be the email they used for packages (in control information).