ROCm desafia o CUDA: ‘avançando um passo de cada vez’

 (eetimes.com)
2 pontos por GN⁺ 15 일 전 | 2 comentários | Compartilhar no WhatsApp
  • A AMD está reforçando sua estratégia de GPUs para datacenter com foco na pilha de software de IA ROCm para enfrentar o ecossistema CUDA da Nvidia
  • O ROCm evoluiu de um simples conjunto de firmwares no início para uma plataforma de software completa e está adotando um ciclo de lançamentos a cada 6 semanas para garantir usabilidade estável
  • Por meio do OneROCm, a empresa busca integrar a pilha de IA e garantir portabilidade entre CPU, GPU e FPGA, além de aumentar a eficiência de desenvolvimento com reutilização de código baseada em Triton e MLIR
  • O ROCm tornou open source todos os componentes, exceto o firmware, absorvendo a velocidade de inovação da comunidade, e também oferece suporte padrão em notebooks com Strix Halo e na versão para Windows
  • A AMD dá prioridade à resposta ao feedback de desenvolvedores e à recuperação da confiança da comunidade, com o objetivo de transformar o ROCm em uma plataforma sustentável e centrada em desenvolvedores pelos próximos 10 anos

A evolução do AMD ROCm e a estratégia para competir com o CUDA

  • A AMD está promovendo a pilha de software de IA ROCm como estratégia central para enfrentar o ecossistema CUDA da Nvidia no mercado de GPUs para datacenter
  • Anush Elangovan, vice-presidente da divisão de software de IA, descreve o desenvolvimento do ROCm como “subir uma montanha, avançando um passo de cada vez”, destacando a importância de melhorias contínuas e integração
  • Ele entrou na AMD após a aquisição da startup Nod.ai, e a equipe da Nod contribuiu para importantes projetos open source como Shark, Torch.MLIR e IREE
  • Com o OneROCm, a AMD busca integrar a pilha de IA entre CPU, GPU e FPGA e encurtar o ciclo de desenvolvimento de software para 6 semanas, com a meta de chegar a um nível em que “o usuário nem precise se preocupar com a versão”
  • Atualmente, o ROCm se prepara para uma transição voltada à engenharia com suporte de IA, acelerando sua expansão com foco no ecossistema open source e na comunidade de desenvolvedores

O avanço do ROCm e a estratégia de software

  • No início, o ROCm era um conjunto de vários fragmentos de firmware, mas após dois anos e meio de investimento evoluiu para uma plataforma de software completa
    • Elangovan afirma ter usado a cultura de desenvolvimento da equipe do Google Chrome como referência para buscar ciclos regulares de lançamento e uma experiência de usuário estável
    • O ROCm passou a ser um software que “simplesmente funciona” e deve migrar para um modelo de lançamentos a cada 6 semanas
  • A AMD está em transição de uma empresa centrada em hardware para uma empresa centrada em software, e vê como próximo ponto de virada a engenharia assistida por IA (AI-assisted engineering)

Integração da pilha de IA e portabilidade

  • Com o OneROCm, a AMD concretiza a integração da pilha de IA entre diferentes tipos de hardware, como CPU, GPU e FPGA
    • Alguns componentes ainda dependem do hardware, mas toda a aceleração é feita pela pilha ROCm, o que garante portabilidade (portability)
  • A disseminação do framework Triton reduziu os problemas de compatibilidade entre GPUs
    • Antes, kernels CUDA eram convertidos para kernels HIP, mas agora é possível escrever kernels em Triton e executá-los tanto em AMD quanto em Nvidia
    • A AMD investe ativamente no Triton e na infraestrutura de compiladores MLIR, e dá suporte ao redirecionamento de código para vários tipos de hardware por meio da manutenção do Torch.MLIR
  • A maioria dos clientes de inferência usa frameworks de LLM como vLLM e SGLang, e os pedidos para conversão de código CUDA vêm diminuindo
    • Quando surge um novo algoritmo de attention, é possível otimizar kernels baseados em Triton em um ou dois dias
    • O HIPify continua disponível para clientes de HPC, e a empresa usa Claude AI para validação e geração de código ao escrever novos kernels

Estratégia open source

  • O ROCm disponibiliza 100% dos componentes como open source, com exceção do firmware
    • Ao abrir o código, a AMD obtém validação da comunidade de desenvolvedores e também pode aproveitar a velocidade de inovação da comunidade, mais rápida que a da própria AMD
    • Qualquer pessoa pode participar no ponto que quiser, como compiladores ou runtime, sem ficar limitada ao ritmo de colaboração da AMD
  • A AMD está expandindo ativamente a comunidade de desenvolvedores, e o ROCm já vem com suporte padrão em notebooks com Strix Halo
    • Atualizações da versão do ROCm para Windows são distribuídas no mesmo dia que as do hardware de datacenter Instinct

