Desarrollan un compilador de shaders de DirectX mejor que el de Microsoft

Construir un compilador de shaders de DirectX mejor que Microsoft

• Una historia sobre el estado complejo del compilador de shaders de DirectX de Microsoft y el esfuerzo por ofrecer una mejor experiencia a los desarrolladores de videojuegos.
• Se está desarrollando para el motor Mach una API gráfica experimental llamada sysgpu, sucesora de WebGPU, usando Zig, y está previsto que soporte backends de Metal, Vulkan, Direct3D y OpenGL.
• Es necesario compilar programas de shaders utilizables en Direct3D 12.

Breve historia de DirectX

• La API gráfica DirectX usa HLSL como lenguaje de sombreado.
• En el pasado, antes de Direct3D 11, se usaba un compilador llamado FXC, conocido por ser notoriamente lento y por generar código poco optimizado.

FXC ya no se usa, y con Direct3D 12 apareció DXC

• Con el lanzamiento de Direct3D 12 y Shader Model 6.0 (SM6), Microsoft retiró FXC y presentó un nuevo compilador llamado DXC.
• DXC es un fork oficial de Microsoft de LLVM/Clang v3.7, y los cambios están claramente marcados mediante comentarios.

Lo que desayunan los drivers de DirectX: DXBC o DXIL

• Aunque HLSL es el lenguaje elegido para programar en Direct3D, en la práctica las GPU tienen arquitecturas de cómputo y requisitos diversos.
• Microsoft ofrece una API frontend amigable para desarrolladores, y los fabricantes de hardware independientes escriben drivers que lo transforman a algo lo más cercano posible al ISA real del hardware.
• Con la llegada de DirectX 12 y Shader Model 6.0, se empezó a usar un nuevo formato llamado DXIL en lugar de DXBC.

DXIL

• DXIL es el formato oficial que usan actualmente los fabricantes de drivers para DirectX 12.
• Los desarrolladores de videojuegos usan el compilador DXC para generar bytecode DXIL, que luego se entrega al driver gráfico para convertirlo en el código máquina real que se ejecutará en el hardware de la GPU.

Modificaciones al fork de LLVM de Microsoft

• Microsoft reconoce que no es ideal que los fabricantes de drivers independientes usen un formato específico de bitcode de LLVM, y admite que mantener un fork de LLVM no es agradable.
• Microsoft empezó a trabajar para integrar directamente el soporte de compilación de HLSL en LLVM/Clang.

Desafíos para desarrolladores de videojuegos, WebGPU y más

• Una capa de abstracción gráfica debe ofrecer un lenguaje de sombreado unificado, y actualmente la mayoría de las implementaciones de WebGPU usan un enfoque de compilar HLSL a DXBC o DXIL.

Una vía de escape sencilla: SPIR-V

• Vulkan/SPIR-V usa un enfoque similar, y corresponde a los fabricantes de GPU decidir si SPIR-V está optimizado o no.

¿Usar o no usar dxcompiler.dll?

• Un runtime de WebGPU debe decidir si usar el nuevo compilador HLSL DXC o el compilador FXC, oficialmente retirado y con peor rendimiento y calidad de generación de código.

¿Por qué no se puede enlazar estáticamente?

• El fork de LLVM de Microsoft no soporta enlace estático, y esto se debe a la complejidad del sistema de build.

Presentación de dxil.dll - blob propietario de firma de código para shaders de DirectX

• dxil.dll no se construye a partir del código fuente, sino que depende de blobs de código propietarios y específicos por plataforma dentro del repositorio “open source” de Microsoft.

Problemas de soporte de plataformas

• Microsoft solo distribuye dxil.dll para Windows (x86/arm) y Linux (x86), y no ofrece binarios para macOS ni Linux aarch64.

Resumen

• No se puede construir DXC como librería estática, y restaurar funcionalidad de LLVM por culpa del blob propietario de firma de código sería una tarea enorme.
• No es posible hacer compilación offline de shaders para juegos multiplataforma en pipelines de CI de macOS o Linux arm.

Mejoras al sistema de build

• Se busca una manera de migrar el sistema de build basado en CMake a build.zig para compilarlo como una sola librería estática.

Resolver la dependencia de librerías dinámicas

• Se hizo un fork del codebase de DXC y se modificó el código en C++ para eliminar las dependencias de librerías dinámicas.

Resolver la firma de código propietaria

• Se encontró una forma de compilar shaders HLSL sin depender de dxil.dll.

Resultado

• Se ofrece una librería dxcompiler y el CLI dxc en binarios estáticos que no dependen del dxil.dll propietario.
• Se construyen binarios para macOS, Linux y Windows dentro del pipeline de CI.

Advertencias

• Algunos binarios todavía no se han construido o probado, y el plan es usar Zig mismo como lenguaje de sombreado en lugar de HLSL.

