OpenCL
Not to be confused with OpenCT.
Open Computing Language (OpenCL) is a framework for writing programs that execute across heterogeneous computing platforms (CPUs, GPUs, DSPs, FPGAs, ASICs, etc.).
Overview[edit | edit source]
The point of this article is to deal with Gentoo implementation and quirks so the overview will be short. For a better overview of the theoretical aspects, see the OpenCL wikipedia article.
OpenCL presents itself as a library with a simple interface:
- Standardized API headers (eg.
#include CL/cl.h
) for C and C++ - The OpenCL library (eg.
libOpenCL.so
)
The standard is made to provide many OpenCL platforms on one system, and each platform can see various devices. Each device has a certain compute characteristics (number of compute units, optimal vector size, memory limits, ...).
The OpenCL standard allows to load OpenCL kernels which are pieces of C99-like code that is JIT-compiled by the OpenCL implementations (most of them rely on LLVM to work), and execute these kernels on the target hardware. Functions are provided to compile the kernels, load them, transfer data back and forth from the target devices, etc.
Hardware vendors can benefit from this standard by implementing the OpenCL primitives for their hardware.
Installing an OpenCL implementation means adding a library implementing the OpenCL API, and a reference to the library path in the ICD (Installable Client Driver) database, as a file in /etc/OpenCL/vendors.
There is an ICD loader which can be provided by a generic loader or one of the implementations. For most uses of OpenCL one of these must be selected using eselect opencl.
The OpenCL host and device API calls, the memory hierarchy are standard, but it doesn't mean that code which is portable to different implementations will be efficient on all of them. Often, code has to be tested on one implementation to eliminate issues. See the implementation validation and implementation tuning sections..
Implementations on Linux[edit | edit source]
Here are upstream projects that provide an implementation of OpenCL.
- pocl is an OpenSource, LLVM-based OpenCL implementation for the CPU which is not necessarily the fastest, but is educational (at this moment not in Gentoo Ebuild Tree)
- mesa has a WIP implementation which works on some GPU devices.
- AMD provides its AMD APP SDK [1] which contains an OpenCL library.
- nVidia provides its CUDA toolkit [2] which contains an OpenCL library.
- Intel, on Linux, has an implementation for CPU devices, and another for GPU devices ("Beignet").
The implementations will be developed in further subsections.
ICD[edit | edit source]
The dev-libs/ocl-icd package provides a layer of indirection to enable different OpenCL implementations, and also provides the OpenCL.pc pkg-config descriptor.
Mesa (clover)[edit | edit source]
As of 2016, installing media-libs/mesa with the opencl
USE flag will get you an OpenCL 1.1 installation that works on almost all AMD GPUs. For a full list of features see the GalliumCompute Matrix.
Since media-libs/mesa-20.3 it supports OpenCL 1.2
Intel - CPU[edit | edit source]
The Intel CPU SDK is provided by the dev-util/intel-ocl-sdk which is in portage.
Intel - GPU[edit | edit source]
Intel Neo[edit | edit source]
Beginning with the Broadwell processor series, Intel Graphics Compute Runtime for OpenCL is provided by dev-libs/intel-neo.
Install it manually as the virtual/opencl note suggests (64-bit only):
root #
emerge --ask dev-libs/intel-neo
AMD[edit | edit source]
The newest OpenCL implementation from AMD is ROCm, Radeon Open Compute, which supports GFX8 and newer GPU chips (Fiji, Polaris, Vega). The GFX7 chips are enabled, but not officially supported. For older chips, use either the Mesa clover (above), or amdgpu-pro-opencl (below) implementations. The ROCm source is available on github, at RadeonOpenCompute/ROCm. ROCm is in Gentoo; install dev-libs/rocm-opencl-runtime. For an error-free operation, it may be necessary to recompile media-libs/mesa with the -opencl
USE flag, and to keep the default -nonfree
USE flag for dev-libs/rocr-runtime.
For ROCm to work properly with the AMDGPU drivers, the following kernel options must be set:
Memory Management options ---> [*] Allow for memory hot-add [*] Allow for memory hot remove [*] Device memory (pmem, HMM, etc...) hotplug support Device Drivers ---> Graphics support ---> <M/*> AMD GPU [*] Always enable userptr write support
The old driver is provided by the dev-util/amdapp package, which is maintained in the Science overlay.
There also exists dev-libs/amdgpu-pro-opencl -package which provides closed source OpenCL libraries from Ubuntu AMDGPU-PRO driver package. These libraries are normally used with the closed source AMDGPU-PRO drivers, but this package helps users to try if they can use them with open source AMDGPU drivers.
Mixing closed source OpenCL libraries with open source drivers isn't offically supported in any way. However there have been success at some levels[1][2]. Users who encounter problems are encouraged to ask help from the forums and not report it as a bug.
nVidia[edit | edit source]
The driver is provided by the dev-util/nvidia-cuda-toolkit package which is in the main ebuild repository.
Usage notes[edit | edit source]
Displaying info about OpenCL[edit | edit source]
You can see information about the system's OpenCL capabilities using dev-util/clinfo.
Implementation validation[edit | edit source]
An implementation (especially the experimental ones) can be checked by running test suites such as:
- piglit: Open Source OpenGL/OpenCL test suite. Check GalliumCompute for simple piglit tests
Implementation tuning[edit | edit source]
The main vendors will provide some form of advanced documentation to use their hardware to the maximum:
- nVidia: For developers targetting nVidia hardware, nVidia provides a Best Practices Guide.
- AMD: For developers targetting AMD hardware, AMD provides an Optimization Guide.
Some characteristics are not straightforward to find, and benchmarks are one way to find out.
TODO detail
LLVM DLL hell[edit | edit source]
LLVM is starting to become a central library, and it is used by most of the implementations. If the user/implementer is not careful, linkage issues can occur (symbol collisions, constructors getting called multiple times and not handled, etc.). This is something that can be noticed with many implementations also.
TODO example
- ↑ AMDGPU and OpenCL - Reddit
- ↑ Post 8087132 - Gentoo Forums