Package Details: opencl-amd 1:6.4.0-1

Git Clone URL: https://aur.archlinux.org/opencl-amd.git (read-only, click to copy)
Package Base: opencl-amd
Description: ROCm components repackaged from AMD's Ubuntu releases (ROCr runtime, ROCm runtime, HIP runtime) - This package is intended to work along with the free amdgpu stack.
Upstream URL: http://www.amd.com
Keywords: amd amdgpu computing gpgpu opencl radeon
Licenses: custom:AMD
Conflicts: amd-smi-lib, comgr, hip, hip-dev, hip-doc, hip-runtime-amd, hip-samples, hipcc, hsa-amd-aqlprofile, hsa-rocr, hsa-rocr-dev, libdrm-amdgpu-amdgpu1, openmp-extras-runtime, rocdecode, rocdecode-dev, rocjpeg, rocjpeg-dev, rocm-cmake, rocm-core, rocm-dbgapi, rocm-debug-agent, rocm-device-libs, rocm-gdb, rocm-hip-runtime, rocm-language-runtime, rocm-ocl-icd, rocm-opencl, rocm-opencl-dev, rocm-opencl-icd-loader, rocm-opencl-runtime, rocm-smi-lib, rocm-utils, rocminfo, rocprofiler, rocprofiler-dev, rocprofiler-plugins, rocprofiler-register, roctracer, roctracer-dev
Provides: amd-smi-lib, comgr, hip, hip-dev, hip-doc, hip-runtime-amd, hip-samples, hipcc, hsa-amd-aqlprofile, hsa-rocr, hsa-rocr-dev, libdrm-amdgpu-amdgpu1, opencl-driver, openmp-extras-runtime, rocdecode, rocdecode-dev, rocjpeg, rocjpeg-dev, rocm-cmake, rocm-core, rocm-dbgapi, rocm-debug-agent, rocm-device-libs, rocm-gdb, rocm-hip-runtime, rocm-language-runtime, rocm-ocl-icd, rocm-opencl, rocm-opencl-dev, rocm-opencl-icd-loader, rocm-opencl-runtime, rocm-smi-lib, rocm-utils, rocminfo, rocprofiler, rocprofiler-dev, rocprofiler-plugins, rocprofiler-register, roctracer, roctracer-dev
Submitter: grmat
Maintainer: sperg512 (luciddream)
Last Packager: luciddream
Votes: 133
Popularity: 0.54
First Submitted: 2016-12-01 03:45 (UTC)
Last Updated: 2025-04-11 22:54 (UTC)

Required by (132)

Sources (38)

Pinned Comments

nho1ix commented on 2023-12-29 08:43 (UTC) (edited on 2024-02-10 07:13 (UTC) by nho1ix)

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.

Latest Comments

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 81 Next › Last »

Ashark commented on 2022-03-26 02:06 (UTC) (edited on 2022-03-26 13:57 (UTC) by Ashark)

@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.

Ashark commented on 2022-03-26 01:54 (UTC) (edited on 2022-03-26 13:56 (UTC) by Ashark)

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.

Ashark commented on 2022-03-24 20:47 (UTC)

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

luciddream commented on 2022-03-24 19:59 (UTC) (edited on 2022-03-24 20:15 (UTC) by luciddream)

@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)

Ashark commented on 2022-03-24 13:02 (UTC)

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.

luciddream commented on 2022-03-23 15:24 (UTC)

@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.

Ashark commented on 2022-03-23 14:56 (UTC)

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).

luciddream commented on 2022-03-23 14:07 (UTC) (edited on 2022-03-23 14:09 (UTC) by luciddream)

@Ashark the pages you linked, have download links to deb files that include the 50002 number. Since the original deb is a package that includes all files for AMDGPU(Pro) and ROCm, I think it's better to keep one version string for all of them, and that's the version string from the amdgpu-install file, which is what people use to install it on official supported distros. In the end, what AUR helpers or makepkg does is create a package that uses this versioning scheme to make a similar package to the Ubuntu / CentOS one.

My assumption for why they are doing this is that while the human readable driver release is 21.50.2, that gives them the freedom to silently release an update when something goes wrong, without the need to create new pages for it. But maybe it's wrong assumption. I'm open to discussing it further and removing both numbers if there is feedback from an AMD employee (maybe we can post a question on their mailing list), but I think 21.50.2.50002-1 will be following their current reasoning for package versioning.

Ashark commented on 2022-03-23 13:23 (UTC) (edited on 2022-03-23 13:25 (UTC) by Ashark)

from the AMD drivers page

Can you please link it? Because I only see the pages I mentioned. For example, the rx590 product page, the 21.50.2 release page.

50002 is not the build number, it's ROCm version number

I understand that. I saw in PKGBUILD. But where I can see it as a user? Can you edit the url upstream link so it is more precise?

I assume that AMD developers have a reason to link ROCm version with the AMDGPU version

Maybe.

about 90% of the package is ROCm related files

Oh, I see now. Then yes, the 50002 should stay in the version number. But then another question. If this package is actually rocm, than where did that 21.50.2 came from? Should not this package version be like just 50002_72-1?

luciddream commented on 2022-03-23 12:55 (UTC)

@Ashark The deb I linked is the one from the AMD drivers page. 50002 is not the build number, it's ROCm version number so I assume that AMD developers have a reason to link ROCm version with the AMDGPU version. For opencl-amd it makes even more sense, because about 90% of the package is ROCm related files, and not amdgpu files.

So I disagree with you, I think the correct version should be 21.50.2.50002-1 like the upstream version AMD is using. Worst case should be 21.50.2.50002_1384495-1 but I think it would be fine to remove the minor version.

p.s Unless an AMD employee clarifies the versioning scheme I think all we can make is assumptions on why it is like this.

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 81 Next › Last »