Package Details: opencl-amd 1:6.1.2-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: 1.33
First Submitted: 2016-12-01 03:45 (UTC)
Last Updated: 2024-06-05 21:12 (UTC)

Required by (115)

Sources (39)

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-06-05 21:14 (UTC) by luciddream)

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

Latest Comments

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 22 23 .. 77 Next › Last »

limsandy commented on 2022-04-01 16:09 (UTC)

Oh I'll be damned.... I put this line in /etc/udev/rules.d/30-radeon-pm.rules

KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="high"

Everything in single line, that's a space before the ATTR.

Now power_dpm_force_performance_level is set to high after reboot. Still you've got to make sure that power_dpm_state is set to performance. Notice that the drivers is now set to "amdgpu"?

limsandy commented on 2022-04-01 12:22 (UTC)

Nope, still doesn't work. I think it's got to do with this file name: /etc/udev/rules.d/30-radeon-pm.rules

Like the udev doesn't read this file unless it's got the right file name.

I'll work something out later, but on a closing remark.... AMD's still gotta work on how the Radeon drivers is not clocking up high/fast enough when there is a work load being placed in the queue. Even after setting the performance level to 'high', I see the Vddgfx downvolting to 0.574V, which means it's allowed to downclock. On the positive side, my APU stays cool at 35-36C which is very near to my ambient temp.

limsandy commented on 2022-04-01 12:14 (UTC)

@luciddream,

Thank you for that link. I tried but it didn't work. This file didn't even exist: /etc/udev/rules.d/30-radeon-pm.rules

So I manually create the file and paste this: KERNEL=="dri/card0", SUBSYSTEM=="drm", DRIVERS=="radeon", ATTR{device/power_dpm_force_performance_level}="high"

It turns out my KERNEL name is wrong. On my sytem, it's just "card0". I've made the change accordingly, and restarting my computer now....

luciddream commented on 2022-04-01 11:32 (UTC) (edited on 2022-04-01 11:33 (UTC) by luciddream)

I've never done this but I guess https://wiki.archlinux.org/title/ATI#Persistent_configuration should work? In any case post your findings, it might be helpful for other people.

limsandy commented on 2022-04-01 11:28 (UTC)

Okay, I think I was celebrating too early. As I said, I was using OpenCL to do VDF verification for running node/farmer for a cryptocurrency program. It can use the CPU (slower) or GPU (with OpenCL) to keep in sync with the current blockchain height.

Under Win 10, with the same computer I'm consistently getting ~0.2 seconds. Under Manjaro, using the CPU, I get 2.7 - 3.0 seconds. With OpenCL, I'm getting 0.3xxx seconds, which is okay if it had been consistent. But sometimes I'm still getting 14 or 18 seconds.

ROCm OpenCL did not work for my APU. Setting the power level to 'high' really helps, but then it always reverts back to 'auto' after reboot. And sudo/root user is needed to change this setting. Can anyone tell me how to write a script that change this setting at reboot with root permission?

sudo nano /sys/class/drm/card0/device/power_dpm_force_performance_level

luciddream commented on 2022-04-01 11:16 (UTC) (edited on 2022-04-01 11:17 (UTC) by luciddream)

@limsandy

Good to hear, so ROCm OpenCL (or maybe Orca) works for your APU? Maybe you can share what you did to fix it so we can add it to Arch Wiki or something.

VDF verification times range from 0.3 all the way to 18 seconds.

What is VDF verification? I'm always looking for more tools to use and compare the performance after every release.

limsandy commented on 2022-04-01 11:04 (UTC)

@luciddream,

With the latest version 22.10, clinfo doesn't return segmentation fault anymore. So it's a good start.... I was even able to use OpenCL in the program that I wanted to use.... But the performance is sometimes a hit and a miss. VDF verification times range from 0.3 all the way to 18 seconds.

I thought this is due to the Radeon power profiles, so I've been messing with it.... Setting performance to 'high' as per instructed at https://wiki.archlinux.org/title/AMDGPU#Power_profiles

I FIXED IT! Thank you so much for updating this, luciddream!

apaz commented on 2022-03-31 21:20 (UTC)

22.10 works for me without any problems (5700xt). Geekbench gives the same results as always. I still need to do more extensive testing. Thanks!

luciddream commented on 2022-03-31 19:12 (UTC) (edited on 2022-03-31 19:35 (UTC) by luciddream)

With the new version I get about 7000 lower score in Geekbench compute, but I also did a BIOS update recently so maybe that's why.

luciddream commented on 2022-03-31 19:02 (UTC)

I have made a new release for both opencl-amd and opencl-amd-dev, I don't feel very confident about them so please send any feedback.

I want to make some extra changes but I can't really justify taking so much time for a release, so I hit the push "button". The process is straight forward, so I will try before next minor release to have a script or program ready to make updating very fast, compared to what it is now (completely manual).