That may sounds silly but I think we should try to implement vulkan as a replacement for OpenCL first, as it just run a dispatch for a specific work instead of a whole render pipeline architecture like eevee. It could be much easier to implement and much of the bulk integration work would be done and the compute shader pipeline it a fair bit easier to put in place (no raster config, no IA, simpler command buffer etc…).
It’s not unheard of, there is some project to make OpenCL converge with Vulkan with some plan to make interoperability between both. (I also found some people saying there is perf gain to that but I’m not convinced: https://community.khronos.org/t/opencl-vs-vulkan-compute/7132/2 )
Additionally if we end-up having a single API that run both Compute stuff and rendering it could be quite awesome in term of both programming and end-user (as there is no additional stuff to enable or install as with openCL: no CUDA, OpenCL choosing between, we can just have to test the availability of the ComputeQueue Family and display “GPU” in the cycles dropdown accordingly.
And last but not the least: if we choose to enable moltenVK en macos it could bring back a proper GPU compute on Mac (openCL being broken and deprecated)
Doing this feel like a win-win while being a smoother starting point. If anyone agree I may try to mirror OpenCL implementation this weekend and see what happen.
Edit: additional point: we could even go as far as merging some compositor effect to be able to run as compute shader (and async compute) in the eevee pipeline with some performance vs quality settings (so you could choose to have a bokeh DOF of a few ms in cycle or about a second in eevee if you want to) and bridge gab between eevee and cycle even more.