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: 65
Popularity: 3.637088
First Submitted: 2016-12-01 03:45
Last Updated: 2019-05-12 12:40

Required by (22)

Sources (1)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Ashark commented on 2019-05-18 17:25

@grmat, ok, thanks for explanation. But I think you may remove it now, as it is a bit confusing and anyway it was done several years ago, so no one affected person remaining I think. In readme there is no info that you said (about that you done it for co-existance of both versions), so I suggest you to place it there and also remove amdgpocl mentioning.

grmat commented on 2019-05-16 19:13

@Ashark: amdgpocl was the name I've been using for this package before this opencl-amd, which suits the arch package names better. The closed driver includes another version of the libdrm. The free one doesn't contain all the functionality and is more frequently updated. The renaming is a workaround to be able to use the free libdrm with the free stack alongside this one with opencl-amd. See readme for more info

@francoism90: if clover (mesa) works for you, I'd prefer that. E.g. It doesn't for cycles (blender). The two don't conflict as they both use icd

Ashark commented on 2019-05-16 03:58

@grmat can you please explain why this package conflicts with amdgpocl? I cannot see any package providing that. And why do you rename libdrm_amdgpu to libdrm_amdgpo? Edit: I explored a git history of this package and saw that it was named amdgpocl previously. Then it needed to use replaces instead of conflicts array. I think it could be removed now. And amdgpO naming was done sinse initial commit, I still do not understand why.

kode54 commented on 2019-05-13 00:49

Well, I haven't benchmarked, but it did offer actually-working-with-blender-benchmark, which I've since learned does very bad things, being pre-2.79 Blender.

Also, this OpenCL runtime causes DaVinci Resolve to crash on startup, I haven't tested if installing opencl-mesa fixes that yet, since I got so pissed at it crashing once again that I uninstalled it and deleted the download package.

francoism90 commented on 2019-05-12 19:36

Any benchmark available against opencl-mesa? It doesn't seem to conflict either, does this package offer any features not provided with the open-source one?

kode54 commented on 2019-05-08 07:00

Here is an updated PKGBUILD, with the current version included in the revision history for comparison:

EgoistAnarchist commented on 2019-02-26 01:58

@Olympus593 How do I append a null kernel to individual programs? I'm not sure what this means exactly.

Olympus593 commented on 2018-12-25 14:40

@grmat same copy to host problem on SI and CI cards. The only known workaround is by appending a null kernel but it can only work for individual programs

grmat commented on 2018-12-22 15:14

I've updated to 18.50, but I don't own a CI card anymore, so please let me know if there are problems with older hardware (even better if you already know workarounds that could be included).

BTW, if you feel like the package updates are too slow and want to jump in as co-maintainer, just contact me.

agapito commented on 2018-12-22 12:27

Libdrm workaround is not needed anymore. I am using blender-git package and opencl-amd 18.50. I can render using CPU + GPU.