<p>At SIGGRAPH 2014 The Khronos Group announced, among other things, <a href="https://www.khronos.org/news/press/khronos-releases-spir-2.0-provisional-specification">SPIR 2.0</a> provisional specification.
The release of SPIR 2.0 spec follows the release of <a href="https://www.khronos.org/news/press/khronos-releases-opencl-2.0">OpenCL 2.0</a> spec last year.</p>

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

<h3>Feature Parity With OpenCL 2.0</h3>

<p>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.</p>

<h5>Generic Address Space</h5>

<blockquote>
  <p>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</p>
</blockquote>

<p>This greatly reduces code redundancy and increases code reusability. Many algorithms perform the same operations on  <code>__global</code> memory and <code>__local</code> memory at various points in the algorithm. A good example an algorithm that would benefit from this would be the parallel reduction algorithm.</p>

<h5>Device Side Kernel Enqueue</h5>

<blockquote>
  <p>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</p>
</blockquote>

<p>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.</p>

<h5>Pipes</h5>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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.</p>

<h3>SPIR Compiler and Tools</h3>

<p>The Khronos group has also added <a href="https://github.com/KhronosGroup/SPIR">SPIR compiler</a> and <a href="https://github.com/KhronosGroup/SPIR-Tools">SPIR Tools</a> to their github page.</p>

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

<p>The SPIR compiler is a patched version of <code>clang</code> that compiles <code>OpenCL C</code> code into <code>SPIR</code>. <code>SPIR tools</code> 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.</p>

<h3>Future of SPIR</h3>

<p>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.</p>

<p>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.</p>