Construir o compilador de shaders DirectX melhor do que a Microsoft?

Artigo original ↗ Discussão no Hacker News ↗

Um esforço de código aberto para reimplementar o compilador de shaders DirectX da Microsoft e a “assinatura” DXIL está chamando atenção por remover a necessidade de distribuir o `dxil.dll` proprietário da Microsoft, o que atualmente complica projetos como o motor Godot e ferramentas multiplataforma. Os comentaristas destacam como a compilação de shaders entre Direct3D, Vulkan e Metal é uma bagunça frágil e controlada pelos fornecedores, e veem o trabalho do Mach/Zig em direção a uma toolchain de shaders entre APIs e entre sistemas operacionais como potencialmente transformador para o desenvolvimento de jogos. O tópico também aborda restrições legais e de licenciamento, as vantagens de infraestrutura com código-fonte disponível em vez de DLLs opacas, e como camadas como Wine/Proton se tornaram alvos de fato de estabilidade e compatibilidade para jogos no Linux.

Godot, dxil.dll e licenciamento

  • O suporte do Godot a D3D12 depende do dxil.dll proprietário da Microsoft, o que entra em conflito com seu objetivo de evitar o envio de componentes de código fechado.
  • Alguns usuários argumentam que os usuários finais “só querem que funcione” e não se importam se drivers/bibliotecas são proprietários; outros preferem fortemente evitar drivers e blobs proprietários.
  • A parte proprietária é especificamente a biblioteca de “assinatura” dxil.dll/libdxil.so, distribuída como um blob binário com uma licença separada; seu código-fonte não está no repositório DXC.
  • Restrições legais (por exemplo, exigências de click-through, termos que não permitem redistribuição) são destacadas como o verdadeiro bloqueio, não apenas a ideologia.

Compilação de shaders entre APIs e Mach/Zig

  • O ecossistema subjacente de shaders em Direct3D, Vulkan e Metal é descrito como uma bagunça, especialmente para cross-compilation.
  • A compilação de shaders para Metal fica presa aos compiladores proprietários da Apple, disponíveis apenas no macOS e, mais recentemente, no Windows; hosts Linux não conseguem direcionar Metal diretamente sem engenharia reversa.
  • A visão do Mach de usar Zig como compilador e toolchain de shaders entre APIs é vista como potencialmente transformadora se alcançar o polimento da história de cross-compilation do Zig.

Incentivos da Microsoft e dinâmica de plataforma

  • Alguns argumentam que a Microsoft tem pouco incentivo para melhorar software por causa de sua dominância e lock-in; outros contrapõem que estúdios internos de jogos dependem dessas ferramentas, então a qualidade importa.
  • Longo debate sobre Proton/Wine da Valve:
    • Um lado diz que o Proton desencoraja ports nativos para Linux ao tornar “Windows-only” um alvo suficiente.
    • O outro lado diz que o Proton é o que torna os jogos no Linux viáveis de fato, dada a fraca estabilidade de ABI e a fragmentação (versões do glibc, stacks gráficos, Wayland etc.).
  • Vários comentários caracterizam o Win32 como, na prática, a única API binária de gráficos estável a longo prazo para Linux via Wine.

“Assinatura” DXIL e engenharia reversa

  • O passo de “assinatura” do DXIL é ridicularizado como teatro de segurança; outras APIs gráficas funcionam sem ele.
  • A assinatura recriada parece ser um hash levemente modificado no estilo MD5; implementações semelhantes já existiam (por exemplo, em ferramentas de depuração).
  • Há especulação de que o autor evitou descrever explicitamente o processo de RE para manter plausibilidade jurídica, embora outros observem que a engenharia reversa focada em interoperabilidade geralmente é defensável.

SPIR-V, linguagens de shaders e toolchains

  • Alguns defendem um pipeline como HLSL/GLSL → SPIR-V ↔ DXIL, aproveitando SPIR-V como um IR comum.
  • Há interesse em conversão SPIR-V→DXIL (o spirv2dxil do Mesa é mencionado) e em DXIL→SPIR-V (vkd3d).
  • Um comentarista propõe seriamente escrever shaders diretamente em SPIR-V para obter melhor previsibilidade entre drivers, apesar do custo mais alto de autoria.
  • Expressa-se frustração com o “inchaço” de dependências de LLVM/C++ e o desejo por compilers mais simples, baseados em C99 puro.

Distribuir dxil.dll vs implementação aberta

  • Alguns observam que muitos jogos já distribuem muitas DLLs proprietárias, então adicionar dxil.dll parece praticamente aceitável.
  • Contra-argumentos:
    • O tamanho e o inchaço de dependências importam para jogos/ferramentas pequenas.
    • Dependências binárias complicam upgrades da toolchain, cross-compiling e a portabilidade para novos hosts/alvos.
    • Ter o código-fonte de tudo oferece mais controle e menos dores de cabeça de integração no longo prazo.

Outros tópicos relacionados

  • O SDL está trabalhando no SDL_gpu como uma abstração gráfica multiplataforma e camada de shaders; comparações com WebGPU levantam preocupações sobre a complexidade do WebGPU e o overhead de segurança da web.
  • Relatos de que Halo CE roda mal via Wine no Apple Silicon levam a sugestões de tentar o Game Porting Toolkit da Apple (D3D→Metal).
  • Vários comentários elogiam o ecossistema Mach/Zig (por exemplo, a reimplementação mach-sysgpu/WebGPU) e o trabalho de “infraestrutura” em geral que viabiliza ferramentas gráficas melhores.
  • Diz-se que o fork de DXC da Microsoft danificou partes da codegen do LLVM; a Microsoft afirmou claramente que não restaurará a geração de DXBC no DXC e pode, em vez disso, oferecê-la no Clang upstream mais tarde, após focar em DXIL e SPIR-V.