OpenCL-Over-Vulkan Could Be Here Soon

[phoronix]

Phoronix: OpenCL-Over-Vulkan Could Be Here Soon

Khronos members have been working on code that could allow OpenCL code to be converted for execution by Vulkan drivers...

http://www.phoronix.com/scan.php?pag...er-Vulkan-Soon

[abergmeier]

It will be interesting to see what all this entails and its capabilities -- e.g. if it will have full OpenCL 2.1+ support, etc.

AFAI talked with Kronos members - no it won't. The reason is mostly that OpenCL is NOT a low-level API. Vulkan is strictly a low-level API and will be kept that way.
As such, yes the memory model and bindings of OpenCL kernels might be supported soon, as it is to a degree low-hanging fruit. Topics like pointer support, etc. might be harder to crack.
On the long run support for all of OpenCL/SYCL might happen but this would then be a layer on top of Vulkan and will take years until compliance.

[karolherbst]

I am wondering how this can be used in multi device scenarios with different types of OpenCL devices, which may also use different backend drivers. With OpenCL you can do the same work on the CPU and GPU in parallel.

[boxie]

being that AMD has put a lot of work into ROCm, I am not sure this would be directly a comparable implementation.

[illwieckz]

Intel's Beignet OpenCL supports OpenCL 2.0 but isn't shipped by default on many distributions.

…and is broken (both Darktable and LuxMark can't run with it), POCL has the same issue : long list of feature implemented, not usable on real scenario.

[Veerappan]

One downside to ROCm: It only works if you've got PCIe 3.0 atomics. This limits to some intel chips (haswell+) and Ryzen, and only if you're using Fiji/Polaris hardware.

Anyone running an older GPU or CPU is left out in the cold.

Even though I've upgraded my main home system to a Ryzen 1700, my GPU is still a Radeon 7850, so I either have to choose the binary driver, or keep working on Clover until I upgrade to Polaris/Vega later this year. My secondary system is still a Phenom II with a radeon 6850, which will never support ROCm.

With the CL CTS having been recently open-sourced, it's getting a lot easier to make fixes to both clover and libclc... While not everything is working correctly yet, progress may end up happening faster than it was before. Image support still hasn't been implemented yet for radeons, but a lot of the other core features are done. People have a tendency to forget that image support is an optional feature in OpenCL. While it's required for some programs/benchmarks, it's not actually a required feature of the language spec.

[quaz0r]

Radeon's Clover OpenCL driver is unmaintained and only supports OpenCL ~1.1

hey that sounds familiar *cough* nvidia

[darkbasic]

What about glamor over vulkan?

[aufkrawall]

hey that sounds familiar *cough* nvidia

Nvidia supports 1.2 (and surprisingly, [email protected] runs totally reliably here with it).

[illwieckz]

Image support still hasn't been implemented yet for radeons, but a lot of the other core features are done. People have a tendency to forget that image support is an optional feature in OpenCL. While it's required for some programs/benchmarks, it's not actually a required feature of the language spec.

That's what I wrote about Beignet and POCL : “long list of feature implemented, not usable on real scenario”.

It's written in the newspost “ROCm stack supports OpenCL 1.2 but with OpenCL 2.0 runtime support” (it's the same for amdgpu-pro) but I read in this forum some AMD guys saying that AMD focus first on real-life required features, full support of required features of the language spec will come later. Some other people focus on required features of the language spec, then required features of real-life usage. Hopefully I'm able to use Darktable with AMD stack since years, I'm just waiting to get everything mainlined and every feature implemented to be proud of them, but eh, it already works so they already deserve some proud.