Now that SYCL is becoming more widely supported i took some time and ported our project that is currently based on CUDA to SYCL/OneApi. I wanted to use pointers on device side, so i used the SVM extension from OneApi instead of plain SYCL.
I have to admit that SYCL is really a great step forward for the whole industry, since finally there is an open standard that allows to do heterogeneous programming in a clean way that is based on modern C++. I could never really understand why Khronos put so long the focus on C instead of C++, which was in my opinion one of the main reasons why CUDA has become so strong in the industry.
What directly came to my mind when working with SYCL was: This is exactly how i would like to write also my Compute Shaders in Vulkan. Since modern GPUs are able to run SYCL/CUDA/ROCM which are based on C++, there doesn’t seem to be a HW reason why this should not be possible. So the only reason seems to be that Khronos has decided not to allow this right now - and stay with C for Vulkan shaders.
In my opinion it seems to be a “no brainer” to allow SYCL like C++ support in Vulkan compute shaders.
From what i have understood it seems that the following two points are missing:
- Vulkan would need an extension that allows to support the compute SPIR-V model that SYCL/OPENCL internally uses.
- Vulkan would then have to be able to run SPIR-V created by a C++ frontend that compiles to SPIR-V.
It seems that CLSPV goes somewhat in that direction (but it seems to focus on C only). But having an open source project here does not seem to be reliable enough to create a large code base that in the long-term would depend on such a technology. In my opionion Khronos should enhance Vulkan so that C++ compute shaders - similar to how it is done with SYCL - can be used.
In my opinion this would be the most dramatic incentive for us to use Vulkan for large projects that combine compute + graphics that i could right now imagine.
A related question is if SYCL should be enhanced in some way to work with Vulkan so that resources like buffers and textures could be shared without overhead for those kind of projects that combine compute + graphics and which do want to benefit from all those great advancements that are going on in the C++ language.