构建比 Microsoft 更好的 DirectX 着色器编译器？

Godot、dxil.dll 和许可证

• Godot 对 D3D12 的支持依赖于 Microsoft 专有的 dxil.dll，这与其避免捆绑闭源组件的目标相冲突。
• 一些用户认为最终用户“只想东西能用”，并不在乎驱动/库是否为专有；另一些人则强烈倾向于避免专有驱动和二进制黑盒。
• 专有部分具体是 dxil.dll/libdxil.so 这个“签名”库，它作为二进制黑盒附带单独许可证；其源码不在 DXC 仓库中。
• 讨论强调，真正的阻碍是法律限制（例如点击同意要求、不可再分发条款），而不只是意识形态。

跨 API 着色器编译与 Mach/Zig

• Direct3D、Vulkan 和 Metal 之间的底层着色器生态被描述为一团糟，尤其是在交叉编译方面。
• Metal 着色器编译被 Apple 的专有编译器锁定，只能在 macOS 上使用，较新情况下也可在 Windows 上使用；Linux 主机若不做逆向工程，无法直接面向 Metal 目标编译。
• Mach 将 Zig 用作跨 API 着色器编译器和工具链的愿景，被认为如果能达到 Zig 跨平台编译故事的成熟度，可能会带来变革。

Microsoft 的激励与平台动态

• 有人认为 Microsoft 因为市场主导地位和锁定效应，没有多少动力改进软件；也有人反驳说，其内部游戏工作室依赖这些工具，因此质量仍然很重要。
• 关于 Valve 的 Proton/Wine 也有长篇争论：
  • 一方认为 Proton 会抑制原生 Linux 移植，因为“只支持 Windows”就足够了。
  • 另一方认为，鉴于 ABI 稳定性差和碎片化（glibc 版本、图形栈、Wayland 等），Proton 恰恰是让 Linux 游戏可行的关键。
• 多条评论将 Win32 描述为通过 Wine 在 Linux 上事实上的唯一长期稳定的二进制图形 API。

DXIL“签名”和逆向工程

• DXIL 的“签名”步骤被嘲讽为安全戏法；其他图形 API 无需它也能工作。
• 复现出的签名看起来只是经过轻微修改的 MD5 风格哈希；类似实现此前已经存在（例如在调试工具中）。
• 有人猜测作者没有明确描述 RE 过程，是为了保留法律上的可辩护空间，尽管也有人指出，出于互操作性目的的逆向工程通常是站得住脚的。

SPIR-V、着色器语言与工具链

• 有人主张采用类似 HLSL/GLSL → SPIR-V ↔ DXIL 的流水线，利用 SPIR-V 作为通用 IR。
• 对 SPIR-V→DXIL 的转换很感兴趣（提到了 Mesa 的 spirv2dxil），也提到了现有的 DXIL→SPIR-V（vkd3d）。
• 一位评论者认真建议直接用 SPIR-V 编写着色器，以获得更好的跨驱动预测性，尽管作者成本更高。
• 有人对 LLVM/C++ 依赖的“臃肿”表示不满，并希望有基于纯 C99、更简洁的编译器。

发布 dxil.dll vs 开源实现

• 有人指出，很多游戏已经捆绑了大量专有 DLL，因此额外加入 dxil.dll 实际上问题不大。
• 反对意见包括：
  • 对小型游戏/工具来说，体积和依赖膨胀很重要。
  • 仅二进制依赖会让工具链升级、交叉编译以及向新的主机/目标平台移植变得更复杂。
  • 拥有所有源码能带来更多控制权，并减少长期集成麻烦。

其他相关话题

• SDL 正在开发 SDL_gpu，作为跨平台图形抽象和着色器层；与 WebGPU 的比较引发了对 WebGPU 复杂性以及其网络安全开销的担忧。
• 有报告称 Halo CE 在 Apple Silicon 上通过 Wine 运行效果很差，因此有人建议尝试 Apple 的 Game Porting Toolkit（D3D→Metal）。
• 多条评论称赞 Mach/Zig 生态（例如 mach-sysgpu/WebGPU 重实现）以及推动更好图形工具的整体“基础设施工作”。
• 据说 Microsoft 对其 DXC 分支损害了 LLVM 的部分代码生成；Microsoft 已明确表示他们不会在 DXC 中恢复 DXBC 生成，而可能在之后通过 upstream Clang 支持它，前提是先专注于 DXIL 和 SPIR-V。