Package Details: opencl-amd 1:6.4.0-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, libdrm-amdgpu-amdgpu1, openmp-extras-runtime, rocdecode, rocdecode-dev, rocjpeg, rocjpeg-dev, 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, libdrm-amdgpu-amdgpu1, opencl-driver, openmp-extras-runtime, rocdecode, rocdecode-dev, rocjpeg, rocjpeg-dev, 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: 133
Popularity: 0.52
First Submitted: 2016-12-01 03:45 (UTC)
Last Updated: 2025-04-11 22:54 (UTC)

Required by (132)

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.

Latest Comments

« First ‹ Previous 1 .. 66 67 68 69 70 71 72 73 74 75 76 .. 81 Next › Last »

Olympus593 commented on 2018-11-05 15:08 (UTC) (edited on 2018-11-05 15:11 (UTC) by Olympus593)

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 (UTC) (edited on 2018-10-25 10:43 (UTC) by Nightbane112)

@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 (UTC)

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 (UTC) (edited on 2018-10-23 19:33 (UTC) by Gemini)

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 (UTC)

@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 (UTC)

libdrm and lib32-libdrm to 2.4.93-1

ArnaudNux commented on 2018-10-17 22:42 (UTC)

[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 (UTC) (edited on 2018-10-16 10:37 (UTC) by Olympus593)

@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 (UTC) (edited on 2018-10-15 16:28 (UTC) by Nightbane112)

@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 (https://github.com/hughperkins/tf-coriander/issues/74)

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

#!/bin/bash
export GPU_FORCE_64BIT_PTR=1
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100
export GPU_MAX_HEAP_SIZE=100

Olympus593 commented on 2018-10-15 13:40 (UTC) (edited on 2018-10-15 15:06 (UTC) by Olympus593)

@Nightbane112 I am using the amdgpu kernel driver and I have already enabled experimental support (I already double checked to make sure that the driver does load) but every time I try to use OpenCL (for example Blender Cycles Render) it ends with Error -6 CL_OUT_OF_HOST_MEMORY. Same error with DaVinci Resolve.

« First ‹ Previous 1 .. 66 67 68 69 70 71 72 73 74 75 76 .. 81 Next › Last »