Projeto de código aberto ZLUDA permite que apps CUDA rodem em GPUs AMD
Um projeto de código aberto chamado ZLUDA pretende permitir que aplicações CUDA rodem em GPUs AMD, reacendendo as esperanças de quebrar a dominância da Nvidia na computação acelerada por GPU. Os comentaristas discutem os obstáculos técnicos e legais, desde as restrições da EULA da Nvidia e a dependência de bibliotecas proprietárias como cuDNN até os desafios de reimplementação em clean-room e de atingir paridade de desempenho. Grande parte do debate gira em torno do ecossistema de software da AMD, há muito criticado, e de suas escolhas estratégicas, incluindo por que ela deixou de financiar o ZLUDA e se alternativas como ROCm, HIP ou padrões abertos algum dia poderão rivalizar com a maturidade e o lock-in do CUDA.
Escopo do ZLUDA e Restrições Legais
- ZLUDA é uma implementação CUDA em clean-room, pronta para uso como substituto direto, voltada para GPUs não-Nvidia (primeiro Intel, agora AMD).
- A EULA do CUDA da Nvidia proíbe, desde pelo menos 2022, usar saídas do SDK para visar plataformas não-Nvidia e executar bibliotecas-chave (por exemplo, cuDNN, cuBLAS) em outro hardware.
- Debate sobre a aplicabilidade:
- Um lado: emulação e reimplementação de APIs são, em geral, legais; se você nunca concordou com a EULA da Nvidia, não está vinculado a ela, e isso pode ser anticoncorrencial.
- Outro lado: se apps empacotam binários da Nvidia, suas licenças podem proibir executá-los em runtimes de terceiros; o DMCA e casos anteriores de SO em hardware não fornecido pelo fabricante sugerem forte risco jurídico para uso comercial.
- Reverse engineering em clean-room é possível, mas caro e difícil de manter atualizado; fazer isso para todas as bibliotecas da Nvidia é uma grande barreira.
Estratégia da AMD e Ecossistema de Software
- Muitos argumentam que a maior fraqueza da AMD é o software: pilhas OpenCL/ROCm/HIP cheias de bugs, drivers instáveis e janelas curtas de suporte, apesar de um hardware razoável.
- A AMD financiou o ZLUDA por cerca de 2 anos e depois parou, alegando “sem caso de negócio”; o código tornou-se open source por contrato.
- Alguns veem isso como uma oportunidade perdida e “absurda”, já que beneficia imediatamente os usuários da AMD.
- Outros defendem que isso é racional: uma camada robusta de CUDA-na-AMD poderia reforçar ainda mais o CUDA, permitindo que desenvolvedores continuem centrados na Nvidia enquanto usam a AMD apenas como hardware de execução mais barato.
Limitações Técnicas e Práticas
- A dificuldade principal não é a tradução básica de kernels, mas equivalentes mantidos e de alto desempenho para as bibliotecas da Nvidia (cuDNN, cuBLAS etc.).
- A Nvidia tem o PTX como IR estável; a AMD frequentemente compila por arquitetura, o que complica suporte de longo prazo e otimização pela comunidade.
- Há relatos de ZLUDA + llama.cpp funcionando, mas mais lento que o ROCm nativo; APUs da AMD geralmente ficam limitadas pela largura de banda de memória e por uma “VRAM” efetiva pequena.
- Alguns entusiastas relatam boas experiências com LLMs pequenos em GPUs AMD de consumo; outros relatam crashes persistentes, segfaults e bugs de driver.
Alternativas e Padrões
- Alternativas mencionadas: HIP/HIPIFY (tradução de código-fonte, não runtime), ROCm, OpenCL, computação em Vulkan, SYCL, offload de GPU com OpenMP.
- Vários comentaristas argumentam que AMD e Intel deveriam impulsionar juntas padrões abertos como o SYCL; outros observam que a fragmentação e implementações ruins limitaram a adoção.
Perspectiva de Mercado Mais Ampla
- Vários comentários enquadram Nvidia, AMD e Intel como atuando como aspirantes a monopolistas assim que ganham poder.
- Há especulação de que reguladores, especialmente na UE, podem eventualmente ver as restrições da Nvidia como anticoncorrenciais, mas os resultados são incertos.