> the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there.
I don't think it's hard to understand. Apple wanted an easy to use API that could be extended and updated easily. Vulkan is an extremely complex API that foregoes all and any developer ergonomy to facilitate quick driver development on as many hardware targets as possible. Consequently, Vulkan's design choices are driven by the least common denominator. The goals are just too different.
There is at least some evidence that Apple was interested in supporting and shaping Vulkan (they were member of the initial working group), but I suspect that it very quickly became clear that the committee is going into a direction they were not interested in, so they noted out.
Still, I don't think it's correct that Apple is opposing any kind of standardisation in this domain, they just want something more aligned with their vision. They have been very active with WebGPU, which is shaping up to be a very nice API, and it has inherited a lot of good design decisions from Metal.
Indeed Apple has been very active in shaping WebGPU, and that is why we can't use a bytecode representation for shaders. Instead, we have to repeat OpenGL's mistakes and store shaders as strings.
WebGPU specifically has to be the lowest common denominator among the APIs it supports. And there are several features very useful in GPGPU's which are supported in Vulkan and CUDA, but cannot be included in WebGPU due to the lack of Metal support. One such example is floating point atomics.
I am sure that bytecode representation of shaders will come in a future revision. It’s not a first priority. SPIR-V is a poor choice for portable shaders for reasons outlined by the WebGPU group on multiple occasions. And WebGPU shading language finally goes away with some poor legacy design choices that are still stuck in GLSL and HLSL (such as shader bindings via global variables).
Regarding floating point atomics, I think you got it confused? Metal fully supports floating atomics on all recent devices, while in Vulkan it’s an optional extension. According to gpuinfo database only 30% of implementations support float atomics, and only 10% support more advanced operations like min/max. If you are looking for cross-platform float atomics support, Apple is the least of your worries (what they suck at are 64-bit int atomics though).
I don't think it's hard to understand. Apple wanted an easy to use API that could be extended and updated easily. Vulkan is an extremely complex API that foregoes all and any developer ergonomy to facilitate quick driver development on as many hardware targets as possible. Consequently, Vulkan's design choices are driven by the least common denominator. The goals are just too different.
There is at least some evidence that Apple was interested in supporting and shaping Vulkan (they were member of the initial working group), but I suspect that it very quickly became clear that the committee is going into a direction they were not interested in, so they noted out.
Still, I don't think it's correct that Apple is opposing any kind of standardisation in this domain, they just want something more aligned with their vision. They have been very active with WebGPU, which is shaping up to be a very nice API, and it has inherited a lot of good design decisions from Metal.