I wouldn't expect being able to load a D3D12 SPIRV blob into Vulkan or OpenGL anyway though, just because the 'input semantics' are very different (and I think that's also the main difference between GL and Vulkan SPIRV blobs). But AFAIK SPIRV is extensible for this type of differences without rendering existing SPIRV tools completely useless.
I think you’re kind of missing what I was getting at: today, tools which produce SPIR-V for OpenCL cannot be used to produce SPIR-V for Vulkan shaders, and vice versa. MLIR is a possible way out of the mess, but I am not hopeful that the future looks less messy, at least for some years, and it may not have enough incentive to even be feasible to improve.
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.