Nota personal

• Tras conseguir un trabajo técnico de tiempo completo con el nombre Stephen, el autor ha mantenido actividad en línea para construir el motor Mach.
• Tiene raíces en el FOSS y cree que debemos ser dueños de nuestras herramientas y empoderarnos a través de ellas.
• Su sueño es construir Mach para todos y ganarse la vida vendiendo juegos de alta calidad.

Gracias por leer

• Revisa machengine.org.
• Considera apoyar el desarrollo para que pueda seguir haciendo más trabajo.
• Únete al servidor de Discord de Mach.
• Patrocina en GitHub.
• machengine.org

Opinión de GN⁺

• Lo más importante de este texto es el esfuerzo de la comunidad de desarrolladores por superar la complejidad y las limitaciones de DXC, el compilador de shaders de DirectX de Microsoft.
• Al mejorar el sistema de build de DXC con Zig y proponer un nuevo enfoque para compilar shaders HLSL sin depender del dxil.dll propietario, el desarrollador del motor Mach hace una contribución importante al desarrollo de juegos multiplataforma.
• El texto subraya la importancia del software de código abierto y que los desarrolladores deberían poder poseer y controlar sus propias herramientas, mostrando el valor de la colaboración y la innovación dentro de la comunidad técnica.

[GN⁺]

Opinión de Hacker News

• Excelente resumen sobre la complejidad de la compilación de shaders para APIs 3D

  • Se ofrece un panorama general del complejo problema de la compilación cruzada de shaders entre distintas APIs 3D.
  • Aunque se enfoca en D3D y Microsoft, la situación no mejora mucho en otras APIs 3D.
  • Por ejemplo, no se pueden compilar de forma cruzada shaders de Metal desde un host Linux; solo es posible en macOS y, recientemente, en Windows.
  • Si el equipo de Mach logra que "usar Zig como compilador de shaders cross-3D-API" funcione de forma tan fluida como "usar Zig como toolchain de compilación cruzada", sería el mayor acontecimiento en gráficos por computadora desde 1995.

• Problemas relacionados con Godot

  • La compatibilidad con Direct3D 12 depende actualmente de la biblioteca propietaria dxil.dll del DirectX Shader Compiler distribuido junto con Godot.
  • Distribuir software propietario va en contra de la misión del proyecto Godot.

• Debate sobre la distribución adicional de .dll

  • No sería necesario distribuir un .dll adicional, al igual que muchos videojuegos ya usan middleware propietario (Bink, SpeedTree, PhysX, etc.).
  • La mayoría de los launchers de juegos (Steam, GOG, Epic, etc.) también requieren sus propias .DLL.
  • Muchos juegos usan D3D11On12, y muchos juegos ya publicados incluyen dxil.dll entre sus archivos de instalación.
  • El trabajo de hacer ingeniería inversa a la firma de código y reimplementarla es impresionante, especialmente porque la salida coincide bit por bit con la de dxil.dll.
  • Sin embargo, quienes prefieran el camino más fácil podrían simplemente optar por distribuir la DLL.

• Pregunta sobre la firma de DXIL.dll

  • ¿La firma que realiza DXIL.dll es simplemente un MD5 modificado?

• Cambios de DXC sobre la capa e infraestructura de generación de código de LLVM

  • El fork de LLVM de DXC elimina o daña la capa de generación de código y la infraestructura de LLVM.
  • Resolver este problema y restaurar las funciones dañadas de LLVM sería una tarea enorme.
  • Debido a limitaciones de recursos, no hay planes de resolver este problema en el nuevo compilador DXC.
  • En el futuro, Clang podría llegar a soportar la generación de DXBC, pero ese trabajo no empezará en varios años porque antes se prioriza el soporte para generar DXIL y SPIR-V.
  • Se expresa agradecimiento a Microsoft por dejar claras las expectativas.

• Consejo sobre el ecosistema de Mach

  • Se recomienda investigar especialmente mach-sysgpu, una reimplementación completa de WebGPU, escrita principalmente por Ali Chraghi, de 17 años.

• Debate sobre SDL_gpu y SDL3

  • El equipo de SDL está desarrollando un nuevo lenguaje de shaders llamado SDL_gpu que se lanzará en SDL3.
  • Esto ofrecerá una forma de trabajar entre plataformas en lo relacionado con gráficos 3D en juegos.

• Uso del lenguaje Zig

  • Usar Zig en sí mismo como lenguaje de shading sería genial.
  • Zig es un lenguaje real, además de sistema de build y lenguaje de shading.

• Expresión de agradecimiento por el trabajo de infraestructura

  • Da gusto leer este tipo de trabajo de infraestructura porque abre muchas puertas.

• Mención sobre la pronunciación de DXIL

  • DXIL se pronuncia "dixel", como "pixel" cambiando la 'p' por una 'd'.