SPIR-V only exists to reaction of Khronos losing to CUDA and PTX, it is the evolution of SPIR, created when they realised industry didn't really want to write OpenCL in a textual form of C99 dialect, rather bytecode formats targeted by multiple compiler backends, including Fortran ignored by Khronos.

Microsoft adopting SPIR-V as DXIL replacement is most likely a matter of convenience, the format got messy to maintain, is tied to an old fork of LLVM, and HLSL has gotten the industy weight, even favoured over GLSL for Vulkan (which Khronos acknowledge at Vulkanised 2024 not doing any work at all, zero, nada), so why redo DXIL from scratch, when they could capitalize on existing work to target SPIR-V from HLSL.

DXIL has other issues beyond being an orphaned fork of LLVM-IR. LLVM is ill-equipped to represents shaders, and there have been real bugs in the wild because of how not-a-shader-language LLVM-IR is. See this [0] post under the 'The classic subgroup breakage – maximal convergence gone awry' section. Read the whole series really if you haven't, it's a fantastic dive into how awful this stuff is.

DXIL is also a useless intermediate representation because parsing it is so bloody difficult nobody could actually do anything with it. DXIL was, and still is, functionally opaque bytes. You can't introspect it, you can't modify it or do anything of use with it. SPIR-V is dead-simple to parse and has an array of tools built around it because it's so easy to work with.

I don't really see how the OpenCL history is relevant to Vulkan either. Khronos losing the OpenCL game to Nvidia, certainly no thanks to Nvidia's sabotage either, doesn't change that SPIR-V is a much more successful format.

[0] https://themaister.net/blog/2022/04/24/my-personal-hell-of-t...