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.53
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 .. 43 44 45 46 47 48 49 50 51 52 53 .. 81 Next › Last »

sperg512 commented on 2021-01-16 01:12 (UTC)

@luciddream Yep, I've tried installing and uninstalling a load of different libraries, none of which seemed to help. LibreOffice once again crashes with OpenCL enabled (like before), but GeekBench works perfectly. I could test Blender but there's a known page fault so I won't. When I feel like coding again (probably by tomorrow) I can see if openCL even works at all with some small sample programs.

luciddream commented on 2021-01-16 01:04 (UTC) (edited on 2021-01-16 01:10 (UTC) by luciddream)

@sperg512 Maybe a long shot but do you have ncurses installed ? It contains a library that might be needed.

If that also doesn't work, try to strace -f clinfo 2>strace.txt - it might reveal more things about the issue.

sperg512 commented on 2021-01-16 00:26 (UTC)

@luciddream yup, I have no idea what's happened. Absolutely every variable I can think of is exactly the same--BIOS settings/version, GPU, PCI bus layout, etc etc. It might be because of the recent GCC/glibc updates. But if it's working for you yeah I've got no clue. I haven't tested any other OpenCL applications though, so when I get on pc again I'll try a few

luciddream commented on 2021-01-15 19:43 (UTC)

@gsus so one thing that is different is gcc-libs. Arch Linux gcc-libs is version 10.x while on Manjaro is 9.x - It may be caused by that.

@sperg512 didn't the package use to work for you? It still works fine on my PC.

gsus commented on 2021-01-15 18:58 (UTC)

@luciddream Sorry about that I forgot to mention. I use Manjaro 20.2.1

The diference of size if for the base 1024 (MiB) vs 1000 (MB)

sperg512 commented on 2021-01-15 16:12 (UTC)

Speaking of distroes, I just booted into my Arch install and yeah, segfaults just like my Artix install. lddebug here: https://sperg.funny.cl/cdn/arch_lddebug_2.txt

Same message in dmesg log, same segfault at the exact same offset, during what I think is linking/binding ios_base to libamdocl64.so. --offline doesn't help, either.

luciddream commented on 2021-01-15 15:55 (UTC) (edited on 2021-01-15 15:57 (UTC) by luciddream)

The thing is that it's not easy to support every distro out there. And if someone has issues with a different distro they need to explicitly mention it. As far as I know it's working fine in Arch Linux.

@gsus are you using Arch Linux or a different distro? I notice your installation size is Tamaño instalado : 238,8 MB while mine says Installed Size : 227.69 MiB

edit: Which is probably the same size after rounding, so probably nothing to worry about.

sperg512 commented on 2021-01-15 15:25 (UTC) (edited on 2021-01-15 15:53 (UTC) by sperg512)

