4 ms·
Well, the current implementations are on top of existing APIs, e.g. https://github.com/illuhad/hipSYCL https://github.com/illuhad/hipSYCL so maybe everyone just
by floatboth 7y ago
Well, the current implementations are on top of existing APIs, e.g. https://github.com/illuhad/hipSYCL https://github.com/illuhad/hipSYCL so maybe everyone just keeps using these.
As an aside: why won't everyone migrate to Vulkan compute shaders? I hate these "special" compute stacks >_< Clearly I'm not alone in thinking this: Tencent's ncnn uses Vulkan as the only GPU option, some Googler is working on clspv (OpenCL to Vulkan SPIR-V compiler)..
- robert_foss 7y agoRight, Khronos intends for SYCL on GPUs to be backed by OpenCL. Vulkan compute and OpenCL are not entirely compatible (both are backed by SPIR-V (but different flavors of it.)) Khronos has chosen to maintain OpenCL (and OpenCL-next) separate from Vulkan.
- rrss 7y ago> why won't everyone migrate to Vulkan compute shaders? 1. No libraries. cudnn, cublas, cufft, are all the fastest available (except maybe magma sometimes), plus no one writing an actual application wants to reinvent a fast gemm. Also cutlass, cub, thrust, ... 2. No c++. The "standard" seems to be glsl, and a "prototype" opencl c -> spir-v compiler doesn't give me much confidence in that approach. 3. No one wants to use vulkan apis directly, and there are approximately 5 billion different "vulkan compute" wrapper utility libraries. i.e. No consistent platform.