OpenCL SPIR 2.0

At SIGGRAPH 2014 The Khronos Group announced, among other things, the SPIR 2.0 provisional specification. This release of SPIR (Standard Portable Intermediate Representation) follows the release of OpenCL 2.0 spec last year.

In this post, we would like to offer our take on SPIR 2.0 and what it means to OpenCL developers.

Feature Parity With OpenCL 2.0

SPIR 1.2 had feature parity with OpenCL 1.2. With 2.0, SPIR has feature parity with OpenCL 2.0. Here are a few new features that we find interesting.

Generic Address Space

“Where functions can be written without specifying a named address space for arguments, especially useful for those arguments that are declared to be a pointer to a type, eliminating the need for multiple functions to be written for each named address space used in an application.”

This greatly reduces code redundancy and increases code reusability. Many algorithms perform the same operations on __global memory and __local memory at various points in the algorithm. A great example of an algorithm that benefits from this is parallel reduction algorithm.

Device Side Kernel Enqueue

“Where device kernels can enqueue kernels to the same device with no host interaction, enabling flexible work scheduling paradigms and avoiding the need to transfer execution control and data between the device and host, often significantly offloading host processor bottlenecks.”

While this sounds like a nice feature to have, we are skeptical about the performance benefits. The improvements in performance will be highly dependent on the platform specific implementation of the scheduler and may not provide reliable improvements across the board. This feature can increase the readability of complex algorithms.

Pipes

“memory objects that store data organized as a FIFO. OpenCL 2.0 provides built-in functions for kernels to read from or write to a pipe, providing straightforward programming of pipe data structures that can be highly optimized by OpenCL implementers.”

Pipes are FIFO data structures that enable communication between two kernels being executed concurrently. This feature seems to be designed for architectures that support streaming data and will likely be inefficient on OpenCL capable GPUs.

SPIR Compiler and Tools

The Khronos group also added the SPIR compiler and SPIR Tools to their github page.

• Modified Clang which generates SPIR from OpenCL C kernel language device programs;
• SPIR module verifier, written in the form of an LLVM pass;
• SPIR built-ins name mangler, written as a standalone library and executable;
• header file containing definitions for all enumerated values in the SPIR specification.

The SPIR compiler is a patched version of clang that compiles OpenCL C code into SPIR. SPIR tools repository enables the usage of OpenCL builtin functions in SPIR. We’ll be exploring the SPIR compiler a lot more in a follow up post.

Future of SPIR

While it is encouraging to see continued development of SPIR, it is still an optional extension in OpenCL. AMD and Intel have supported SPIR since their OpenCL 1.2 implementations. NVIDIA has NVVM IR that may or may not be compatible with SPIR.

OpenCL brought the portability across different architectures. Similarily, SPIR will bring portability across multiple programming languages. All the vendors would be doing themselves and the ecosystem a favor if they support SPIR and implemented their compute language of choice on top of it.