For some reason, with this, clinfo just segfaults on my Artix install. Luckily, I was able to get the LD_DEBUG output (https://sperg.funny.cl/cdn/lddebug.txt), but it still segfaults even then. Seems like it's loading all the correct libraries. ICYW, here's the lddebug.txt from a chroot into my Arch install: https://sperg.funny.cl/cdn/arch_lddebug.txt (could boot into it directly and get it but cba rn)

The error fish gives specifically is:

fish: “LD_DEBUG=all clinfo 2> lddebug.…” terminated by signal SIGSEGV (Address boundary error)

So yeah, I don't know what's going on. However, one thing I'm particularly worried might be the problem is that nothing in rocm-device-libs archive gets installed. Though, I tried installing it to the corresponding directory but that didn't seem to work. Which means it's probably something else, or something with my Artix install. But I've got all the necessary stuff installed, numactl, ocl-icd, etc...

Also @gsus those are warnings not errors. I also get those for all of the libambd* libraries, on both my Artix and Arch installs, so you don't need to set the execution bit, in fact, you usually shouldn't do that for a library, and it wouldn't really do much since it's basically just a bunch of symbols and function definitions.

edit: The last line of the lddebug.txt says this: binding file /usr/lib/libamdocl64.so [0] to /usr/lib/libstdc++.so.6 [0]: normal symbol '_ZNSt8ios_baseD2Ev'

I can't tell if this specifically is crashing it, but it might be. Looks like it's trying to link/bind ios_base or something.

edit2: dmesg log says this: [ 5148.574644] clinfo[24744]: segfault at 8 ip 00007f33d50462b4 sp 00007fffa86b0f90 error 4 in libamdocl64.so[7f33d4faa000+db000]

So the error is in libamdocl64.so. Maaaayyybeee a missing library? I'd at least expect that to say "failed to open shared object" or something.

Directly after this message, it also says: [ 5321.488236] Code: 3b 44 24 08 73 08 89 5c 24 0c 89 44 24 08 8d 43 01 48 8b 55 00 48 89 c3 48 3b 04 24 72 a8 8b 44 24 0c 48 8d 04 40 48 8d 14 c2 <48> 8b 42 08 48 8d 0d 81 f5 07 00 4c 8b 0a 49 89 87 f0 05 00 00 48 which I don't understand in the slightest. Clearly it's some hex, maybe the <48> is like a bad instruction or byte or something, since it's the only one in <>? But there ARE other 48's there, so I've got no clue...

edit3: That last message is some hex in the libamdocl64 library. Specifically, it starts at offset 0x0B128A, and the <48> thing is at offset 0x0B12B4. That's the only place it occurs. So yeah, I think it's the area where it's segfaulting. Later, I might try to grab the assembly and see what's there? Maybe that'll help? Who knows

edit4: Here's the assembly file: http://sperg.funny.cl/cdn/libamdocl64.asm

Also, here's a snippet from that for 0x0B128A to 0x0B12B4:

   b128a:   3b 44 24 08             cmp    0x8(%rsp),%eax
   b128e:   73 08                   jae    b1298 <clCreateContextFromType@@OPENCL_1.0+0x3ac28>
   b1290:   89 5c 24 0c             mov    %ebx,0xc(%rsp)
   b1294:   89 44 24 08             mov    %eax,0x8(%rsp)
   b1298:   8d 43 01                lea    0x1(%rbx),%eax
   b129b:   48 8b 55 00             mov    0x0(%rbp),%rdx
   b129f:   48 89 c3                mov    %rax,%rbx
   b12a2:   48 3b 04 24             cmp    (%rsp),%rax
   b12a6:   72 a8                   jb     b1250 <clCreateContextFromType@@OPENCL_1.0+0x3abe0>
   b12a8:   8b 44 24 0c             mov    0xc(%rsp),%eax
   b12ac:   48 8d 04 40             lea    (%rax,%rax,2),%rax
   b12b0:   48 8d 14 c2             lea    (%rdx,%rax,8),%rdx
   b12b4:   48 8b 42 08             mov    0x8(%rdx),%rax

meaning that if my "theory" is correct, mov 0x8(%rdx),%rax is segfaulting it. Fish mentioned address boundaries, so it might trying to be moving a value into an unallocated RAM address or something, or one it can't access?

gsus commented on 2021-01-15 15:01 (UTC) (edited on 2021-01-15 15:04 (UTC) by gsus)

the version of the package is 20.45.1164792-3

the errors of the ldd -v /usr/lib/libamd*

ldd: atención: no tiene permiso de ejecución para /usr/lib/libamd_comgr.so ldd: atención: no tiene permiso de ejecución para /usr/lib/libamd_comgr.so.1 ldd: atención: no tiene permiso de ejecución para /usr/lib/libamd_comgr.so.1.7.0 [...] (in english is "you don't have execute permission to")

Maybe I need to set the execution bit to the libraries?

here is the output.

https://filedn.com/lsGYnWmDn67jepFm0Ehk7z0/lddlibamd.txt

https://filedn.com/lsGYnWmDn67jepFm0Ehk7z0/opencl-amd.info

luciddream commented on 2021-01-15 13:57 (UTC) (edited on 2021-01-15 14:00 (UTC) by luciddream)

@gsus what version of the package do you use? I don't see it trying to load libamd_comgr.so.1 at all.

edit: also try a ldd -v /usr/lib/libamd* and see if it gives errors.

« First ‹ Previous 1 .. 43 44 45 46 47 48 49 50 51 52 53 .. 81 Next › Last »