4 ms·

The SPIR-V OpenCL profile is suitable, the Vulkan one is much less suitable. (you can’t even transpile OpenCL C 1.2 to it fully, with quite heavily limited poin

by my123 5y ago

The SPIR-V OpenCL profile is suitable, the Vulkan one is much less suitable. (you can’t even transpile OpenCL C 1.2 to it fully, with quite heavily limited pointers…) Metal has the best GPGPU story of the graphics APIs, with D3D12 coming second after that. Both at least can have OpenCL C transpiled without catches to them… Microsoft is writing CLon12 on that front: https://github.com/microsoft/OpenCLOn12 https://github.com/microsoft/OpenCLOn12

raphlinus 5y ago
> (you can’t even transpile OpenCL C 1.2 to it fully, with quite heavily limited pointers…) Is that still true as of Vulkan 1.3? We have buffer device address now, which I think counts as a real pointer. > Metal has the best GPGPU story of the graphics APIs I wish I could agree wholeheartedly with this. Yes, it's wonderful in many ways, but the lack of device-scope barriers means an entire class of advanced coordination patterns is unavailable. Of course, you're talking about transpiling OpenCL C 1.2, which I consider incredibly primitive and limited compared to modern compute shaders: no subgroups, no device-scope barriers, no 16 bit float.
- my123 5y ago
  > Is that still true as of Vulkan 1.3? In practice every GPU vendor that mattered already implemented it to 1.2, not much of a change on that front. The core problem, that pointers are an abstract type with no known compile-time size remains. > but the lack of device-scope barriers means an entire class of advanced coordination patterns is unavailable. (And OpenCL on Apple Silicon seems to have the opposite problem, stuff being promoted to device wide barriers when it should not be…)
shmerl 5y ago
That still sounds like not a good situation, if the only option if C-like expressiveness level I suppose. Can something like Rust level of expressiveness be compiled into OpenCL profile SPIR-V? Basically I'm talking about the higher level language, not about just IR being able to express compute use cases. Metal, D3D and CUDA are all dead ends becasue neither of them is really free of some kind of lock-in.

by my123 5y ago

raphlinus 5y ago

> (you can’t even transpile OpenCL C 1.2 to it fully, with quite heavily limited pointers…) Is that still true as of Vulkan 1.3? We have buffer device address now, which I think counts as a real pointer. > Metal has the best GPGPU story of the graphics APIs I wish I could agree wholeheartedly with this. Yes, it's wonderful in many ways, but the lack of device-scope barriers means an entire class of advanced coordination patterns is unavailable. Of course, you're talking about transpiling OpenCL C 1.2, which I consider incredibly primitive and limited compared to modern compute shaders: no subgroups, no device-scope barriers, no 16 bit float.

my123 5y ago
> Is that still true as of Vulkan 1.3? In practice every GPU vendor that mattered already implemented it to 1.2, not much of a change on that front. The core problem, that pointers are an abstract type with no known compile-time size remains. > but the lack of device-scope barriers means an entire class of advanced coordination patterns is unavailable. (And OpenCL on Apple Silicon seems to have the opposite problem, stuff being promoted to device wide barriers when it should not be…)

shmerl 5y ago

That still sounds like not a good situation, if the only option if C-like expressiveness level I suppose. Can something like Rust level of expressiveness be compiled into OpenCL profile SPIR-V? Basically I'm talking about the higher level language, not about just IR being able to express compute use cases. Metal, D3D and CUDA are all dead ends becasue neither of them is really free of some kind of lock-in.