¿Construir el compilador de shaders de DirectX mejor que Microsoft?

Artículo original ↗ Discusión en Hacker News ↗

Un esfuerzo de código abierto para reimplementar el compilador de shaders DirectX de Microsoft y la “firma” de DXIL está llamando la atención por eliminar la necesidad de distribuir `dxil.dll`, propiedad de Microsoft, lo que actualmente complica proyectos como el motor Godot y las herramientas multiplataforma. Los comentaristas señalan cómo la compilación de shaders entre Direct3D, Vulkan y Metal es un lío frágil y controlado por los proveedores, y ven el trabajo de Mach/Zig hacia una cadena de herramientas de shaders entre APIs y entre sistemas operativos como potencialmente transformador para el desarrollo de juegos. El hilo también aborda las restricciones legales y de licencias, las ventajas de una infraestructura con código fuente frente a DLL opacas, y cómo capas como Wine/Proton se han convertido de facto en objetivos de estabilidad y compatibilidad para el gaming en Linux.

Godot, dxil.dll y licencias

  • La compatibilidad de Godot con D3D12 depende de dxil.dll, propiedad de Microsoft, lo que entra en conflicto con su objetivo de evitar distribuir componentes de código cerrado.
  • Algunos usuarios sostienen que los usuarios finales “solo quieren que las cosas funcionen” y no les importa si los controladores/bibliotecas son propietarios; otros prefieren firmemente evitar controladores y blobs propietarios.
  • La parte propietaria es específicamente la biblioteca de “firma” dxil.dll/libdxil.so, distribuida como un blob binario con una licencia separada; su código fuente no está en el repositorio de DXC.
  • Se enfatiza que las restricciones legales (por ejemplo, requisitos de click-through, términos que no permiten redistribución) son el verdadero bloqueo, no solo la ideología.

Compilación de shaders entre APIs y Mach/Zig

  • El ecosistema subyacente de shaders en Direct3D, Vulkan y Metal se describe como un desastre, especialmente para la compilación cruzada.
  • La compilación de shaders de Metal está bloqueada detrás de los compiladores propietarios de Apple, disponibles solo en macOS y, más recientemente, en Windows; los hosts Linux no pueden apuntar a Metal directamente sin ingeniería inversa.
  • La visión de Mach de usar Zig como un compilador de shaders y una cadena de herramientas entre APIs se considera potencialmente transformadora si alcanza el nivel de pulido de la historia de compilación cruzada de Zig.

Incentivos de Microsoft y dinámica de plataformas

  • Algunos argumentan que Microsoft tiene pocos incentivos para mejorar el software debido a su dominio y al bloqueo de usuarios; otros responden que los estudios internos de videojuegos dependen de estas herramientas, así que la calidad importa.
  • Largo debate sobre Proton/Wine de Valve:
    • Un bando dice que Proton desincentiva los ports nativos a Linux al hacer que “solo Windows” sea un objetivo suficiente.
    • El otro bando dice que Proton es lo que hace viable el gaming en Linux, dado el mal estado de la estabilidad de ABI y la fragmentación (versiones de glibc, stacks gráficos, Wayland, etc.).
  • Varios comentarios caracterizan Win32 como, en la práctica, la única API binaria de gráficos estable a largo plazo para Linux a través de Wine.

DXIL “signing” e ingeniería inversa

  • El paso de “firma” de DXIL es ridiculizado como teatro de seguridad; otras APIs gráficas funcionan sin él.
  • La firma recreada parece ser un hash ligeramente modificado al estilo MD5; ya existían implementaciones similares (por ejemplo, en herramientas de depuración).
  • Se especula que el autor evitó describir explícitamente el proceso de RE para mantener negación legal plausible, aunque otros señalan que la ingeniería inversa orientada a la interoperabilidad suele ser defendible.

SPIR-V, lenguajes de shaders y cadenas de herramientas

  • Algunos abogan por una cadena como HLSL/GLSL → SPIR-V ↔ DXIL, aprovechando SPIR-V como un IR común.
  • Hay interés en la conversión SPIR-V→DXIL (se menciona spirv2dxil de Mesa) y la existente DXIL→SPIR-V (vkd3d).
  • Un comentarista propone seriamente escribir shaders directamente en SPIR-V para lograr mejor predictibilidad entre drivers, a pesar del mayor coste de autoría.
  • Se expresa frustración con la “hinchazón” de dependencias de LLVM/C++ y el deseo de compiladores más simples basados en C99 puro.

Distribuir dxil.dll vs una implementación abierta

  • Algunos señalan que muchos juegos ya distribuyen muchas DLL propietarias, así que añadir dxil.dll parece, en la práctica, aceptable.
  • Contraargumentos:
    • El tamaño y la hinchazón de dependencias importan para juegos/herramientas pequeños.
    • Las dependencias solo binarias complican las actualizaciones de la cadena de herramientas, la compilación cruzada y el portado a nuevos hosts/objetivos.
    • Tener el código fuente de todo da más control y menos dolores de cabeza de integración a largo plazo.

Otros temas relacionados

  • SDL está trabajando en SDL_gpu como una abstracción gráfica multiplataforma y una capa de shaders; las comparaciones con WebGPU plantean preocupaciones sobre la complejidad de WebGPU y la sobrecarga de seguridad de la web.
  • Los informes de que Halo CE funciona mal vía Wine en Apple Silicon llevan a sugerencias de probar el Game Porting Toolkit de Apple (D3D→Metal).
  • Varios comentarios elogian el ecosistema Mach/Zig (por ejemplo, la reimplementación mach-sysgpu/WebGPU) y el trabajo de infraestructura en general que permite mejores herramientas gráficas.
  • Se dice que el fork de DXC de Microsoft dañó partes del codegen de LLVM; Microsoft ha dejado claro que no restaurará la generación de DXBC en DXC y que quizá la apoye más adelante en Clang upstream, después de centrarse en DXIL y SPIR-V.