Khronos Ships New OpenCL SDK Upgrades!
The release of the OpenCL™ 3.0 specification was a significant milestone for this open standard for low-level heterogeneous parallel programming, creating a pervasive baseline that can be cleanly extended with new functionality requested by developers. But a strong open standard ecosystem is much more than just an API document and Khronos is making significant investments to improve the OpenCL developer experience. Read on to discover the latest updates to the OpenCL SDK and what is coming on the SDK roadmap!
The Khronos OpenCL SDK
The initial version of the open source Khronos OpenCL SDK was released on GitHub together with OpenCL 3.0. The SDK aims to be a "one-stop-shop" for easily getting started with the most important components to productively develop OpenCL applications and libraries. This Khronos cross-vendor SDK complements the SDKs supplied by hardware vendors that tailor tooling and samples for their customers.
The OpenCL SDK encompasses a number of repositories that comprise a productive OpenCL development environment such as OpenCL-Headers, OpenCL-ICD-Loader and OpenCL-CLHPP. If you are used to having to assemble OpenCL development packages from scratch, we suggest trying the new OpenCL SDK for a more streamlined experience!
Build or Binary
The new OpenCL SDK has a significantly enhanced build system, including using CMake to support consuming existing projects as top-level builds as well as subprojects - see more details on how the SDK uses CMake below.
For developers who prefer a manual installation experience, or want to use automation to consume the SDK without building it, we’ve added binary releases of tagged versions to the SDK’s GitHub release page.
Getting Started with the OpenCL Guide
The GitHub-hosted OpenCL-Guide provides documentation for many aspects of developing with OpenCL and using the OpenCL SDK. New topics added to the Guide include:
- Getting started on Windows
- Getting started on Linux
- CMake build system support
- Offline/Online compilation
You are invited to file issues on the Guide repo if there are topics that you would like to see added.
The OpenCL SDK includes a set of C, C++, Python and Ruby samples, including new native samples that demonstrate how OpenCL 3.0 specific features can be used with backwards compatibility - even on OpenCL 1.x and 2.x runtimes. New samples demonstrating OpenCL-OpenGL interop depend on SFML, a windowing library which is supported on all SDK target platforms.
The out-of-the-box experience for those wishing to build new samples has also improved. The new C and C++ samples native samples uniformly depend on the unexported libOpenCLSDK or libOpenCLSDKCpp respectively. This makes it easier to define command-line options which may be unique to a particular sample.
The handful of dependencies needed to build samples may be installed via your system's package manager or via a C/C++ package manager such as Conan, Vcpkg, Spack, or Hunter. Sample dependencies can also be auto-fetched via SDK build scripts which can be useful for developers not using package managers and don't self-host their dependencies. Be aware that auto-fetching dependencies comes at the cost of configuration time, so for some, it may still be worthwhile obtaining them directly.
New Utility Libraries
There are tasks which are common to many OpenCL programs and developers tend to develop their own utility libraries. The OpenGL ecosystem developed common utility libraries such as GLUT and GLM that are widely used, and the new OpenCL Utility Libraries aim to serve a similar role, streamlining tasks such as robustly loading kernel source and binary files, converting profiling info to
Two utility libraries are now installed alongside the SDK. These are C++ utilities which don't strictly relate to the API and therefore don't really belong in OpenCL-CLHPP, the canonical C++ wrapper to OpenCL, but may be of interest to a wider audience:
- libOpenCLUtils implemented in ISO C
- libOpenCLUtilsCpp implemented in ISO C++
The latter also contains some templated utilities, which cannot be written as C utilities wrapped in C++. Documentation on these new libraries can be found in the SDK repository.
If you have created additional helper libraries, you are warmly invited to open a pull request on the OpenCL SDK repo and share them, so others may benefit from your work.
CMake's OpenCL:: namespace
OpenCL enjoys increasing levels of CMake support including a Find Module (FindOpenCL.cmake) that is a turn-key solution to take some of the guesswork out of detecting SDK development files when there isn’t direct upstream CMake support.
But to improve the user experience when building and consuming the OpenCL-SDK, all downstream repos (OpenCL-Headers, OpenCL-CLHPP, and OpenCL-ICD-Loader) now install robust Package Config files for the precise detection of all SDK components. Did we say components? Yes we did!
Existing Find Module scripts aren’t component-aware, hence using
find_package(OpenCL) resulted in some SDKs not including cl.hpp, later cl2.hpp - and the current opencl.hpp canonical C++ wrapper. Even if the OpenCL package was found, the presence/absence of the C++ wrapper still had to be handled.
But now, when components are installed by the OpenCL SDK rather than installed in isolation, it is now possible to properly detect all components individually:
find_package(OpenCL COMPONENTS Headers HeadersCpp OpenCL # ICD-Loader, depends on Headers Utils UtilsCpp )
These enhancements are backward compatible manner, so that the existing:
find_package(OpenCL REQUIRED) target_link_libraries(MyApp PRIVATE OpenCL::OpenCL)
continues to work regardless of
find_package() operating in Module or Config mode.
For more information on CMake support, refer to the associated chapter of the OpenCL-Guide.
Looking forward, the OpenCL Working Group at Khronos plans to contribute to Kitware’s upstream FindOpenCL.cmake, ensuring the new OpenCL:: namespace and its component support become increasingly reliable and comprehensive over time.
Package managers have been steadily gaining traction for C/C++ with varying degrees of support for installing OpenCL development files. Khronos will notify and assist package maintainers to build from the OpenCL SDK to both reduce maintenance costs and improve feature coherence across the OpenCL ecosystem.
The OpenCL Working Group has also begun to assist distribution maintainers package newer versions of OpenCL-related packages, as well as providing easy installation methods that integrate well with various operating systems, including using PPAs, for those that wish to use newer OpenCL builds than what their OS distribution provides as default.
We would love to hear your feedback on how the OpenCL SDK works for you. If you find any issues, or identify features and samples that you would like to see added, we encourage you to open an issue, or even pull requests, to help us evolve the SDK to best meet the needs of the OpenCL developer community. Give it a try and let us know what you think!