Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V
With today's OpenCL 2.1 provisional specification, there's a new OpenCL C++ kernel language based on a subset of C++14 that is designed to make it simpler and more powerful for parallel programming. OpenCL C will still be supported to preserve existing kernels. Removed from OpenCL C++ are features like allocation and releasing of memory, virtual functions, abstract virtual classes, function pointers, goto, and other changes that don't work too well in a parallel computing environment. OpenCL 2.1 also adds a clCloneKernel option to enable copying of kernel objects and states, new low-latency device timer queries, clCreateProgramWithIL to ingest SPIR-V code at runtime, zero-size enqueue support, and other changes.
While supporting Vulkan will be a greater burden for Mesa/Gallium3D driver developers given they haven't even reached official OpenGL 4.0 support yet, Vulkan drivers will be simpler than OpenGL drivers. The simpler drivers should lead to better cross-vendor portability, lower-overhead, etc. The switch to SPIR-V as the intermediate language should hopefully be a big win. If the SPIR-V to LLVM IR pass materializes, it may open up big possibilities for existing GPU-based LLVM back-ends like the AMDGPU driver used by the RadeonSI Gallium3D driver and there's also NVIDIA's NVPTX back-end (though not used by Nouveau and NVPTX is just NVIDIA's IR consumed by their binary blob).
If SPIR-V is able to fully represent OpenCL and Vulkan programs, it will be interesting if much of this code can then be translated into LLVM IR and consumed by these GPU LLVM back-ends, etc, without as much work as happens now for supporting new versions of OpenGL within Mesa. The open-source (and closed-source) drivers consuming SPIR-V should make it much easier to support new features and be more easily maintained. It will also be interesting to see if Intel finally picks up an LLVM back-end for their open-source graphics driver, which has been a matter they've talked about many times over the years but never fully realized due to various gripes over LLVM and its relatively high cost to entry. Likewise, with the new APIs, maybe Intel will finally shift to Gallium3D assuming the new interface will be easy to implement as just a Gallium3D state tracker.