Comment by fc417fc802
14 hours ago
This appears to be single source which would make it similar to SYCL.
Given that it can target WGPU I'm really wondering why OpenCL isn't included as a backend. One of my biggest complaints about GPGPU stuff is that so many of the solutions are GPU only, and often only target the vendor compute APIs (CUDA, ROCm) which have much narrower ecosystem support (versus an older core vulkan profile for example).
It's desirable to be able to target CPU for compatibility, debugging, and also because it can be nice to have a single solution for parallelizing all your data heavy work. The latter reduces mental overhead and permits more code reuse.
There's infrastructure in the SPIR-V compiler to be able to target both OpenCL and Vulkan, but we don't currently use it because OpenCL would require a new runtime, while Vulkan can simply use the existing wgpu runtime and pass raw SPIR-V shaders.
One thing I've never investigated is how performance OpenCL actually is for CPU. Do you happen to have any resources comparing it to a more native CPU implementation?
Sorry my interest there is debugging and I'm not immediately coming across good benchmarks. PoCL [0] seems to have added a TBB backend [1] so I'd expect it to be reasonable (otherwise why bother) but I haven't tested it.
It isn't really related to your question but I think the FluidX3D benchmarks [2] illustrate that OpenCL is at least viable across a wide variety of hardware.
As far as targeting CPUs in a release build it's not a particular backend that's important to me. The issue is at the source code level. Having single source is nice but you're still stuck with these two very different approaches. It means that the code is still clearly segmented and thus retargeting any given task (at least nontrivial ones) involves rewriting it to at least some extent.
Contrast that with a model like OpenMP where the difference between CPU and GPU is marking the relevant segment for offload. Granted that you'll often need to change algorithms when switching to achieve reasonable performance but it's still a really nice quality of life feature not to have to juggle more paradigms and libraries.
[0] https://github.com/pocl/pocl
[1] https://portablecl.org/docs/html/drivers.html
[2] https://github.com/ProjectPhysX/FluidX3D
Who would use the OpenCL backend rather than the others targets provided ?
Makes sense. And indeed, having OpenCL as a backend would be a very interesting extension.