Comunidade de desenvolvedores e cultura de feedback

  • Elangovan valoriza a comunicação direta com desenvolvedores e coleta feedback em tempo real pelo X (Twitter)
    • Ele monitora palavras-chave como “ROCm”, “ROCm sucks” e “AMD software not working” e responde pessoalmente a todas as postagens
    • Segundo ele, a maioria dos problemas vem de falta de educação e suporte, e ele oferece orientação direta até mesmo a desenvolvedores anônimos
  • A AMD investigou mais de 1.000 reclamações relacionadas ao ROCm no GitHub e resolveu todas em um ano
    • Havia muitos pedidos de suporte para hardware antigo, que hoje é mantido pela AMD ou pela comunidade
    • Com essa postura, a confiança dos desenvolvedores foi restaurada, e se espalhou a percepção de que “a AMD resolve os problemas”
  • Elangovan demonstrou expectativa em relação à GPU MI450, prevista para o segundo semestre de 2026, e destacou que pretende transformar o ROCm em uma plataforma sustentável para a próxima década
    • O objetivo é construir um ecossistema estável em que desenvolvedores não precisem se preocupar mesmo quando surgir novo hardware

Direção futura e filosofia

  • Com base em sua experiência na Nod.ai, Elangovan cita casos em que tecnologias de compiladores foram adotadas por praticamente todas as empresas de aceleradores
    • Ele afirma que “é preciso avançar um passo de cada vez com convicção”, definindo a evolução do ROCm como resultado de execução contínua
  • A AMD está indo além de simplesmente copiar o CUDA e desenvolve funcionalidades diferenciadas para o ROCm, com a meta de se posicionar no longo prazo como uma plataforma centrada em desenvolvedores

Leituras relacionadas

2 comentários

 
picopress 12 일 전

Comecem pelo driver...
 
