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.3.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 getting the same issue as @IMBJR

Switching to the mesa OpenCL driver or cpu rendering works as expected.

Images: https://imgur.com/a/z6JoqI5

I don't see anything wrong in the shared libraries:

 ldd -v /usr/bin/clinfo
linux-vdso.so.1 (0x00007fff631f6000)
libOpenCL.so.1 => /usr/lib/libOpenCL.so.1 (0x00007fc7ab84b000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc7ab844000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fc7ab678000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc7ab8d3000)

Version information:
/usr/bin/clinfo:
libdl.so.2 (GLIBC_2.2.5) => /usr/lib/libdl.so.2
libOpenCL.so.1 (OPENCL_1.0) => /usr/lib/libOpenCL.so.1
libc.so.6 (GLIBC_2.3) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.7) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.14) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /usr/lib/libc.so.6
/usr/lib/libOpenCL.so.1:
libdl.so.2 (GLIBC_2.2.5) => /usr/lib/libdl.so.2
ld-linux-x86-64.so.2 (GLIBC_2.3) => /usr/lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.3.4) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.33) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /usr/lib/libc.so.6
/usr/lib/libdl.so.2:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /usr/lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_PRIVATE) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /usr/lib/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /usr/lib/libc.so.6
/usr/lib/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /usr/lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_2.3) => /usr/lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /usr/lib64/ld-linux-x86-64.so.2

@tyler19820201: I can confirm all packages here build well. But any version after I had tried after 20.40.1147286-1 will make clinfo hang at the end infinitely on my Ryzen 5 4500U. Not sure if would work stable though. So use that version for now. There were rather huge changes at 20.45.1164792 and later when comparing the file list. See also @pikasalt comment 2021-07-26.

Maybe someone has an idea what could be the reason and if this will get fixed in the future. Right now I'm thinking about a new Ryzen 5700G based system where I need basic stable image support for darktable.

FYI I've opened a topic on Arch Forum asking what the process would be to transfer this to a new pkgbase. I'm more worried about that process than maintaining the 32bit parts. But maybe you already know how to do that.

The most important thing is that a lot of people depend on this package for their systems so I don't want to unnecessarily create troubles for them. So if we change the pkgbase we should be extra careful not to break it.

Personally I don't really know if that's necessary. Many users might not need the 32-bit libraries. Probably more than who needs it. Ideally, I think we could simply merge the two into the same PKGBASE, downloading the exact same tarball, and then install from there? I think that would work, correct me if I'm wrong. If it doesn't, it might just be possible to have lib32-opencl-amd install both, but that'd be a lot of work aswell...

Unfortunately, like luciddream, if they were merged l probably wouldn't be able to maintain the package very well. Especially since I not only switched to Gentoo some time ago (and thus have to update stuff on my Arch server), but also because the school and soccer years just started.

However I think a while back someone sent me a PKGBUILD that was a lot better than the current one. I think I'll grab that one and see if it's possible to adapt it to include 32-bit libs

@luciddream yes,lib32-opencl-amd is not a complete package like opencl-amd and you only have to deal with two deb files.

If you read my patch below, you will see it uses generally the same command as opencl-amd to extract files from orca and libdrm, just to substitue "/usr/lib" with "/usr/lib32" and "64" with "32", provide $shared_32 and $shared2_32.

To test if 32bit opencl works, use clinfo from clinfo-amdgpu-pro_21.30-1290604_i386.deb.

@maz-1 actually let me test it a bit locally tomorrow maybe it's easier than I thought it is. But if anyone wants to give their opinion feel free to do so.

@maz-1 I did thought about it a bit and I still don't see a reason to merge these packages. Personally I spend at least 1 hour reading all changes and comparing files etc when I update this package, and I will not be able to do that when I can't verify if the files are working properly. Plus it will double the work needed for each update.

If there is popular demand for it though maybe it's OK for someone to merge it but I don't think I will be able to keep maintaining the package in that state.

(p.s I'm not sperg512, I just co-maintain this package the last year or so).

@sperg512 I think seperate lib32 packages are for packages built from source. lib32-opencl-amd share the same zip file with opencl-amd so it should be ok to built both packages from one package base. Besides lib32-opencl-amd requires opencl-amd and install it will download the same zip file twice if lib32-opencl-amd is a seperated package. You can check out nvidia-vulkan and amdgpu-pro-installer in aur.

@maz-1 why not create another package lib32-opencl-amd ? It looks to me most AUR packages use that strategy for 32bit software. Having it in one package will make it harder to maintain and to verify updates. But that's just my opinion.