I know, I was there. I also think that objection to SPIR-V wasn't completely unfounded. SPIR-V is a nice binary representation of shaders, but it has problems i

I know, I was there. I also think that objection to SPIR-V wasn't completely unfounded. SPIR-V is a nice binary representation of shaders, but it has problems in the context of WebGPU adoption: 1. It's so low level that generating HLSL and MSL from it is more painful than it could be. For example, it represents branching in the form of a Control Flow Graph (which is typical for an IR). This is lower level than either a source language people would use (e.g. GLSL), or the destination backend language we need to produce (e.g. HLSL or MSL). This is unnecessary complexity for translation. 2. It has a lot of instructions, covering wide range of hardware (somewhat similar to Vulkan). In contrast, for WebGPU it would make sense to have fewer instructions for the ease of securing it and translating to other representations. 3. Friction in the features we need, vs features Khronos needs. There is also a situation where there is no single well specified and tested textual shading language. HLSL doesn't have a spec. MSL has documentation, but not enough for a spec, and it's not portable. GLSL kinda has a few specs, but realistically it's just specified by the implementation of glslValidator.