GN⁺ 15 일 전
Comentários do Hacker News

  • Na última semana, enquanto portava o TheRock para o stagex, tentei compilar o ROCm com uma toolchain baseada em musl/mimalloc
    porque, em workloads em que segurança e privacidade são críticas, não dá para confiar em binários construídos com um único compilador
    Foi um pesadelo empacotar mais de 30 dependências e um LLVM customizado, mas finalmente consegui compilar o runtime hoje de manhã
    O fato de o hardware da AMD funcionar em um ambiente totalmente aberto dá esperança para workloads de alta segurança

    • Eu também tentei empacotar o ROCm sobre musl, especialmente para Alpine Linux
      Consegui passar pelo fork customizado de LLVM e por vários pacotes, mas no fim desisti porque era perda de tempo
      Agora uso o llama.cpp com suporte a Vulkan e estou bastante satisfeito
      Se você puder compartilhar a receita de build, acho que ajudaria a passar da etapa final do port para Alpine
    • É triste ver essa situação se repetir
      No ano passado parei a campanha de acionistas por confiar nas promessas da AMD, mas agora sinto que realmente é preciso agir
      unlockgpu.com/action-plan
    • Dá até dor no coração ver a issue #3477
      Não pode ser assim, esse trabalho claramente precisa ser utilizável
    • O motivo para não confiar na Nvidia é porque o driver é fechado?
      A Nvidia também prometeu melhorar os drivers open source
      Pessoalmente, acho mais atraente a Intel oferecer 32 GB de VRAM na faixa dos 1000 dólares
    • Achei interessante a frase “não dá para confiar em binários construídos com um único compilador”
      É um esquema de misturar e linkar arquivos .o gerados por compiladores diferentes?
      Fiquei curioso se é um workload que realmente tenta evitar, na prática, o problema de Reflections on Trusting Trust

  • Desde fevereiro venho pedindo à AMD para incluir kernels Tensile ajustados para gfx1201 no rcom-libs, mas ninguém sabe quem é o responsável
    Nem no Discord de desenvolvedores respondem, o que é frustrante. Parece um caso que expõe não só problemas técnicos, mas também um gargalo organizacional na AMD

  • A AMD ainda tem que tirar uma defasagem de vários anos em ROCm
    Nem todas as GPUs da empresa capazes de fazer operações de IA são suportadas, e mesmo quando são há muitos bugs
    O driver AMDGPU para Linux vem ficando instável desde o 6.6

    • O motivo de não conseguirem contratar talentos é simples. Eles precisam competir por talentos com as melhores empresas do mundo, e a AMD ainda estava lutando pela própria sobrevivência há apenas 10 anos
    • No fim, não é porque não pagam o suficiente?
    • O ROCm ficou abandonado por tempo demais. Há 5 anos meus amigos tentaram convencer internamente a aumentar o investimento, mas falharam
      Não perceber que a IA se tornaria importante foi claramente um erro
      Seria melhor para toda a indústria se a AMD fosse competitiva nisso, mas ela mesma causou essa situação
    • Isso também pode ser um problema cultural
      Desde os tempos da ATI já havia má fama de drivers cheios de bugs, e parece que essa cultura não mudou depois da aquisição pela AMD

  • No ano passado a AMD coletou reclamações sobre ROCm no GitHub e anunciou que havia resolvido todas as 1000
    Mas, na prática, quase não houve aumento no suporte a hardware antigo

    • Se o nível é ter que vasculhar várias wikis e hackear manualmente o suporte à placa, fica difícil chamar isso de “adicionar suporte”

  • Quando chegar o dia em que o ROCm tiver suporte no lançamento para todas as placas AMD, aí sim talvez eu acredite no marketing
    Ter abandonado até placas relativamente novas, como a série 400, foi um grande erro
    Espero que a diretoria invista mais na stack de software

    • O CUDA também não é perfeito. Por exemplo, o GB10 já foi lançado há um bom tempo e ainda tem muitas funcionalidades não implementadas

  • O ROCm não é suportado em GPUs de consumidor comuns, como a RX 580
    Em vez disso, o backend Vulkan funciona bem

    • Comprei uma RX 580 em 2018, então é frustrante ver o pouco suporte às GPUs RDNA1 e RDNA2
      Acho normal a arquitetura GCN já ter perdido suporte, mas na geração RDNA o problema ainda é a falta de suporte
    • O ROCm normalmente só suporta duas gerações de GPU
      No momento, só RDNA3 e RDNA4 são possíveis, enquanto o CUDA ainda suporta Turing
      Veja a documentação oficial
    • Uso uma RX 5700, mas a versão do ROCm suportada é antiga demais para rodar o Ollama
      O backend Vulkan funciona bem, mas o suporte oficial demorou de 1 a 2 anos para chegar
    • O Vulkan funciona bem, mas faltam kernels JIT de C++·Fortran·Python, integração com IDE, depuração e suporte a bibliotecas
    • Acho que antigamente eu usava ROCm com a RX580, então isso agora está fora de suporte?

  • Gostaria que a stack do ROCm fosse organizada (clean-up)
    Algo como simplesmente git clone --recurse-submodules rocm e depois compilar com configure/make, com mensagens claras sobre dependências ausentes
    Hoje parece mais um monte de componentes jogados sem estrutura, e não se vê uma arquitetura consistente

  • Eu estou no time OpenVINO e SYCL contra o CUDA
    As iGPU e dGPU da Intel ficaram com preços razoáveis recentemente, e o suporte de software também melhorou
    Para workloads de visão computacional ou ciência de dados, em vez de jogos, isso escala bem

  • Este é o feedback sobre ROCm que eu gostaria de passar para a diretoria da AMD
    (1) Ter suportado só GPUs de servidor e ignorado GPUs/APUs de consumidor foi um erro estratégico
    A maioria dos desenvolvedores experimenta no notebook pessoal e depois escala para servidores
    Como o CUDA, ele precisa rodar em GPUs de consumidor, mesmo que com desempenho menor
    (2) A política de suportar só duas gerações é irracional do ponto de vista do cliente
    Veja a documentação oficial
    O CUDA mantém uma retrocompatibilidade forte
    (3) Focar só em Triton e tratar HIP como algo de segunda categoria é uma direção errada
    Ainda existe muito código de HPC, simulação e computação científica baseado em C/C++
    GPUs da AMD têm desempenho FP64 como ponto forte, então isso é praticamente abrir mão da própria vantagem
    (4) Por fim, é preciso melhorar a qualidade do empacotamento
    Cooperar com mantenedores de distribuições não custa tanto e pode gerar vantagem competitiva frente à Nvidia

    • O ponto forte do CUDA é o suporte polyglot
      Dá para escrever kernels diretamente em várias linguagens, como Python e Julia, e a integração com IDE, depuradores e bibliotecas é excelente
      Quando se olha o ecossistema GPGPU como um todo, AMD e Intel ainda não alcançam o nível de maturidade do ecossistema do CUDA
    • Empacotamento, na verdade, não é algo simples
      A maioria das empresas opta por um modelo de instalação do fornecedor como /opt/foo/
      Isso também facilita para a distribuição empacotar por conta própria depois
      Mas, para entender isso, é preciso ter gente com experiência no ecossistema open source
    • A NVIDIA também está cometendo erros parecidos
      Está atrasando o lançamento de GPUs de consumidor com muita VRAM e focando no mercado de servidores
      Se a AMD souber aproveitar essa brecha, isso pode virar uma oportunidade
    • Na prática, o ROCm funciona oficiosamente mesmo sem suporte oficial
      Por exemplo, ele roda bem na 7900 XT
      Só não aparece como “suporte oficial” porque a AMD não investe recursos de teste nisso

  • Pela minha experiência anterior com compute shaders, CUDA, ROCm e OpenCV são todos complicados demais de instalar
    As dependências são grandes, e o CUDA ocupa 11 GB
    Acho melhor simplesmente usar Vulkan. Não fica preso a plataforma e “simplesmente funciona”

    • O Vulkan é fácil de instalar, mas o código é complexo
      Só compilação de shader e configuração de recursos já exigem centenas de linhas, e para lidar com endereços de GPU são necessárias extensões
    • No Windows é só instalar um exe de 3 GB, e no Linux basta adicionar o repositório e instalar
      Não parece algo que deveria levar horas
    • O Vulkan é uma API de baixo nível, então até tarefas simples exigem mais de 200 linhas
      Antigamente, na NVIDIA, havia até um bug(?) em que mudar para modo gráfico gerava 20% mais desempenho