OpenCL via Vulkan

[BrickFarmer]

btw Congrats on the rapid inclussion of Vulkan in LWJGL!

So I'm looking at some NVidia graphics cards, and I cant find mention of OpenCL support.  Looking at OpenCL we are now at 2.1 and I see LWJGL already supports that!   I found something mentioning that NVidia only supports OpenCL 1.2, since they push CUDA hard.  So then I noticed Vulkan support in the latest NVidia drivers (that goes back to older cards as well).  But now I'm confused, it doesnt take much these days     OpenCL 2.1 seems to 'compile down' to SPIR-V which is then 'run' on Vulkan?  So isn't OpenCL2.1 support implicit if a driver supports Vulkan?  or would some kind of more complex tool chain be required?

ie.  I found something that converts from java .class bytecode to LLVM, and a tool that goes from LLVM to SPIR-V

The reason for my ramblings is that I was looking at a CPU based grid compute architecture, and started wondering how it could be replicated within GPU without using vendor specific options like CUDA.  For example the new Nvidia P100 or the crazy powerful Nvidia DGX-1. (and No, they are not on my shopping list!).  So I started to wonder how you could make use of such powerful GPUs as a grid compute platform via Java.  Although the NVLink seems like another proprietry trap in this solution.

Anyway I guess my main question is how usable is OpenCL 2.1 if the GPU manufacturers are no longer supporting it publicly?  and can it be somehow compiled down to Vulkan behind the scenes to keep development at a higher level?  Or would an intermediate binding to SPIR-V be an option?

[spasi]

It's not so simple, you cannot "compile" OpenCL code to Vulkan. The two APIs have very different designs and semantics.

If you're only interested in GPU compute, then I guess Vulkan would be a very powerful choice. I haven't seen an exhaustive comparison, but I can't think of anything you can do with OpenCL that you can't do equally well or better with Vulkan.

One advantage OpenCL has over OpenGL compute shaders or Vulkan compute pipelines is that OpenCL kernels may run on CPUs and APUs, in addition to GPUs. The biggest change in OpenCL 2.0 was the introduction of shared virtually memory, which among other things enables semantics that make compute on APUs very efficient.

But the OpenCL ecosystem is problematic. Only Intel and AMD support OpenCL 2.0 and no one supports 2.1 yet. Nvidia is focused on CUDA, although there's been rumors that they may release OpenCL 2 support this year. Apple, the creator of OpenCL, doesn't seem to care either; OS X is still on OpenCL 1.2.

[BrickFarmer]

Thanks for your insights.  I found that Vulkan also isnt on OSX yet, typical of Apple these days    Does Vulkan also have this concept of shared virtual memory then? seems like MappedMemory might do the trick, it was something I saw used quite a bit in the grid system I was looking at, although interconnect was very fast so there was also a lot of inter process communication used.  I went through the Vulkan API and it seems like a fresh clean design if not a little daunting for newbies!  btw Is LWJGL also supporting WIS? although I guess that is not needed with GLFW already supported.  Anyway thanks for the info, although having done some more reading it's quite sad to see how the industy is all pulling towards propriety solutions.  In fact I'm amazad Vulkan is being so widly adopted/supported.  There is still hope, keep up the good work

[spasi]

Does Vulkan also have this concept of shared virtual memory then?

No. Vulkan has memory heaps that are either device local or host local and all memory transfers must be explicitly synchronized to be made coherent.

seems like MappedMemory might do the trick, it was something I saw used quite a bit in the grid system I was looking at, although interconnect was very fast so there was also a lot of inter process communication used.

A Vulkan implementation may have dedicated transfer queues that can be used to perform asynchronous memory operations. With explicit dependencies and synchronization, this enables very efficient schemes, but obviously requires extra work from the programmer.

btw Is LWJGL also supporting WIS? although I guess that is not needed with GLFW already supported.

Yes. GLFW takes care of it internally, but you have access to WSI bindings if you want to do something custom.