AMD's 22 year old GPUs are still getting updates

Original Article ↗ Hacker News Discussion ↗

Open-source graphics drivers are still being optimized for ATI/AMD GPUs from the early 2000s, underscoring how community-maintained software can dramatically outlast official vendor support. Commenters contrast this with AMD’s relatively short support window for newer architectures like Vega and Polaris, and with proprietary ecosystems such as Nvidia’s CUDA, where older hardware and APIs are dropped more aggressively. The thread broadens into a debate over mandatory open-sourcing of drivers and firmware, planned obsolescence, and whether regulation or competition is needed to keep hardware usable and environmentally sustainable for longer.

What’s Actually Being Updated

  • Several commenters note the title is misleading: the updates are to open-source Mesa drivers for ~22-year-old ATI/AMD GPUs, not official AMD releases.
  • The hardware was already supported; current work focuses on performance and feature improvements, largely by individual community contributors.

Experiences with Old and New GPUs

  • Many reminisce about early Radeon cards (e.g., 9700 Pro, X1000/X1800, old laptops) and classic games.
  • Some report modern Linux kernels or Mesa breaking support for ~10–20-year-old GPUs unless specific paths (e.g., EXA instead of Glamor) are used.
  • Others plan to test legacy GPUs (e.g., X1950 Pro) under current Linux stacks thanks to these driver improvements.

AMD vs Nvidia and Vendor Support

  • AMD is praised for publishing hardware specs, enabling good open drivers, and partially following open standards, especially compared to Nvidia.
  • At the same time, AMD is criticized for dropping or splitting support for relatively recent hardware (Polaris, Vega, ROCm on RX 580), even while such products are still sold.
  • Users report regressions in recent Windows drivers for older AMD GPUs (e.g., RX 580 + VR), needing to roll back to older driver branches.

Open-Sourcing Drivers and Firmware

  • Strong sentiment that drivers (and often firmware) should be mandated open source after hardware EOL, or even from day one.
  • Arguments for: longer hardware life, community maintenance, reduced e‑waste, avoidance of artificial limitations (printers, cameras, video recorders).
  • Counterpoints: IP/licensing entanglements, driver code as “secret sauce,” legal risk around patents/copyright, vendor fear of reduced sales and lawsuits.

Regulation, Environment, and Planned Obsolescence

  • Some advocate environmental and procurement standards (e.g., eco labels) to indirectly force openness and longevity.
  • Others describe industries where products still sold receive only token support, linking this to planned obsolescence and vertical integration of hardware + drivers.

Compute, ROCm, and ML Ecosystem

  • ROCm is nominally open source but seen as awkwardly developed; official support for older AMD GPUs is dropped quickly.
  • Community efforts (e.g., rusticl, KFD, distro packaging/CI) try to keep compute usable on older Radeon hardware.
  • In ML, commenters note rapid deprecation of older Nvidia architectures (e.g., Kepler), justified by fast-changing GPU instruction sets but frustrating for basic experimentation on older cards.