Ah right, I was thinking of the Vulkan vs GL SPIRV flavours.
I don't think it's much of a problem though. I cannot run a WASM blob compiled for the web in a WASI runtime either, or an x86 executable compiled for Windows on Linux. Heck, I can't even run an executable compiled for one Linux distro on another Linux distro if the glibc library versions don't overlap.
I guess the main reason is that entirely different people work on using GPUs for compute tasks versus using GPUs for rendering tasks (unless you're using the 3D API's compute features). E.g. not a technical problem, but organizational.
Yes. The ecosystem is the problem, and it’s a chicken/egg or network-effect problem. There’s no reason we can’t use the same source and compiler to target both Vulkan shaders and OpenCL kernels and now DX12 shaders, but in practice the fact that these all supposedly use the same standard IR doesn’t actually get us the promised utility of implementing that standard, because in practice they do use different variations of the standard.
Therefore this news is less than useless unless it does something to defeat this problem.
I think the main reason why DX switches to SPIRV is that it saves the DX team a lot of work. They can drop dxc which is based on a very old LLVM fork, and replace the DXIL "hack" (which is just LLVM-IR with some things bolted on) with a properly specified bytecode.
I don't think it's much of a problem though. I cannot run a WASM blob compiled for the web in a WASI runtime either, or an x86 executable compiled for Windows on Linux. Heck, I can't even run an executable compiled for one Linux distro on another Linux distro if the glibc library versions don't overlap.