Would you like to run CUDA-kernels on the OpenCL framework? Or Python or Rust? SPIR-V is the answer! Where source-to-source translations had several limitations, SPIR-V 1.1 even supports higher level languages like C++.

SPIRV is the strength of OpenCL and it will only get bigger.

Currently Intel drivers best support SPIR-V, making it the first target for the new SPIR-V frontends. It is unknown which vendor will be next – probably one which (almost) has OpenCL 2.0 drivers already, such as AMD, ARM, Qualcomm or even NVidia.

How interesting is sPIR-V Really?

So if SPIR-V is really that important a reason to choose for OpenCL, I thought of framing it towards CUDA-devs on twitter in a special way:

Should CUDA 9 support SPIR-V?

So that’s a big yes for SPIR-V support on CUDA. And why not? Don’t we want to program in our own language and not be forced to use C or C++? SPIR-V makes it possible to quickly add support in any language out there without official support of the vendor. Let wrappers handle the differences per vendor and let SPIR-V be the shared language for GPU-kernels. Where do we need OpenCL or CUDA for, if the real work is defined by SPIR-V?

What do you think? Leave your comment below how you see the future of GPGPU with SPIR-V in town. Is 2017 the year of SPIR-V?

And if you worked on a SPIR-V frontend, get in touch to continue your project on https://github.com/spirv. Yes, it’s empty right now, but you don’t know what’s hidden.