Using orca on amdgpu (Kaveri)?

[Berniyh]

Hi,

so I gave it another go trying to use the closed source opencl stack and failed again, I just don't see what I'm doing wrong.
First, my distribution is Exherbo, so not exactly officially supported, but in principle, it should work, I think.
Second, my kernel (4.16) is self-compiled, with the following config (excerpt):

# CONFIG_DRM_RADEON is not set
CONFIG_DRM_AMDGPU=y
# CONFIG_DRM_AMDGPU_SI is not set
CONFIG_DRM_AMDGPU_CIK=y
# CONFIG_DRM_AMDGPU_USERPTR is not set
# CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set

#
# ACP (Audio CoProcessor) Configuration
#
CONFIG_DRM_AMD_ACP=y

#
# Display Engine Configuration
#
# CONFIG_DRM_AMD_DC is not set
CONFIG_DRM_AMD_DC_PRE_VEGA=y

mesa is 18.0.2 (for the moment) and ddx is xf86-video-amdgpu 18.0.1. llvm (does it matter for orca?) is 5.0.1.
APU is a Kaveri:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] (prog-if 00 [VGA controller])
        Subsystem: ASRock Incorporation Kaveri [Radeon R7 Graphics]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 29
        Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M]
        Region 4: I/O ports at f000 [size=256]
        Region 5: Memory at feb00000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: amdgpu

Now I downloaded the Ubuntu version and had a look at the deb files and their deps.
Turns out, I need the contents of these files:

amdgpu-core_18.10-572953_all.deb
amdgpu-pro-core_18.10-572953_all.deb
clinfo-amdgpu-pro_18.10-572953_amd64.deb
opencl-orca-amdgpu-pro-icd_18.10-572953_amd64.deb

Extracted them and did end up with this file list:

/opt
/opt/amdgpu-pro
/opt/amdgpu-pro/bin
/opt/amdgpu-pro/bin/clinfo
/opt/amdgpu-pro/lib
/opt/amdgpu-pro/lib/x86_64-linux-gnu
/opt/amdgpu-pro/lib/x86_64-linux-gnu/libamdocl-orca64.so
/opt/amdgpu-pro/lib/x86_64-linux-gnu/libamdocl12cl64.so
/etc
/etc/OpenCL
/etc/OpenCL/vendors
/etc/OpenCL/vendors/amdocl-orca64.icd

Looks about right to me, those two libs don't have any other amdgpu-related link-time deps afaics.
Added /opt/amdgpu-pro/bin to PATH and /opt/amdgpu-pro/lib/x86_64-linux-gnu to LDPATH and wanted to see if it works, so I run clinfo (doesn't matter if as root or normal user):

clinfo
zsh: segmentation fault (core dumped)  clinfo

Am I doing something wrong? :/

[cde1]

I think I have never been able to have OpenCL working on my A10 APU (Godavari, but very close to Kaveri) using AMDGPU-Pro or the open-source stack. It will probably remain unsupported forever, even on Windows the last driver version that supports it is 17.4. I think AMD has abandoned support for that line of APU since at least a year or so. In fact this has been confirmed to me by someone from AMD.

The best I could do is install fglrx on an old distro such as Debian 8, then OpenCL works.

EDIT: as Berniyh said below, 18.20 appears to support Kaveri/Godavari which is really cool :-)

[Berniyh]

I thought I read that others got it working, hence why I'm asking.

Anyway, even if it wasn't supported, I would expect it to throw an according error message instead of just crashing.

[Berniyh]

Forget it, I've got it working now.
cde1's post in the other thread made me look for & try 18.20 and with that it doesn't segfault and does actually work.

Although the gain in darktable unfortunately wasn't as big as I hoped. Processing times are reduced by ~40-50%.

[cde1]

Forget it, I've got it working now.
cde1's post in the other thread made me look for & try 18.20 and with that it doesn't segfault and does actually work.

Although the gain in darktable unfortunately wasn't as big as I hoped. Processing times are reduced by ~40-50%.

Cool! I assume video output also works? That's something I was never able to get working outside of catalyst (it would just show a black screen).

[Berniyh]

Cool! I assume video output also works? That's something I was never able to get working outside of catalyst (it would just show a black screen).

You mean VDPAU? Yes, that works. In fact it always worked for me since switching to amdgpu and that was since the initial release of xf86-video-amdgpu, so beginning of 2016.

I recently experienced some system crashes, which I think are related to VDPAU (at least they didn't occur since I switched to xv for testing), but apart from that it wasn't a problem for me at all.

Edit: now that OpenCL works, I did some tests with mesa 18.2 git master which is supposed to run up to 2× faster on some workloads.
Question: would it be expected that this improves the performance of OpenCL as well?
Because it seems to be the case. In darktable, I did some raw performance testing before on an image I already edited previously. On top of that I did some WB changes, so the whole stack + the WB is computed and darktable gives you a time for each step and the whole thing:
Only CPU: ~2.5s
GPU mesa 18.0: ~1.4-1.6s
GPU mesa 18.2: ~0.7-0.8s

I was a bit surprised by this as I thought that the change in mesa should only affect OpenGL-rendering?
But I take it anyway.
A change from (initially 2.5s) to <1s for a huge image editing stack is a very pleasant result.