Arquitetura de Computação CDNA 3 da AMD

Arquitetura de GPU da AMD: CDNA vs RDNA

• A AMD dividiu o desenvolvimento de GPUs em CDNA (computação/HPC) e RDNA (gráficos), evoluindo o GCN para CDNA e reformulando os gráficos em RDNA.
• CDNA remove ou minimiza unidades focadas em gráficos (por exemplo, saídas de renderização), se destaca em computação e alimenta vários supercomputadores do Top500.
• RDNA é otimizada para jogos: melhor desempenho de rasterização, menor consumo de energia e menor tamanho de die em comparação com a antiga GCN (por exemplo, RX 5700 XT vs Radeon VII), mas mais fraca em recursos orientados a computação.
• Alguns argumentam que a divisão isola a computação e prejudica a percepção de mercado; outros dizem que a especialização era necessária para ser competitiva em jogos e HPC.

ROCm e Ecossistema de Software

• O ROCm atualmente distribui código de máquina de GPU por arquitetura em vez de bytecode semelhante ao PTX, forçando binários específicos por arquitetura para todas as bibliotecas e inflando o tamanho dos pacotes.
• Pequenas variantes de ISA (por exemplo, gfx1030 vs gfx1031) complicam o suporte; existem soluções alternativas e abordagens de longo prazo de “family ISA”, mas elas demoram a chegar.
• Muitos comentaristas descrevem o ROCm como frágil: suporte restrito a GPUs/OS, instalações dolorosas, demos que dão segfault e trackers de issues efetivamente abandonados.
• Alguns usuários relatam sucesso em placas de consumo não suportadas com pequenos ajustes de ambiente, mas isso é não oficial e frágil.

Comparação com NVIDIA e CUDA

• A consistência do CUDA entre gerações e produtos é vista como o principal moat da NVIDIA: a mesma API em GPUs de consumo e de data center, com PTX compatível com versões anteriores.
• A NVIDIA é retratada como “software-first”, investindo cedo (desde CUDA 2007) e continuamente em ferramentas, documentação e bibliotecas.
• A AMD é criticada por abandonar APIs passadas (por exemplo, implementações de OpenCL), reiniciar ecossistemas com frequência e alternar o suporte do ROCm, o que leva à desconfiança.
• Há debate sobre FLOPs brutos vs desempenho no mundo real; tensor cores e unidades matriciais especializadas tornam comparações simples de TFLOPs enganosas.

Padrões Abertos e Pilhas Alternativas

• OpenCL é visto como um padrão “traído”: preso ao C99, com pouco suporte da AMD/Intel e ignorado pela NVIDIA.
• SYCL/oneAPI são mencionados como mais abertos, com governança multi-vendor; backends Mesa/RustiCL e Vulkan/D3D existem, mas são imaturos ou de nicho.
• Alguns pedem um IR de GPU entre fornecedores, semelhante ao PTX/MSIL; outros observam complicações com SPIR-V e diferenças entre os modelos Vulkan/OpenCL.

Caminho de Computação para Consumidores e Hobistas

• A falta de suporte oficial robusto a computação em GPUs de consumo da AMD (especialmente APUs e placas mais antigas) é vista como uma grande oportunidade perdida para formar desenvolvedores.
• Vários argumentam que estudantes e hobistas em hardware de consumo se tornam os compradores de HPC de amanhã; negligenciá-los entregou esse funil ao CUDA e, cada vez mais, à Apple/Metal.

Tópicos Paralelos de Arquitetura e Terminologia

• A discussão toca na história do VLIW (Itanium, DSPs, GPUs AMD antigas), nas tendências de dual-issue em GPUs modernas e nos retornos decrescentes de paralelismo amplo em ordem.
• Estratégias de memória de GPU (grandes bancos de registradores, memória compartilhada/local, caches grandes, ocultação de latência via paralelismo massivo) são contrastadas com hierarquias de cache de CPU.
• Alguns reclamam de “compute” como substantivo; outros observam que isso é comum pelo menos desde os primeiros serviços em nuvem e a IA moderna.