Package Details: opencl-amd 19.10.785425-1

Git Clone URL: (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:
Keywords: amd amdgpu computing gpgpu opencl radeon
Licenses: custom:AMD
Conflicts: amdgpocl
Provides: opencl-driver
Submitter: grmat
Maintainer: grmat
Last Packager: grmat
Votes: 66
Popularity: 3.424994
First Submitted: 2016-12-01 03:45
Last Updated: 2019-05-12 12:40

Required by (22)

Sources (1)

Latest Comments

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

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

pkgdesc="OpenCL userspace driver as provided in the amdgpu-pro driver stack. This package is intended to work along with the free amdgpu stack."
depends=('libdrm' 'ocl-icd')

DLAGENTS='https::/usr/bin/wget --referer -N %u'



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"

    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 ""
    mv "" ""
    ln -s "" ""

    mv "${srcdir}/opencl/etc" "${pkgdir}/"
    mkdir -p ${pkgdir}/usr/lib
    mv "${srcdir}/opencl/${shared}/" "${pkgdir}/usr/lib/"
    mv "${srcdir}/opencl/${shared}/" "${pkgdir}/usr/lib/"
    mv "${srcdir}/opencl/${shared}/" "${pkgdir}/usr/lib/"
    mv "${srcdir}/libdrm/${shared/amdgpu-pro/amdgpu}/" "${pkgdir}/usr/lib/"
    mv "${srcdir}/libdrm/${shared/amdgpu-pro/amdgpu}/" "${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 (with an O?)

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

blender(BLI_system_backtrace+0x34) [0x55e1e8b59b84] blender(+0xb7b8b2) [0x55e1e80e58b2] /usr/lib/ [0x7fce6db09e00] /usr/lib/ [0x7fce485acbdf] /usr/lib/ [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.


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

ArnaudNux commented on 2018-10-17 22:42

[root@AMD fah]# ./FAHClient --configure 22:40:42:INFO(1):Read GPUs.txt amdgpu_device_initialize: DRM version is 2.50.0 but this driver is only compatible with 3.x.x. No protocol specified

Olympus593 commented on 2018-10-16 04:56

@Nightbane112 It sort of works but very unstable. Obviously, every time I need an app to use OpenCL I must launch it from a terminal to make OpenCL "sort of work"

In blender, it takes 3 tries before it stats to render but it is ridiculously slow (like CPU is several times faster. If you try to hit render again, blender will crash.

On Resolve thumbnail previews are completely useless, playback and render does work, however when using power windows resolve crashes.

Still very buggy. I think it is because of the experimental SI support. I wish I didn't have to launch every app via terminal.

Nightbane112 commented on 2018-10-15 16:28

@Olympus593 From the looks of it, I don't think its a driver problem. A bit of searching online lead me to this issue on GitHub (

How about appending this to your bashrc file and see if it changes anything?

export GPU_FORCE_64BIT_PTR=1
export GPU_MAX_HEAP_SIZE=100