Whoa. D3D is switching to SPIR-V as shader bytecode format! This is excellent, and I guess lets them move away from their llvm 3.7 fork easier. https://devblogs.microsoft.com/directx/directx-adopting-spir-v/
DirectX Adopting SPIR-V as the Interchange Format of the Future - DirectX Developer Blog

Today the Direct3D and HLSL teams are excited to share some insight into the next big step for GPU programmability. Once Shader Model 7 is released, DirectX 12 will accept shaders compiled to SPIR-V™. The HLSL team is committed to open development processes and collaborating with The Khronos® Group and LLVM Project. We’re sharing this […]

DirectX Developer Blog
@aras this will change a lot of things for graphics developers ^^
@aras just one more step towards the day when Windows is a reskinned Linux distro...
@rvkennedy @aras i am like super convinced that that was originally the plan before suddenly everyone started using PCs again with covid, quietly retiring NTOSKRNL and building internals on top of Linux. and in turn Windows 11 being so bad is because the Windows team were made to make the new one and theyre shittifying it on purpose
@exelia_antonov this tracks. I'm half-joking, but the idea they would just cancel Internet Explorer and try to get us using a reskinned Chrome browser would have seemed mad ten years ago.
@aras super welcome, about time! So much energy lost into all these stupid conversions 😒

@aras We've finally reached "embrace" with Vulkan's victory? Yay, i guess.

`US$0.02++`

@aras What kind of benefits does that bring? Aside from reduced maintenance for the DX team.

@Robin_Van_Ee @aras It makes things easier for the developers of debug tools like renderdoc.

(edited to remove incorrect information)

@aeva @Robin_Van_Ee not sure if one set of shaders for both would happen. SPIR-V for D3D would still have to have some extensions/ops in there that are different due to slightly different resource binding model etc
@aras @aeva @Robin_Van_Ee yeah I think that would be very unlikely, SPIR-V will need extensions to reflect D3D12’s particulars (especially the differences in binding)
@aeva @Robin_Van_Ee @aras I would be surprised if a Vulkan SPIRV blob could be loaded directly into D3D12 and vice versa (I think Vulkan and GL also use different SPIRV flavours?)
@floooh @aeva @Robin_Van_Ee @aras yes, there’s also a different flavor for OpenCL
@Robin_Van_Ee @aras SPIR-V in general is just a much nicer and saner format to work with compared to DXIL, which is basically LLVM 3.7 IR with a bunch of extra shader things bolted on. This means you can tap into various SPIR-V tools to parse/patch/optimize/reflect/link the bytecode instead of having to go to DXC for that (or pull off heroics to do it yourself like RenderDoc). It also makes it a lot easier for non-DXC compilers to emit native bytecode for D3D, and also for HLSL to evolve.
@mjp @Robin_Van_Ee @aras While the tooling for SPIR-V is good, I hate the fact that it is text-based. It is barely human readable. I found DXIL much nicer to debug shaders without source.
@vincentp @Robin_Van_Ee @aras what do you mean by “text based”? SPIR-V is a binary format too, no?
@mjp @Robin_Van_Ee @aras Oups I did not mean text based (maybe I thought about WebGPU when writing 😅 ). I hate the verbosity of SPIR-V! The format seems very bloated compared to DXIL.
GitHub - aras-p/smol-v: SMOL-V: like Vulkan/Khronos SPIR-V, but smaller.

SMOL-V: like Vulkan/Khronos SPIR-V, but smaller. Contribute to aras-p/smol-v development by creating an account on GitHub.

GitHub

@vincentp @Robin_Van_Ee @aras

Looking at these examples side-by-side:

https://godbolt.org/z/a43bso6Tj

https://godbolt.org/z/9611eTqsf

The DXIL version is actually longer in terms of total length. I agree that SPIR-V tends to have lots of decorations and constant declarations and such, but after that I generally find it more readable than DXIL's constant usage of "call" and "extractvalue" But there's certainly room for different opinions. 🙂

Compiler Explorer - HLSL (DXC 1.8.2403.2)

// The entry point and target profile are needed to compile this example: // -T ps_6_6 -E PSMain struct CBData { float4 X; float4 Y; uint Index; bool FlagA; bool FlagB; }; ConstantBuffer<CBData> CB; struct PSInput { float4 position : SV_Position; float4 color : COLOR0; float2 uv : UV; uint idx : IDX; }; Texture2D TexA; Texture2D TexB; SamplerState SampA; struct BuffElement { float X; float Y; }; ByteAddressBuffer Buffers[]; float4 PSMain(PSInput input) : SV_Target0 { float4 output = 0.0f; if (CB.FlagA) { float2 uv = input.uv * CB.Y.xy; output += TexA.Sample(SampA, uv) * CB.X; } else if (CB.FlagB) { float2 uv = input.uv * CB.Y.xy; output += TexB.Sample(SampA, uv) * CB.X; if (input.idx != 0xFFFFFFFF) { ByteAddressBuffer buff = Buffers[CB.Index]; BuffElement elem = buff.Load<BuffElement>(input.idx * sizeof(BuffElement)); output = output * elem.X + elem.Y; } } return output * input.color; }

@aras will this have an effect on shader pre-compilation issue?
@aras next they'll switch to Vulkan with DXVK/VKD3D for legacy support and eventually Windows will be a Linux distro with a proprietary desktop, ads and crappy "genuine advantage" licensing. Probably they'll buy Ubuntu for that, it already integrates ads, a commercial pro mode and is reasonably popular...
@Doomed_Daniel @aras IMHO the logical next step should be to ditch HLSL in favour of a handful of C and C++ extensions in Clang (similar to what Apple did with MSL).