ZLUDA, projeto open source que permite executar apps CUDA em GPUs AMD

 (cgchannel.com)
3 pontos por GN⁺ 2024-03-06 | 1 comentários | Compartilhar no WhatsApp
  • ZLUDA 3 é uma tecnologia open source que busca executar sem modificações em GPUs AMD aplicações para GPUs NVIDIA que estavam presas ao CUDA
  • Começou como uma implementação alternativa drop-in de CUDA para GPUs Intel, mas, após a interrupção das avaliações pela Intel e pela AMD, agora foi publicado código voltado a GPUs AMD
  • No Blender, há casos de desempenho semelhante ao backend HIP nativo, mas 3DF Zephyr e RealityCapture aparecem como “much slower” no ZLUDA, indicando grande variação conforme o app
  • Foi confirmada a possibilidade de executar apps de CG exclusivos da NVIDIA, como RealityCapture e Arnold, mas o suporte a OptiX permanece mínimo no Linux, impondo limitações a workflows de renderização
  • Sem apoio da Intel ou da AMD, o projeto está próximo de “realistically now abandoned”, e a licença do NVIDIA SDK também restringe o desenvolvimento de camadas de tradução para plataformas não NVIDIA

O problema de dependência do CUDA que o ZLUDA 3 tenta resolver

  • ZLUDA 3 é um projeto open source que permite executar aplicações baseadas em GPU feitas para GPUs NVIDIA em hardware de outros fabricantes
  • Ele foi projetado para executar aplicações existentes em novo hardware sem modificações, sem exigir trabalho adicional de portabilidade dos desenvolvedores dos apps
  • O ZLUDA foi lançado inicialmente em 2020 como uma implementação alternativa drop-in de CUDA para GPUs Intel, e a continuidade do desenvolvimento ficou difícil após a versão 2, em 2021
  • Em 2021, quando Andrzej Janik trabalhava na Intel, a empresa avaliou o ZLUDA como candidato a tecnologia oficial, mas concluiu que “não havia caso de negócio para executar aplicações CUDA em GPUs Intel”
  • Depois de deixar a Intel em 2022, Janik procurou a AMD, que também avaliou o ZLUDA por dois anos, mas decidiu não prosseguir
  • Depois disso, o código atualizado foi publicado como open source; o contexto relacionado pode ser visto com mais detalhes no artigo da Phoronix

Escopo de funcionamento confirmado em apps de CG

  • O ZLUDA 3 tem como objetivo executar em GPUs AMD apps de GPU desenvolvidos com a API CUDA da NVIDIA
  • Nas áreas de VFX, motion graphics e visualização, alguns apps e renderizadores essenciais de CG são baseados em CUDA e, na prática, continuam exclusivos da NVIDIA
  • O HIP, da AMD, é uma tecnologia para portar apps CUDA para hardware AMD, mas exige trabalho dos desenvolvedores de software
    • O HIP é usado nas versões compatíveis com AMD do Redshift e do Cycles do Blender
    • O ZLUDA 3 também foi criado com base no HIP, mas seu objetivo é a execução sem modificações de apps CUDA existentes
  • Entre os softwares exclusivos da NVIDIA que Janik testou com o ZLUDA estão 3DF Zephyr, RealityCapture e Autodesk Arnold
  • O suporte ao Arnold está no nível de prova de conceito, e há um número limitado de cenas renderizadas com sucesso usando a implementação de OptiX do ZLUDA

Limitações práticas de desempenho e compatibilidade

  • Janik avalia que apps CUDA são executados em GPUs AMD com “near-native performance”
  • Segundo benchmarks da Phoronix e uma thread no fórum Blender Artists, há casos em que, no Blender, o desempenho do ZLUDA é semelhante ao do backend HIP nativo
  • Por outro lado, o repositório GitHub do ZLUDA marca 3DF Zephyr e RealityCapture como much slower no ZLUDA
  • Muitos renderizadores de GPU usam também o OptiX da NVIDIA, além do CUDA, para aceleração de ray tracing
    • O suporte a OptiX do ZLUDA é de nível “minimum”
    • O suporte a OptiX existe apenas no Linux, não no Windows
    • O estado da implementação é “buggy, unoptimized and incomplete”
    • O ZLUDA-OptiX não está incluído nas versões redistribuídas, então precisa ser compilado manualmente
  • É difícil avaliar se outros apps de CG baseados em CUDA podem ser executados sem testes dos usuários

