OpenCL (the API) will merge into Vulkan, but OpenCL C/C++/DCompute/compute shaders (the kernel languages) will remain separate as they compile to SPIRV, which is compiled into the native binary format.
Can you explain this a bit more clearly? As I understood it, OpenCL's compute API will look like Vulkan's functions and nothing from Vulkan side will change (interpreting this from the fact that Vulkan group apparently won't be involved in this merge -- according to the interview)
How will everything possibly work? Is it just that OpenCL's API will change and the libraries for OpenCL will remain the same or will the library be merged into Vulkan too? I'm just confused since the programming models are so different.
AFAIU Vulkan will continue in the direction it is going.
I imagine that the OpenCL API will replace the directly comparable parts of the APIs (e.g. contexts queues images/buffers) so that OpenCL will use the Vulkan "definition". OpenCL kernels would go next to compute shaders in terms of the pipeline. There of course would be some additional things added to the combined API to support OpenCL specific things (like pipes).
But alas, I am no more privy to these things than you, and the above is pure speculation.
OP here. This is a small code example of how to use Vulkan for compute operations. Only ~400LOC. It's pretty short, and has plenty of comments, so it should be useful for people learning Vulkan, I hope.
Has someone created a wrapper or higher-level API that takes care of some of the details for common use-cases?
For example, say I don't need to optimize my command submittal, or I just want the main device. Or maybe my common use case is a compute shader just like the program submitted in this Hacker News post. I would want a class that just exposed a simple API like runComputeShader() or something.