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.

@linnaea only AMD can fix the issue but most likely they will never fully develop SI and CIK support.

@Olympus593 I just gave up and ended up using pci passthrough with VM running an older distro. I'm toying with cltorch here.

That crash is probably caused by the same problem causing OpenCL CTS to segfault. CTS segfaults randomly during async copy to host, and if it doesn't segfault, only the first several hundred bytes of the data can pass CTS verification so it's still worthless.

Feels like a timing issue to me, but there's not much anyone can do about that.

@linnaea I am able to run DaVinci Resolve with only one problem. When using power windows and GPU accelerated fusion, it crashes. Mostly because it does not even meet minimum standards when it comes to usability.

For the time being SI support is pretty much unusable for any purpose, it fails OpenCL Conformance Tests pretty spectacularly, failing 67 out of the 77 tests before segfaulting the test program during async copy test.

It even fails 9 out of the 11 basic fp/int math tests, and all of the type convertion tests.

And that's on CentOS 7, listed as supported by AMD.

Updated to 18.40 and latest linux and linux-firmware package and still very buggy SI support. Or maybe I have everything misconfigured.

@urbenlegend Does this opencl works if you hold back libdrm to ver 2.4.93 with the updated package?

EDIT: Just tested the new PKGBUILD. Updated package works as long libdrm is at ver 2.4.93

As long AMD supplies libdrm at ver 2.4.92, the last backward compatible version is upstream's libdrm 2.4.93 as hinted in the following line

ar x "${srcdir}/${prefix}${major}-${minor}-${targetos}/libdrm-amdgpu-amdgpu1_2.4.92-${minor}_amd64.deb"

Just tried modifying PKGBUILD to get the latest 18.40 release. Blender still crashes with this driver and the latest libdrm.

Here's the modified PKGBUILD if anyone is interested:

# Maintainer: grmat <grmat@sub.red>

pkgname=opencl-amd
pkgdesc="OpenCL userspace driver as provided in the amdgpu-pro driver stack. This package is intended to work along with the free amdgpu stack."
pkgver='18.40.676022'
pkgrel=1
arch=('x86_64')
url='http://www.amd.com'
license=('custom:AMD')
makedepends=('wget')
depends=('libdrm' 'ocl-icd')
conflicts=('amdgpocl')
provides=('opencl-driver')

DLAGENTS='https::/usr/bin/wget --referer https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx -N %u'

prefix='amdgpu-pro-'
major='18.40'
minor='676022'
shared="opt/amdgpu-pro/lib/x86_64-linux-gnu"
targetos='ubuntu-18.04'

source=("https://drivers.amd.com/drivers/linux/${prefix}${major}-${minor}-${targetos}.tar.xz")
sha256sums=('4f71f0a70d68a2d1714902855d1a5e8ccc454b1065182f904cf0f93862cac97c')

pkgver() {
    echo "${major}.${minor}"
}

