OpenCL SPIR 1.2: An Intermediate Format For OpenCL

Moving on from OpenGL, the rest of Khronos’ major news for SIGGRAPH revolves around their OpenCL standard for GPGPU compute. OpenCL was first released in 2008, and has since then been iterated on in conjunction with further software developments and the release of newer, more capable hardware. Khronos in turn is announcing two new OpenCL standards, OpenCL SPIR 1.2 and OpenCL 2.0.

Starting off with OpenCL SPIR 1.2, SPIR is an extension of OpenCL designed around filling in some of the software deployment holes the standard OpenCL software stack exposes. Standing for Standard Portable Intermediate Representation, SPIR is the format and specifications needed to represent OpenCL programs in an intermediate format, between high level C kernels and low level fully compiled binaries.

SPIR seeks to solve one of the outstanding issues with deploying OpenCL programs, which relates to OpenCL’s Just-In-Time (JIT) compilation nature. By default OpenCL programs can be shipped in one of two forms, either as a low-level binary compiled to specific devices, or in a high level form with the original high level C code being compiled all the way down to binary form at runtime; the botton and top of the compilation stack respectively. Importantly, with OpenCL core there is nothing in between, leaving the only options being to expose the original code or put together binaries for each and every device family. To use a Java analogy, OpenCL core lacks the equivalent of an intermediate format like a class file, and this is what SPIR is intended to solve.

SPIR solves this by defining a standard intermediate representation for OpenCL code, along with creating the frontends and backends necessary to support SPIR. With the appropriate systems in place, software vendors would then be able to ship OpenCL programs and kernels compiled down to the SPIR format, with device drivers then consuming the SPIR code and compiling the programs to their final device specific formats.

Ultimately SPIR is primarily being driven by the needs of software vendors, whose needs are expanding as OpenCL stabilizes and matures, and the number of capable devices increases. The exposure of high level code in fully portable (and forward-compatible) programs was not a problem in the early days of OpenCL, but as additional developers come on board and OpenCL programs move from complexity levels similar to OpenGL shaders (simple) to full blown applications (complex) there’s a need to protect code from trivial reverse engineering and source code theft. Though by no means perfect, compiling code to lower levels – be it intermediate or low level – prevents trivial reverse engineering and provides a reasonable level of protection for code. And since the OpenCL JIT model means that low level binaries are not portable to other devices, there is a clear need for an intermediate format that provides similar protection while maintaining portability.

On a technical level, it should come as no great surprise that SPIR will be borrowing heavily from the tag-team duo of LLVM and Clang. LLVM is a widely popular compiler backend, used in both CPU and GPU environments alike. Meanwhile Clang is the C language compiler frontend for LLVM. By going this route Khronos is able to leverage the strengths of LLVM, mainly LLVM’s wide portability and existing high quality intermediate representation format, not to mention the fact that many of the OpenCL vendors already use LLVM for their GPGPU compilers (particularly NVIDIA’s CUDA toolchain).

As an added bonus, much like NVIDIA and their use of LLVM for CUDA, by moving to LLVM Khronos gains the ability to quickly and efficiently add support for new high level languages to OpenCL. The separation of backend from the frontend means that Clang merely needs to be extended or replaced to add new languages, and as it stands Clang offers Khronos a very clear path towards enabling C++ in future versions of OpenCL, something that developers have been asking about for quite some time now.

Of course SPIR still needs to do some evolving of its own, along with OpenCL core itself. OpenCL SPIR 1.2 is being released as a provisional specification today, which in Khronos governance means that it’s a proposed specification that’s still open to comments and modification. Khronos’s goal here is to finalize SPIR in 6 months, assuming everything goes well, making this the first standardized version of SPIR. In turn, once OpenCL 2.0 is finalized, the SPIR working group can then begin work on SPIR for OpenCL 2.0.

Ultimately if Khronos plays their cards right, SPIR could drive the kick in adoption that OpenCL has been lacking thus far. The ability to protect programs by shipping intermediate code provides a benefit today, but by moving to LLVM and greatly simplifying the process of adding new languages it also gives OpenCL a new level of flexibility that will help OpenCL in the future.

OpenGL 4.4 Specification Released OpenCL 2.0: What's New
Comments Locked

28 Comments

View All Comments

  • ltcommanderdata - Monday, July 22, 2013 - link

    In DirectX 11.2 there's some thought that Tiled Resources tier 1 refers to Bindless Textures while tier 2 refers to Sparse Textures. So is there any hierarchy to these features where GPUs supporting sparse textures (GCN-based) should also support bindless textures (only Keplar officially announced)? Or are they independent?

    And is GK110 the only GPU currently available that supports Dynamic Parallelism and therefore the only currently shipping GPU that will be OpenCL 2.0 compatible? Hopefully Volcanic Islands and Maxwell will bring dynamic parallelism to the full product stack rather than just the top-end GPUs.
  • sontin - Monday, July 22, 2013 - link

    GK208 (Cuda 3.5) supports Dynamic Parallelism. And with next year i guess every GPU and Tegra 5 will support at leats Cuda 3.5.
  • TeXWiller - Monday, July 22, 2013 - link

    That may be Tesla/Quadro-exlusive offering anyway. It would be nice if Nvidia would bring back the "democratization of parallelism" from the times long gone.
  • sontin - Monday, July 22, 2013 - link

    GK208 is a consumer chip. It's not limited to the Quadro or Tesla series. They even advertised cards based on the chip on their blog:
    http://blogs.nvidia.com/blog/2013/06/06/hey-develo...
  • xdrol - Monday, July 22, 2013 - link

    The thing is, nVidia does not care about OpenCL, they could not even (ehm, rather, didn't want to) ship an OpenCL 1.2 driver at all.. So it's nice that the hardware supports the feature, if we cannot use it from OpenCL, that's no better than AMD's version.
  • name99 - Tuesday, July 23, 2013 - link

    You mean you won't be able to use OpenCL on Windows?

    I assume on OSX you'll be able to use OpenCL and it will continue to move forward --- unless nVidia thinks it would be a wise business move to ensure Apple never buys from them again.
  • MrSpadge - Saturday, July 27, 2013 - link

    No, by "not shipping OpenCL 1.2 drivers" he means they're still at 1.1. I don't expect this to be any better on OSX.
  • Ryan Smith - Monday, July 22, 2013 - link

    To the best of knowledge this is independent. At one point last year AMD said they didn't believe they could implement bindless textures in GCN hardware in an equivalent manner to NVIDIA. And NVIDIA of course may be bindless, but they can't do sparse in hardware. I fully expect the two to come together in the next generation of hardware, with NV and AMD gaining their competitor's respective functionality.
  • przemo_li - Thursday, July 25, 2013 - link

    Nvidia support both ARB_bindless_texture and ARB_sparse_texture in their drivers:
    http://www.geeks3d.com/20130722/nvidia-r326-29-bet...

    And "Tiers" and "feature levels" is MS speak for extensions and OpenGL versions. (Since clean DX9, DX10, DX11 do not work any more)

    Both of those did NOT landed in core. Those are extensions vendors may implement in hw if they like. (Though ARB stand there for a reason, and those extensions should land in core in unchanged form if hw support will be good)
  • chris81 - Monday, July 22, 2013 - link

    typo:
    Now with the competition of the new conformance tests -> completion

Log in

Don't have an account? Sign up now