ZLUDA torna possível executar aplicativos CUDA em GPUs AMD
- O ZLUDA 3, projeto open source desenvolvido por Andrzej Janik, permite executar em hardware de outros fabricantes aplicativos baseados em GPU que foram projetados para GPUs NVIDIA.
- A tecnologia foi projetada para permitir que aplicativos existentes rodem em novo hardware sem trabalho adicional dos desenvolvedores.
- Versões anteriores do ZLUDA permitiam executar aplicativos CUDA em GPUs Intel, mas na versão 3 o foco mudou para GPUs AMD.
O ZLUDA não era para GPUs Intel?
- O ZLUDA foi lançado inicialmente em 2020 como uma alternativa ao CUDA para GPUs Intel.
- Após o lançamento da versão 2 em 2021, Janik anunciou que não poderia continuar o desenvolvimento do projeto, mas depois a Intel passou a avaliar o ZLUDA como tecnologia oficial.
- A Intel decidiu que não havia um caso de negócio para executar aplicativos CUDA em GPUs Intel, e Janik deixou a empresa e procurou a AMD.
- A AMD avaliou o ZLUDA por dois anos, mas decidiu não levar o projeto adiante, e Janik publicou o código atualizado como open source.
Por que isso é importante para artistas de CG?
- A versão 3 do ZLUDA permite executar em GPUs AMD aplicativos baseados em GPU desenvolvidos usando a API CUDA da NVIDIA.
- Em setores como VFX, motion graphics e visualização, muitos aplicativos importantes de CG, especialmente renderizadores, são baseados em CUDA e exclusivos da NVIDIA.
- A AMD tem sua própria tecnologia, o HIP, mas isso exige trabalho dos desenvolvedores de software.
- O ZLUDA é, na prática, construído sobre o HIP e foi projetado para permitir que aplicativos CUDA rodem em GPUs AMD sem modificações.
Quão rápido é executar aplicativos CUDA com o ZLUDA?
- Janik descreve a execução de aplicativos CUDA em GPUs AMD como tendo "desempenho quase nativo".
- No entanto, segundo o repositório do ZLUDA no GitHub, 3DF Zephyr e RealityCapture ficam "muito mais lentos" com o ZLUDA.
- Muitos desenvolvedores de renderizadores GPU também usam o OptiX, uma segunda API da NVIDIA que contribui para o desempenho, e o ZLUDA oferece suporte "mínimo" ao OptiX.
Outros aplicativos de CG podem rodar em GPUs AMD via ZLUDA?
- Sem testes de usuários, é difícil dizer quão bem outros aplicativos de CG baseados em CUDA funcionarão com o ZLUDA.
- Há muitos problemas conhecidos, e Janik teve sucesso limitado com outros renderizadores GPU.
Mais aplicativos de CG baseados em CUDA poderão rodar com o ZLUDA no futuro?
- Janik afirma que, sem apoio da Intel ou da AMD, o ZLUDA está "realisticamente abandonado".
- Ele está aberto a propostas que possam levar o projeto adiante, mas, caso contrário, é provável que suporte apenas tecnologias da NVIDIA pelas quais tenha interesse pessoal.
- O código-fonte está disponível publicamente e, mesmo em seu estado atual, o ZLUDA pode ser usado por desenvolvedores de software como parte de uma "migração mais gradual" de CUDA para HIP.
Licença e requisitos de sistema
- Versões compiladas do ZLUDA 3 estão disponíveis para Windows e Linux. O código-fonte é fornecido sob as licenças Apache 2.0 ou MIT.
Opinião do GN⁺
- O ZLUDA tem potencial para estimular a concorrência no mercado de GPUs ao abrir o ecossistema proprietário CUDA da NVIDIA para usuários da AMD.
- O projeto pode beneficiar especialmente usuários de software de renderização ou aplicativos de computação científica que dependem de CUDA, ao oferecer mais opções de hardware.
- No entanto, como o ZLUDA ainda está em estágio inicial e não oferece desempenho e compatibilidade completos, sua adoção em ambientes reais de produção deve ser cautelosa.
- Reduzir a diferença tecnológica entre AMD e NVIDIA pode oferecer melhores preços e mais opções aos consumidores, o que pode incentivar uma concorrência saudável no mercado.
- O interesse contínuo e as contribuições da comunidade open source serão importantes para o sucesso do projeto, além de oferecer uma boa oportunidade de contribuição para especialistas da área.
1 comentários
Opiniões no Hacker News
Discussão anterior, há 22 dias: A AMD desenvolveu uma implementação de CUDA baseada em ROCm e a publicou como open source [0], com 400 comentários.
É muito irracional que a AMD tenha parado de financiar este projeto. Assim que foi aberto como open source, ele já começou a entregar valor para usuários da AMD, e isso deveria ser a prioridade máxima da empresa, mas a AMD perdeu anos com duas (ou seriam três?) APIs alternativas que até hoje têm pouco suporte.
Conteúdo relacionado à discussão: A Nvidia proíbe o uso de camadas de tradução do software CUDA para execução em outros chips [1]
A Intel também acabou decidindo que "não há um caso de negócio para executar aplicações CUDA em GPUs Intel". Isso apenas confirma o que qualquer pessoa que já lidou com GPGPU da AMD já sabe.
É bem conhecido que o software da AMD é muito ruim, e este é o único fator que impede a AMD de se tornar uma empresa de 2 trilhões de dólares. O compilador OpenCL da AMD tinha bugs, e era fácil derrubar o compilador com um segfault (acabei desistindo e nem reportei). Foi uma visão extremamente de curto prazo a AMD não desenvolver um concorrente para o CUDA. Não consigo entender por que o conselho da AMD ainda não foi trocado. Você pode criar o melhor hardware do mundo, mas se o software para usá-lo for péssimo, ninguém vai comprar nem usar. Como cliente, parece que o conselho da AMD não se importa com os trilhões de dólares em valor deixados sobre a mesa, então só resta comprar placas Nvidia superfaturadas. Quem possui ações da AMD deveria fazer perguntas, e esse conselho deveria ir direto para o ralo mais próximo.
Fico me perguntando se existe alguma linguagem de programação que consiga compilar para várias linguagens de kernel, como Metal, CUDA e o que quer que a AMD tenha. Se não existe, por que não? Assim como existem compiladores C que compilam para várias arquiteturas de CPU, não deveria haver também compiladores que compilam para arquiteturas de GPU? Talvez ninguém ainda tenha feito isso.
Fico curioso se alguém já tentou rodar isso em ferramentas OSS de fotogrametria como o Meshroom. O artigo menciona algumas coisas proprietárias, mas não parece que seja necessário tanto assim.
O problema das GPUs AMD não são os kernels individuais, e sim as bibliotecas. As notas de versão mencionam a 'adição de suporte mínimo para cuDNN, cuBLAS, cuSPARSE, cuFFT, NCCL e NVML', então parece que o projeto estava indo nessa direção. Ninguém sabe se ele conseguirá manter o embalo depois que a AMD cortou o financiamento.
Isso é quase exatamente o mesmo problema que usar bytecode da JVM no caso Oracle vs Google.
A luta contínua (e cara) do geohot com GPUs AMD também é relevante: link do Twitter