Arquitectura de Cómputo CDNA 3 de AMD

Artículo original ↗ Discusión en Hacker News ↗

La división de AMD entre sus GPU CDNA de cómputo y sus GPU RDNA para juegos provoca debate sobre si la empresa sacrificó un ecosistema de software unificado en busca de hardware especializado. Los comentaristas contrastan el soporte fragmentado y a menudo frágil de ROCm y OpenCL de AMD con la estrategia de CUDA a largo plazo de Nvidia, argumentando que la consistencia de herramientas y la compatibilidad retroactiva —no los FLOPS brutos— fueron lo que hizo que Nvidia ganara los mercados de IA y HPC. Algunos ven esperanza en el soporte reciente de ROCm para Radeon de gama alta de consumo, pero muchos creen que el enfoque tardío e inconsistente de AMD en el software ha cedido una década crucial de presencia de marca a Nvidia.

Arquitectura de GPU de AMD: CDNA vs RDNA

  • AMD dividió el desarrollo de GPU en CDNA (cómputo/HPC) y RDNA (gráficos), evolucionando GCN hacia CDNA y reestructurando los gráficos en RDNA.
  • CDNA elimina o minimiza unidades centradas en gráficos (por ejemplo, salidas de renderizado), sobresale en cómputo y alimenta múltiples superordenadores del Top500.
  • RDNA está optimizada para juegos: mejor rendimiento de rasterización, menor consumo y menor tamaño de die frente a GCN más antigua (por ejemplo, RX 5700 XT frente a Radeon VII), pero es más débil para funciones orientadas al cómputo.
  • Algunos sostienen que la división aísla el cómputo y perjudica la presencia de marca; otros dicen que la especialización era necesaria para ser competitivo en juegos y HPC.

ROCm y ecosistema de software

  • ROCm actualmente distribuye código máquina de GPU por arquitectura en lugar de un bytecode similar a PTX, lo que obliga a binarios específicos por arquitectura para todas las bibliotecas e inflando el tamaño de los paquetes.
  • Pequeñas variantes de ISA (por ejemplo, gfx1030 frente a gfx1031) complican el soporte; existen soluciones alternativas y enfoques a más largo plazo de “family ISA”, pero tardan en llegar.
  • Muchos comentaristas describen ROCm como frágil: soporte limitado de GPU/SO, instalaciones dolorosas, demos que fallan con segfaults y rastreadores de incidencias prácticamente abandonados.
  • Algunos usuarios reportan éxito en tarjetas de consumo no compatibles con pequeños ajustes de entorno, pero esto no es oficial y es frágil.

Comparación con NVIDIA y CUDA

  • La consistencia de CUDA entre generaciones y productos se considera la principal ventaja de NVIDIA: la misma API en GPU de consumo y de centro de datos, con PTX retrocompatible.
  • Se presenta a NVIDIA como “primero el software”, invirtiendo pronto (desde CUDA 2007) y de forma continua en herramientas, documentación y bibliotecas.
  • Se critica a AMD por abandonar APIs pasadas (por ejemplo, implementaciones de OpenCL), reiniciar ecosistemas con frecuencia y rotar el soporte de ROCm, lo que genera desconfianza.
  • Hay debate sobre FLOPs brutos frente a rendimiento real; los tensor cores y las unidades matriciales especializadas hacen que las comparaciones simples de TFLOP sean engañosas.

Estándares abiertos y pilas alternativas

  • OpenCL se ve como un estándar “traicionado”: atascado en C99, mal soportado por AMD/Intel e ignorado por NVIDIA.
  • SYCL/oneAPI se mencionan como más abiertos, con gobernanza multivendedor; existen backends de Mesa/RustiCL y Vulkan/D3D, pero son inmaduros o de nicho.
  • Algunos piden un IR de GPU entre fabricantes similar a PTX/MSIL; otros señalan las complicaciones de SPIR-V y las diferencias entre los modelos de Vulkan/OpenCL.

Ruta de cómputo para consumidores y aficionados

  • La falta de soporte oficial y robusto para cómputo en GPU de consumo de AMD (especialmente APU y tarjetas antiguas) se ve como una gran oportunidad perdida para formar desarrolladores.
  • Varios argumentan que estudiantes y aficionados en hardware de consumo se convierten en los compradores de HPC del mañana; descuidarlos cedió este embudo a CUDA y, cada vez más, a Apple/Metal.

Hilos secundarios de arquitectura y terminología

  • La discusión aborda la historia de VLIW (Itanium, DSPs, GPU AMD más antiguas), las tendencias de doble emisión en GPU modernas y los rendimientos decrecientes del paralelismo amplio en orden.
  • Se contrastan las estrategias de memoria de GPU (grandes archivos de registros, memoria compartida/local, cachés grandes, ocultación de latencia mediante paralelismo masivo) con las jerarquías de caché de CPU.
  • Algunos se quejan de “compute” como sustantivo; otros señalan que ha sido común desde al menos los primeros servicios en la nube y la IA moderna.