package() {
    mkdir "${srcdir}/opencl"
    cd "${srcdir}/opencl"
    ar x "${srcdir}/${prefix}${major}-${minor}-${targetos}/opencl-amdgpu-pro-icd_${major}-${minor}_amd64.deb"
    tar xJf data.tar.xz
    ar x "${srcdir}/${prefix}${major}-${minor}-${targetos}/opencl-orca-amdgpu-pro-icd_${major}-${minor}_amd64.deb"
    tar xJf data.tar.xz
    cd ${shared}
    sed -i "s|libdrm_amdgpu|libdrm_amdgpo|g" libamdocl-orca64.so

    mkdir "${srcdir}/libdrm"
    cd "${srcdir}/libdrm"
    ar x "${srcdir}/${prefix}${major}-${minor}-${targetos}/libdrm-amdgpu-amdgpu1_2.4.92-${minor}_amd64.deb"
    tar xJf data.tar.xz
    cd ${shared/amdgpu-pro/amdgpu}
    rm "libdrm_amdgpu.so.1"
    mv "libdrm_amdgpu.so.1.0.0" "libdrm_amdgpo.so.1.0.0"
    ln -s "libdrm_amdgpo.so.1.0.0" "libdrm_amdgpo.so.1"

    mv "${srcdir}/opencl/etc" "${pkgdir}/"
    mkdir -p ${pkgdir}/usr/lib
    mv "${srcdir}/opencl/${shared}/libamdocl64.so" "${pkgdir}/usr/lib/"
    mv "${srcdir}/opencl/${shared}/libamdocl-orca64.so" "${pkgdir}/usr/lib/"
    mv "${srcdir}/opencl/${shared}/libamdocl12cl64.so" "${pkgdir}/usr/lib/"
    mv "${srcdir}/libdrm/${shared/amdgpu-pro/amdgpu}/libdrm_amdgpo.so.1.0.0" "${pkgdir}/usr/lib/"
    mv "${srcdir}/libdrm/${shared/amdgpu-pro/amdgpu}/libdrm_amdgpo.so.1" "${pkgdir}/usr/lib/"

    mkdir -p "${pkgdir}/opt/amdgpu/share/libdrm"
    cd "${pkgdir}/opt/amdgpu/share/libdrm"
    ln -s /usr/share/libdrm/amdgpu.ids amdgpu.ids

    rm -r "${srcdir}/opencl"
    rm -r "${srcdir}/libdrm"
}

update: Wow, it worked! at least up to par with the other setup. But it also fixed the "kernels in a row" bug! Blender OTOH still doesn't even start, segfaulting at trying to find out the device:

AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead

amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-9) Writing: /tmp/blender.crash.txt

Segmentation fault (core dumped)

-- Here's the backtrace summary, a series of function calls leading to libdrm_amdgpo.so (with an O?)

Blender 2.79 (sub 0), Commit date: 2018-05-26 21:51, Hash 32432d91bbe

backtrace

blender(BLI_system_backtrace+0x34) [0x55e1e8b59b84] blender(+0xb7b8b2) [0x55e1e80e58b2] /usr/lib/libc.so.6(+0x37e00) [0x7fce6db09e00] /usr/lib/libdrm_amdgpo.so.1(amdgpu_get_marketing_name+0xc) [0x7fce485acbdf] /usr/lib/libamdocl-orca64.so(+0x8d871e) [0x7fce4908b71e] [trimmed]

-- I was getting that -9 return code on other openCL stuff too (-36 was another, related to not finding functions), it "can't find the device", notably from clBLAS (NB, no 't' at the end, clblast seem to be more forgiving with our OpenCL 1.1 hardware), but even that seem to be working now, although some results from the example code are a bit weird, like "-nan" instead of a float or too many 0.0000 which suggest rounding problems. (perhaps other constants to set on .bashrc?)

As for Blender, the only suggestion I might have is to disable cycles on compilation (there was a release note back when they finally split the kernels that openCL would only work on 2.78c[1], perhaps still true to SI, only advanced stuff like Baking would not be available, but you WOULD be stuck on that version) and use BlendLuxCore instead, which is just 'out of the oven' with a reboot, re-coded from scratch. All you have to do is download a zip addon. (Arch should have a no-cycles version? is there a cli parameter perhaps?)

Another thing I noticed was that CUDA was mentioned on the installation but I don't think this should be interfering with openCL.

[1] https://en.blender.org/index.php/OpenCL

Edit: added reference

@ArnaudNux I get that message if the Radeon driver is loaded instead of AMDGPU. Have you passed the Kernel Parameter Flags, with your bootloader? (check out the article, linked on previous posts)

@Olympus593 Same problem here, same SI chipset. On a different distro, where I managed to run openCL kernels, clblast example code (cache.c) produces a VERY similar symptom, whereas issuing another kernel to the hardware BEFORE CLEARING (flushing?) the cache breaks the program. The only difference I see is that distro is using the mesa-ocl interface, instead of this "amdocl-orca64" (I tried changing to the amdocl64.icd here in Arch, but didn't work at all, we SHOULD be able to use different "vendor icds" though).

I'll try the recommended bashrc exports to see if Arch gets to at least that same place, past that CL_OUT_OF_HOST_MEMORY.

libdrm and lib32-libdrm to 2.4.93-1