Continuidade do projeto e restrições de licença

  • Janik considera que, sem apoio da Intel ou da AMD, o ZLUDA está em um estado “realistically now abandoned”
    • Ele está aberto a propostas que façam o projeto avançar
    • Caso contrário, é provável que apenas adicione suporte a tecnologias da NVIDIA de interesse pessoal, como DLSS
    • O código atual também pode ser útil para desenvolvedores de software que estejam fazendo portabilidade gradual de CUDA para HIP
  • Segundo uma atualização de 14 de março de 2024, a Tom’s Hardware apontou que os termos da licença do SDK da NVIDIA proíbem o uso de artefatos de SDK, incluindo o CUDA Toolkit, para desenvolver tecnologias de tradução voltadas a plataformas não NVIDIA
  • Versões compiladas do ZLUDA 3 estão disponíveis para Windows e Linux, e o código-fonte é fornecido sob Apache 2.0 ou MIT license
  • O download do ZLUDA 3 está disponível no repositório GitHub do projeto

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-06
Opiniões no Hacker News

  • Já houve uma discussão relacionada 22 dias antes: um post [0] dizendo que a AMD financiou uma implementação drop-in de CUDA baseada em ROCm e que depois ela foi publicada como open source recebeu 400 comentários
    Um comentário de topo digno de nota naquele thread dizia que a própria publicação foi resultado da AMD ter encerrado o financiamento: “Depois de 2 anos de desenvolvimento e análise, a AMD concluiu que não havia viabilidade comercial em executar aplicações CUDA em GPUs AMD. Uma das condições do meu contrato com a AMD era que eu poderia publicar o projeto se a AMD concluísse que ele não era adequado para desenvolvimento adicional. Foi assim que chegamos ao dia de hoje.” Fonte: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • É realmente absurdo a AMD ter cortado o financiamento deste projeto. Assim que ele foi publicado como open source, começou a gerar valor para usuários da AMD
    Esse tipo de coisa deveria ser a prioridade máxima da AMD, mas, em vez disso, ela ficou anos patinando com duas APIs alternativas com pouco suporte — agora talvez três?

    • No momento em que isso se tornar uma opção confiável, a Nvidia vai mandar uma ordem de cessar e desistir e processar. Como solução séria, é um beco sem saída; nesse contexto, dá para entender
    • Talvez seja porque querem fazer as pessoas usarem HIP
      “HIP é muito fino, com pouco ou nenhum impacto de desempenho em comparação com programar diretamente no modo CUDA”
      “A ferramenta HIPIFY converte automaticamente código-fonte CUDA para HIP”
      1. https://github.com/ROCm/HIP
    • Pensando estrategicamente, é difícil ver isso como o melhor para a AMD. Se não for algo de nível de produto e juridicamente validado, acaba sendo apenas uma ferramenta para permitir que desenvolvedores criem aplicações em AMD e as distribuam em Nvidia
      No mercado de placas de vídeo de consumo, isso pode trazer ganhos de curto prazo, mas no longo prazo é quase um tiro no pé que continua consolidando a posição da Nvidia em datacenters
    • É bem provável que tenham recebido informação prévia sobre o anúncio da NVIDIA e liberado esse contratado. Pelos termos do contrato, o projeto teria se tornado open source
    • Aqui há uma suposição de que a AMD escolheu desistir. Talvez ela esteja criando algo melhor, não?

  • Também parece relacionado a esta discussão o post dizendo que “a Nvidia proibiu o uso de camadas de tradução para executar software CUDA em outros chips” [1]

    [1] https://news.ycombinator.com/item?id=39592689

    • Se você não usa hardware da Nvidia, não usa drivers da Nvidia e nunca concordou com a EULA da Nvidia, não sei por que deveria se importar
      Emulação é legalmente protegida, tanto de forma explícita quanto pela jurisprudência. A reprodução de APIs para fins de compatibilidade chegou até a Suprema Corte dos EUA, e foi decidido que não é passível de copyright. Pelo menos dentro de um escopo bastante amplo
      Não sou advogado, mas não vejo bem qual base jurídica a Nvidia espera usar. Para uma pessoa ou empresa que não tenha nenhum hardware da Nvidia, parece uma questão sem sentido. Se for uma empresa que já tem hardware da Nvidia, talvez dê para formular algum argumento, mas isso não entraria diretamente no terreno de conduta anticompetitiva?
    • Não sei em que isso é diferente de Wine/Proton. A EULA da Microsoft deve ter condições parecidas; se fossem aplicáveis, a Microsoft não teria enviado as mesmas ordens de cessar e desistir aos desenvolvedores do Wine?
    • É importante enfatizar novamente que essa cláusula, ao contrário do que afirma a matéria, já estava na EULA do CUDA desde janeiro de 2022 e, ao contrário do que diz a atualização da matéria, também estava incluída no download
    • Isso importa? Não é preciso permissão de ninguém para implementar um sistema com interface compatível com outro sistema
      Isso violaria a EULA, mas, desde que você não baixe o software CUDA, não precisa concordar com a EULA, e os autores do ZLUDA provavelmente conseguiram evitar isso
    • A NVIDIA não tem esse direito. Não há NVIDIA SDK envolvido aqui

  • “A Intel também acabou concluindo que ‘não havia viabilidade comercial em executar aplicações CUDA em GPUs Intel’” — que situação complicada

    • Em resumo, toda empresa que atinge certo tamanho e idade passa a sonhar em ser monopolista, não em ser concorrente
    • A divisão de gráficos da Intel era tão ruim que precisou abandonar o nome Intel HD por causa da impressão negativa que deixou nas pessoas

  • Foi confirmado algo que qualquer pessoa que já tenha mexido uma vez com GPGPU da AMD sabe. A única coisa que impede a AMD de se tornar uma empresa de 2 trilhões de dólares é um software realmente terrível
    Lembro de ter encontrado um bug no compilador OpenCL da AMD [1], e também era muito fácil derrubar o compilador OpenCL com um erro de segmentação. Isso nunca foi corrigido, então desisti de reportar
    A AMD não ter desenvolvido um concorrente do CUDA é uma das decisões mais míopes que já vi. Não sei por que o conselho não foi substituído por pessoas que entendam que, mesmo fabricando o melhor hardware, se o software que o usa for, para dizer de forma bem gentil, péssimo, ninguém vai comprar nem usar
    Nós, clientes, somos obrigados a comprar placas Nvidia caras porque o conselho da AMD é rico demais para se importar com algo como 1 trilhão de dólares de valor deixado sobre a mesa. Quem tem ações da AMD deveria fazer perguntas. Esse conselho deveria descer pelo ralo mais próximo
    [1] https://github.com/msoos/amdmiscompile -- no fim, isso foi corrigido

    • Você consegue explicar o que é GPGPU como se estivesse explicando para JavaScript?
      Meu entendimento ingênuo é que uma placa de vídeo é um computador estranho em que você pode colocar instruções e dados e deixá-lo calcular sozinho
      Não entendo por que CUDA é algo tão importante. A AMD não poderia simplesmente permitir acesso direto à GPU como se fosse um array de 4096 placas Arduino?
    • Sim. Por outro lado, a AMD geralmente é mais amigável ao open source que a Nvidia. A Nvidia foi ativamente hostil por um tempo; basta ver o vídeo do “F* you!” do Linus
      Empresas que desenvolvem hardware, em geral, são ruins em software. Há exceções, mas não muitas, e essas empresas de fato foram recompensadas na cotação das ações. Não conheço a cultura da divisão de software da AMD, mas normalmente consertar algo assim exige uma mudança bem grande
      Só trocar o conselho provavelmente não resolveria. Se as ordens da alta direção não forem o único fator que está puxando a empresa para baixo, seria preciso trocar muito mais camadas de gestão e substituir também um número considerável de gerentes intermediários. Se a contratação de software tiver sido malfeita, às vezes é preciso trocar até contribuidores individuais
    • Não entendo por que a AMD não se alia à Intel para promover SYCL como o padrão de GPGPU e de programação heterogênea
      A Intel é boa em software, SYCL é um padrão aberto, então as duas empresas poderiam se beneficiar do mesmo código, e os clientes poderiam rodar código SYCL até em um Threadripper, se quisessem. Hoje em dia alguns Threadripper chegam a ser tão rápidos quanto algumas GPUs
      A AMD está tentando criar seu próprio ecossistema proprietário com aprisionamento? Não entendo por que ela não se compromete com um padrão aberto multiplataforma
    • Eu, particularmente, gostava bastante do AMD Software em si. Quando um jogo ou software não oferecia suporte nativo, era fácil limitar a taxa de quadros a 60 para evitar que a GPU rodasse no máximo, e também dava para configurar por atalho um replay instantâneo que ficava gravando continuamente os últimos minutos, como o Shadowplay
      Quando meu UPS não era bom, também dava para limitar a potência da GPU, e eu conseguia fazer overclock automático para tentar usar a RX 580 por mais ou menos mais um ano
      Porém, o software/driver desde mais ou menos 2020 faz títulos de VR travarem em menos de uma hora. Não há pacote de software para Linux, e o CoreCtrl não é tão bom. Às vezes o replay instantâneo simplesmente não funciona. Nunca consegui fazer o ROCm funcionar direito com LLM local, nem no Windows nem no Linux, e o DKMS adorava fazer um monte de compilações inúteis a cada apt upgrade
      Estou em dúvida se, por curiosidade, pego uma Intel Arc como próxima GPU ou se simplesmente volto para a Nvidia. As candidatas seriam algo como A580, RX 6600 e RTX 3050, e talvez eu consiga aguentar até os preços de outros componentes caírem

  • Existe alguma linguagem de programação que compile para várias linguagens de kernel, como Metal, CUDA e alguma coisa da AMD? Se não existe, por quê?
    Compiladores C compilam para várias arquiteturas de CPU. Não deveria haver também um compilador para arquiteturas de GPU? Talvez só ninguém tenha criado ainda

    • Dá para incluir OpenCL nisso?
      https://www.khronos.org/api/opencl
    • O OpenMP 5 especificou suporte a GPU. Pelo que vi em uma busca rápida, alguns compiladores agora parecem oferecer suporte pelo menos parcial

  • Alguém já usou isso para rodar ferramentas open source de fotogrametria como o Meshroom? O artigo menciona algumas ferramentas proprietárias, mas minhas necessidades são bem pequenas

  • Isso parece quase igual ao caso Oracle vs. Google envolvendo o uso de bytecode da JVM

    • Não me parece. A questão não é a conversão de bytecode, mas vincular uma propriedade intelectual de biblioteca de nível mais alto ao hardware
      Isso é parecido com o Google dizer: “nossos aplicativos Android só podem rodar em celulares aprovados pelo Google”. Pelo que entendo, o Google de fato faz isso para coisas como o framework Play ou Maps

  • Ouvi recentemente um rumor interessante: a pessoa responsável por CUDA na NVIDIA teria lutado durante anos para conseguir recursos e convencer a empresa a levar esse projeto a sério
    Sem CUDA, a NVIDIA nunca teria se tornado a empresa de quase 1 trilhão de dólares que é hoje

  • O geohot continuar brigando com GPUs AMD caras também é relacionado: https://twitter.com/tinygrad/status/1764734675002810622