Package Details: opencl-amd 19.20.812932-1

Git Clone URL: https://aur.archlinux.org/opencl-amd.git (read-only)
Package Base: opencl-amd
Description: OpenCL userspace driver as provided in the amdgpu-pro driver stack. 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: amdgpocl
Provides: opencl-driver
Submitter: grmat
Maintainer: grmat
Last Packager: grmat
Votes: 67
Popularity: 2.983272
First Submitted: 2016-12-01 03:45
Last Updated: 2019-07-19 18:25

Required by (21)

Sources (1)

Latest Comments

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

Olympus593 commented on 2018-11-14 13:13

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

linnaea commented on 2018-11-12 16:56

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

Olympus593 commented on 2018-11-12 16:31

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

linnaea commented on 2018-11-12 03:04

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.

Olympus593 commented on 2018-11-05 15:08

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

Nightbane112 commented on 2018-10-25 10:23

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

urbenlegend commented on 2018-10-25 02:09

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"
}

Gemini commented on 2018-10-23 19:15

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

Gemini commented on 2018-10-23 18:35

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

kenzhishi commented on 2018-10-19 07:16

libdrm and lib32-libdrm to 2.4.93-1