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.32
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 .. 33 34 35 36 37 38 39 40 41 42 43 .. 81 Next › Last »

AndyRTR commented on 2021-10-01 18:48 (UTC)

OpenCL won't work on RX460 with latest release here:

https://community.amd.com/t5/drivers-software/linux-opencl-21-30-broken-with-rx460/td-p/491173

toma678 commented on 2021-09-19 19:19 (UTC)

Just to note that the R9 390 stops working with the update to 21.30. Downgrading to 21.20 fixes this. I guess AMD may have dropped support for the 390 in their driver.

<deleted-account> commented on 2021-08-29 23:48 (UTC)

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

AndyRTR commented on 2021-08-28 20:16 (UTC) (edited on 2021-08-28 20:21 (UTC) by AndyRTR)

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

luciddream commented on 2021-08-23 15:36 (UTC) (edited on 2021-08-23 15:38 (UTC) by luciddream)

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.

sperg512 commented on 2021-08-23 11:46 (UTC) (edited on 2021-08-23 11:47 (UTC) by sperg512)

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

maz-1 commented on 2021-08-21 01:30 (UTC) (edited on 2021-08-21 04:08 (UTC) by maz-1)

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

luciddream commented on 2021-08-21 00:29 (UTC)

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

luciddream commented on 2021-08-21 00:20 (UTC)

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

« First ‹ Previous 1 .. 33 34 35 36 37 38 39 40 41 42 43 .. 81 Next › Last »