AMD's CDNA 3 Compute Architecture

Original Article ↗ Hacker News Discussion ↗

AMD’s split between its CDNA compute GPUs and RDNA gaming GPUs prompts debate over whether the company sacrificed a unified software ecosystem in pursuit of specialized hardware. Commenters contrast AMD’s fragmented, often fragile ROCm and OpenCL support with Nvidia’s long-term CUDA strategy, arguing that consistent tooling and backward compatibility—not raw FLOPS—won Nvidia the AI and HPC markets. Some see hope in recent ROCm support for high-end consumer Radeons, but many believe AMD’s late and inconsistent software focus has ceded a crucial decade of mindshare to Nvidia.

AMD GPU Architecture: CDNA vs RDNA

  • AMD split GPU development into CDNA (compute/HPC) and RDNA (graphics), evolving GCN into CDNA and reworking graphics into RDNA.
  • CDNA drops or minimizes graphics-focused units (e.g., render outputs), excels at compute, and powers multiple Top500 supercomputers.
  • RDNA is optimized for gaming: better raster performance, lower power and die size vs older GCN (e.g., RX 5700 XT vs Radeon VII) but weaker for compute-oriented features.
  • Some argue the split isolates compute and hurts mindshare; others say specialization was necessary to be competitive in gaming and HPC.

ROCm and Software Ecosystem

  • ROCm currently ships GPU machine code per-architecture instead of a PTX-like bytecode, forcing architecture-specific binaries for all libraries and inflating package size.
  • Small ISA variants (e.g., gfx1030 vs gfx1031) complicate support; workarounds and longer-term “family ISA” approaches exist but are slow to arrive.
  • Many posters describe ROCm as fragile: narrow GPU/OS support, painful installs, segfaulting demos, and effectively abandoned issue trackers.
  • Some users report success on unsupported consumer cards with minor environment hacks, but this is unofficial and brittle.

Comparison with NVIDIA and CUDA

  • CUDA’s consistency across generations and products is seen as NVIDIA’s main moat: same API on consumer and data center GPUs, with backward-compatible PTX.
  • NVIDIA is portrayed as “software-first,” investing early (since CUDA 2007) and continuously in tools, docs, and libraries.
  • AMD is criticized for abandoning past APIs (e.g., OpenCL implementations), frequently resetting ecosystems, and rotating ROCm support, leading to mistrust.
  • There is debate over raw FLOPs vs real-world performance; tensor cores and specialized matrix units make simple TFLOP comparisons misleading.

Open Standards and Alternative Stacks

  • OpenCL is viewed as a “betrayed” standard: stuck at C99, poorly supported by AMD/Intel, and ignored by NVIDIA.
  • SYCL/oneAPI are mentioned as more open, with multi-vendor governance; Mesa/RustiCL and Vulkan/D3D backends exist but are immature or niche.
  • Some call for a cross-vendor GPU IR akin to PTX/MSIL; others note SPIR-V complications and differences between Vulkan/OpenCL models.

Consumer & Hobbyist Compute Path

  • Lack of robust, official compute support on AMD consumer GPUs (especially APUs and older cards) is seen as a major lost opportunity for seeding developers.
  • Several argue that students and hobbyists on consumer hardware become tomorrow’s HPC buyers; neglecting them ceded this funnel to CUDA and, increasingly, Apple/Metal.

Architecture & Terminology Side Threads

  • Discussion touches on VLIW history (Itanium, DSPs, older AMD GPUs), dual-issue trends in modern GPUs, and diminishing returns of wide in-order parallelism.
  • GPU memory strategies (large register files, shared/local memory, big caches, latency hiding via massive parallelism) are contrasted with CPU cache hierarchies.
  • Some complain about “compute” as a noun; others note it has been common since at least early cloud services and modern AI.