<a title="theregister" href="http://www.theregister.co.uk/2014/08/11/khronos_unveils_opengl_4_5_and_spir_2/">Many</a>, <a title="phoronix" href="http://www.phoronix.com/scan.php?page=news_item&amp;px=MTc1OTk">outlets</a> are carrying the news that the Khronos group released the provisional SPIR 2.0 spec for OpenCL this Monday. This is exciting news, but what does the new spec mean for all the current (and potential) OpenCL users out there?

The Khronos website lists the following interesting aspects of the new spec:
<ul style="color: #222222;">
	<li>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;</li>
	<li>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;</li>
	<li>C++11 atomics – a subset of C11 atomics and synchronization operations to enable assignments in one work-item to be visible to other work-items in a work-group, across work-groups executing on a device or for sharing data between the OpenCL device and host;</li>
	<li>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.</li>
</ul>
@pavan, @umar do you have experience with these? Does Shehzan have good experience? A good post might be to give a good example of each of these with motivation.

&nbsp;

The first commentator on the Khronos thread posts his observations,
<ul>
	<li>SPIR is now based on LLVM 3.4 IR (previously it was 3.2)</li>
	<li>Memory ordering &amp; scope has been added (fences which control where memory changes are visible, needed for SVM)</li>
	<li>Support for device-kernel-enqueing by providing blocks (%opencl.block) and ndrange_t types. The ndrange_t definition is trivial and just as expected. Make sure to look at how blocks are represented/implemented, this is partially implementation-defined with quite a bit of "high-level" built-ins to kick-off a block. This is a large addition, and there is a bunch of built-ins to support blocks.</li>
	<li>Loop unrolling metadata. While alone it's not too interesting, there's now a clean way how such hints can be passed from the front-end into SPIR.</li>
	<li>Pipes. I'm not quite sure I follow the documentation, but on the SPIR level, pipe read/writes are modelled as function calls to a (runtime provided?) function. I thought there would be a generic built-in instead. I assume the fact that the provided function contains the whole type will allow vendors to optimize the writes, but it still seams a bit weird to me (why not read/write_pipe with a metadata block describing the struct layout, if any?)</li>
</ul>
&nbsp;

Again, it would be great to do something as far as examples, here