Building the DirectX shader compiler better than Microsoft?

Godot, dxil.dll, and licensing

• Godot’s D3D12 support depends on Microsoft’s proprietary dxil.dll, conflicting with its goal to avoid shipping closed-source components.
• Some users argue end-users “just want things to work” and don’t care if drivers/libraries are proprietary; others strongly prefer avoiding proprietary drivers and blobs.
• The proprietary part is specifically the dxil.dll/libdxil.so “signing” library, shipped as a binary blob with a separate license; its source is not in the DXC repo.
• Legal constraints (e.g., click-through requirements, non-redistributable terms) are emphasized as the real blocker, not just ideology.

Cross-API shader compilation and Mach/Zig

• The underlying shader ecosystem across Direct3D, Vulkan, and Metal is described as a mess, especially for cross-compilation.
• Metal shader compilation is locked behind Apple’s proprietary compilers, available only on macOS and more recently Windows; Linux hosts can’t target Metal directly without reverse engineering.
• Mach’s vision of using Zig as a cross-API shader compiler and toolchain is seen as potentially transformative if it reaches the polish of Zig’s cross-compilation story.

Microsoft incentives and platform dynamics

• Some argue Microsoft has little incentive to improve software because of its dominance and lock-in; others counter that internal game studios depend on these tools, so quality matters.
• Long debate about Valve’s Proton/Wine:
  • One side says Proton discourages native Linux ports by making “Windows-only” a sufficient target.
  • The other side says Proton is what makes gaming on Linux viable at all, given poor ABI stability and fragmentation (glibc versions, graphics stacks, Wayland, etc.).
• Several comments characterize Win32 as effectively the only long-term-stable binary graphics API for Linux via Wine.

DXIL “signing” and reverse engineering

• The DXIL “signing” step is derided as security theater; other graphics APIs work without it.
• The recreated signing appears to be a lightly modified MD5-style hash; similar implementations already existed (e.g., in debugging tools).
• There is speculation that the author avoided describing the RE process explicitly to maintain legal deniability, though others note interoperability-focused RE is generally defensible.

SPIR-V, shader languages, and toolchains

• Some advocate a pipeline like HLSL/GLSL → SPIR-V ↔ DXIL, leveraging SPIR-V as a common IR.
• There’s interest in SPIR-V→DXIL conversion (Mesa’s spirv2dxil mentioned) and existing DXIL→SPIR-V (vkd3d).
• One commenter seriously proposes authoring shaders directly in SPIR-V for better cross-driver predictability, despite higher authoring cost.
• Frustration is expressed with LLVM/C++ dependency “bloat,” and a desire for plain C99-based, simpler compilers.

Shipping dxil.dll vs open implementation

• Some note many games already ship lots of proprietary DLLs, so adding dxil.dll seems practically fine.
• Counterpoints:
  • Size and dependency bloat matter for small games/tools.
  • Binary-only deps complicate toolchain upgrades, cross-compiling, and porting to new hosts/targets.
  • Having source for everything gives more control and fewer long-term integration headaches.

Other related topics

• SDL is working on SDL_gpu as a cross-platform graphics abstraction and shader layer; comparisons to WebGPU raise concerns about WebGPU’s complexity and web-security overhead.
• Reports that Halo CE runs poorly via Wine on Apple Silicon lead to suggestions to try Apple’s Game Porting Toolkit (D3D→Metal).
• Multiple comments praise the Mach/Zig ecosystem (e.g., mach-sysgpu/WebGPU reimplementation) and the general “infrastructure work” enabling better graphics tooling.
• Microsoft’s DXC fork is said to have damaged parts of LLVM’s codegen; Microsoft has clearly stated they won’t restore DXBC generation in DXC and may instead support it in upstream Clang later, after focusing on DXIL and SPIR-V.