If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Official OpenCL SPIR 2.0 Provisional Specification feedback thread

OpenCL SPIR 2.0 Provisional Specification
The Khronos™ Group today announced the ratification and public release of the SPIR™ 2.0 provisional specification that provides a non-source encoding, and binary level portability, for OpenCL™ 2.0 device programs. SPIR (Standard Portable Intermediate Representation) is the industry's first open, cross-platform Intermediate Representation standard for portable heterogeneous parallel computing and is based on LLVM IR. SPIR enables developers to avoid exposing sensitive kernel source and enables a diversity of language front-ends to easily target OpenCL platforms and devices in addition to OpenCL C.

OpenCL BOF at SIGGRAPH 2014
Attendees at the SIGGRAPH 2014 Conference in Vancouver are invited to the Khronos OpenCL BOF at 3-4PM on Wednesday 13th at the Marriott Pinnacle Hotel, next to the Vancouver Convention & Exhibition Centre to hear more details around developments in the OpenCL ecosystem. Space is limited and is available on a first-come first served basis.

For easy reviewing, is there a version with changes highlighted? I have the SPIR 1.2 and 2.0 documentation open side-by-side right now to see changes, but some smaller issues might be hard to spot. There's also no "what's new in SPIR 2.0" section (unlike for example in OpenGL and the OpenCL specs) which would be also helpful.

For any new readers, here are the main additions & changes:

SPIR is now based on LLVM 3.4 IR (previously it was 3.2)

Memory ordering & scope has been added (fences which control where memory changes are visible, needed for SVM)

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.

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.

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?)

What is meant to me in § 3.13? There's just a question mark there.

These are the major changes I've spotted on the first read. Looks like a pretty clean addition over SPIR 1.2. Blocks are quite a bit larger in IR than expected and require multiple steps of built-in machinery for setup. I wonder what the rationale is for the way pipes are handled, if someone could shed some light on this, I'd be curious to hear why it's not done using metadata.