One issue is that the Vulkan API is absurdly low-level and verbose. There are good reasons for this if you're writing a game engine, but if you just want to run simple compute kernel you're looking at ~500 LoC, probably an order of magnitude more than with OpenCL. So the barrier to entry is really high.
It also seems the Vulkan supports a different variant of SPIR-V than OpenCL, with the result that some OpenCL C code can't be compiled to work with Vulkan. [1]
But it does seem like a combination of lifting Vulkan compute restrictions and building compute-oriented APIs on top of it could be a better path forward. Especially since this new version basically seems to be giving up an getting vendors to support the features that would make OpenCL competitive with CUDA.
It also seems the Vulkan supports a different variant of SPIR-V than OpenCL, with the result that some OpenCL C code can't be compiled to work with Vulkan. [1]
But it does seem like a combination of lifting Vulkan compute restrictions and building compute-oriented APIs on top of it could be a better path forward. Especially since this new version basically seems to be giving up an getting vendors to support the features that would make OpenCL competitive with CUDA.
[1] https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu...