Package Details: opencl-amd 1:6.2.4-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, hsakmt-roct, hsakmt-roct-dev, libdrm-amdgpu-amdgpu1, openmp-extras-runtime, rocdecode, rocdecode-dev, rocm-clang-ocl, 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, hsakmt-roct, hsakmt-roct-dev, libdrm-amdgpu-amdgpu1, opencl-driver, openmp-extras-runtime, rocdecode, rocdecode-dev, rocm-clang-ocl, 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: 132
Popularity: 0.72
First Submitted: 2016-12-01 03:45 (UTC)
Last Updated: 2024-11-07 20:43 (UTC)

Required by (126)

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.

luciddream commented on 2021-12-26 15:14 (UTC) (edited on 2024-11-07 20:44 (UTC) by luciddream)

Current release is for ROCm 6.2.4 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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 77 Next › Last »

merlock commented on 2024-02-04 22:30 (UTC)

Well, no joy for me. :(

luciddream commented on 2024-02-02 22:46 (UTC) (edited on 2024-02-02 22:46 (UTC) by luciddream)

I've updated to 6.0.2 in a bit of a hurry, so hopefully everything is OK. Blender works fine (finally since latest kernel update), Geekbench works fine as well.

luciddream commented on 2023-12-29 09:17 (UTC)

@nho1ix it would be helpful to post the segfault here just in case it helps with packaging issues. However, I think this time it's probably just a linux kernel bug: https://github.com/ROCm/ROCm/issues/2596

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.

trougnouf commented on 2023-12-28 16:52 (UTC)

I think you would be responsible for maintaining compatibility with the official packages. Can you imagine if official packages did not work together because different packagers disagreed on principles ? It would be a completely dysfunctional distribution. That to me is much more logical than following AMD's guidelines. Anyway thank you for raising an issue about it.

luciddream commented on 2023-12-28 09:55 (UTC)

@trougnouf I'm not responsible for what the maintainers of the official packages decide to do and I don't have to convince them to do anything. I try to follow standards and logic, as should everyone. In any case, I just created an issue about it.

trougnouf commented on 2023-12-27 17:52 (UTC) (edited on 2023-12-27 18:09 (UTC) by trougnouf)

I feel that you did not address any of the points I made, including the main one. I agreed with you that magma shouldn't be part of the ROCm directory but that's no reason to block anything from being part of the ROCm directory. Arch uses /opt/rocm, it goes against the AMD guidelines (/opt/rocm-version) and if you'd like that fixed I think you should raise an issue rather than make a change that's inconsistent and incompatible with the Arch ecosystem.

luciddream commented on 2023-12-26 20:18 (UTC) (edited on 2023-12-26 20:20 (UTC) by luciddream)

I disagree, I think the official packages need to follow the archlinux filesystem hierarchy system. I don't know why they deviate from that (speaking about magma).

opencl-amd just follows the ROCm filesystem hierarchy, while the official packages deviate from that as well.

Let's wait for more comments on the gitlab issue tracker before deciding anything

trougnouf commented on 2023-12-26 18:05 (UTC) (edited on 2023-12-26 18:28 (UTC) by trougnouf)

@luciddream I have an AMD Ryzen 9 6900HS in the laptop and an AMD Ryzen Threadripper 3960X in the desktop.

I tried opening Blender but I get "No compatible GPUs found for Cycles Requires AMD GPU with Vega or RDNA architecture and AMD driver version 22.10 or newer" in the settings (System > HIP).

My feedback for removing the /opt/rocm symlink:

  • I noticed your initial comment in the bug tracker and it hasn't been taken into account while the issue has been ongoing for 9 months now.

  • Mainly I think owning a directory by making it a symlink is bad practice; nothing else is allowed to have anything to do with it. I understand your point that magma did not belong there, but that's no reason to make it nearly impossible to package anything in there, I'm sure there could be legitimate use-case to extend /opt/rocm in some way.

  • I also think that it's unnecessary to even have an /opt/rocm-6.0.0 directory, the version number is not normally added to directories in /usr/share, but it could be kept in an unobstructive way the other way around by making /opt/rocm-6.0.0 a symlink to /opt/rocm (like how /usr/share/zoneinfo-posix, the only symlink in my /usr/share, points to the more generic /usr/share/zoneinfo)

  • The official packages use /opt/rocm rather than /opt/rocm-version. While your package works very differently (everything is packaged in one or two packages and it's really akin to opencl-amd-bin), I think that official packages are a good packaging reference and there is no reason to deviate there.

luciddream commented on 2023-12-25 10:13 (UTC)

@tougnouf

What CPU does your laptop have? I think most issues are with Kernel 6.6+, AMD CPUs and HIP. OpenCL works fine for me in Geekbench and Opencl-Benchmark but Blender freezes when trying to initialize HIP.

About removing the /opt/rocm symlink, I'm not convinced yet it's the right move but I'm open for feedback. I created an issue at magma-hip as I'm not very experienced with AUR or Linux filesystems but I try to be logical. What makes things worse is that I'm working as a C# developer for the past 3 years so I'm not even using Linux all this time - which is sad -.