ocl VS clspv

Please note that OpenCL consists of two parts: host API and a separate language which is used to write kernels (code which is going to be offloaded to devices). OpenCL specification describes host APIs as C-style APIs and that is what implementors has to provide. However, there are number of various libraries which provides bindings for other languages: - C++ - Python - Go - Rust

ocl

I don't know a lot about Rust, but this looks like a valid set of OpenCL bindings for Rust: https://github.com/cogciprocate/ocl

If you prefer an open alternative to CUDA, there are complete, easy to use und well documented bindings for opencl: https://github.com/cogciprocate/ocl/

- https://github.com/cogciprocate/ocl/issues/202

I use Rust with OpenCL (ocl). And I am still in college studying CS. It takes a while to setup OpenCL depending on what you want to do with it. But performance benefits are well worth it. On average I can backtest 4 years of data with 1 minute candles in about 8.745 ms for typical RSI indicator. This is done on i5-3320m CPU (not iGPU). Took me a year to build it. Was also learning rust with it. My project has many features so you probably can do it in half amount of time or even less. Currently the project has 21k in Rust and 2k lines in OpenCL.

See https://github.com/google/clspv for an OpenCL implementation on Vulkan Compute. There are plenty of quirks involved because the two standards use different varieties of SPIR-V ("kernels" vs. "shaders") and provide different guarantees (Vulkan Compute doesn't care much about numerical accuracy). The Mesa folks are also looking into this as part of their RustiCL (a modern OpenCL implementation) and Zink (implementing OpenGL and perhaps OpenCL itself on Vulkan) projects.

Vulkan Compute backends for numerical compute (as typified by both OpenCL and SYCL) are challenging, you can look at Google's cspv https://github.com/google/clspv project for the nitty gritty details. The lowest-effort path is actually via some combination of Rocm (for hardware that AMD bothers to support themselves) and the Mesa project's Rusticl backend (for everything else).

D3D12 has more compute features than Vulkan has. It works out for DXVK because games often don’t use those, but it’ll cause much more issues with CLon12.

By the way, if you are ready to have a _limited_ implementation without a full feature set because of Vulkan API limitations, clvk is a thing. The list of limitations of that approach is at https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu...

tldr: Vulkan and OpenCL SPIR-V dialects are different, and the former has significant limitations affecting this use case

For OpenCL on DX12, the test suite doesn't pass yet. Every Khronos OpenCL 1.2 CTS test passes on at least one hardware driver, but there's none that pass them all. That is why CLon12 isn't submitted to Khronos's compliant products list yet.

The pointer semantics that Vulkan has aren't very amenable to implementing a compliant OpenCL implementation on top of. There are also some other limitatons: https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu....

Vulkan is much more limited, notably because of Vulkan's SPIR-V dialect limitations. That makes a compliant OpenCL 1.2 impl on top of Vulkan impossible. (see: https://github.com/google/clspv/blob/master/docs/OpenCLCOnVulkan.md)

OpenCL really is your best bet for a cross-platform GPU-capable framework. OpenCL 3.0 cleared out a lot of the cruft from OpenCL 2.x so it's seeing a lot more adoption. The most cross-platform solution is still OpenCL 1.2, largely for MacOS, but OpenCL 3.0 is becoming more and more common for Windows and Linux and multiple devices. Even on platforms without native OpenCL support there are compatibility layers that implement OpenCL on top of DirectX (OpenCLOn12) or Vulkan (clvk and clspv).