An Update on Apple M1/M2 GPU Drivers

Original Article ↗ Hacker News Discussion ↗

Open-source developers are reverse-engineering Apple’s M1/M2 GPU hardware to build Linux graphics drivers in Rust, exposing how much of the modern graphics stack must be emulated in software because Apple omits or redesigns legacy features like geometry shaders and standard page sizes. Commenters weigh the technical brilliance and sheer difficulty of this work against Apple’s closed, Metal-first design philosophy, asking whether community energy is better spent adapting to proprietary platforms or pushing for open standards and hardware. The thread also touches on how newer M3/M4 GPUs may require substantially different drivers, the real-world value of hardware ray tracing, and the long-term appeal of Apple laptops despite these constraints.

Driver work & technical challenges

  • Many commenters praise the GPU reverse‑engineering effort as extraordinarily complex, bordering on “magic,” and highlight how inscrutable driver and GPU math code can be, even for experienced developers.
  • There is admiration for the sustained focus on M1/M2 support instead of chasing only the newest chips.
  • Some are astonished how much “missing” hardware functionality is re‑implemented in software or via emulation, yet note that much of it targets legacy API features.

Apple GPU architecture (M1–M4)

  • M3 is described as a substantial architectural shift: dynamic caching (register file as cache), mesh shaders, ray‑tracing units, and different memory/register handling.
  • This likely requires significantly different drivers from M1/M2, though exact compatibility impacts remain unclear.
  • End‑user performance gains on newer chips are perceived as modest in raw GPU grunt, more incremental clocks than massive core changes.

Legacy features, tessellation & mesh/geometry shaders

  • Geometry shaders are widely portrayed as a design mistake: hard to implement efficiently, rarely useful, often slower than older techniques.
  • Mesh shaders, by contrast, are viewed as genuinely valuable but very hard to support, especially on mobile hardware.
  • Some discuss a large, difficult tessellation implementation ported into shader code, emphasizing how mathematically dense and under‑documented such components can be.

Ray tracing: gimmick or future standard?

  • Strong split:
    • Pro‑RT side: sees path tracing as the physically correct “gold standard” that can eventually simplify pipelines, reduce artist workload, and unify lighting; RT today is seen as early but inevitable.
    • Skeptical side: calls RT a marketing‑driven gimmick on current hardware, especially mobile‑class GPUs; notes huge performance costs, reliance on upscaling, and that many games show marginal visual gains.
  • Several argue it’s transformative only when games are designed for RT from the start; retrofits often look worse or barely better.

Rust, testing & CI constraints

  • The Linux GPU driver for Apple silicon is being written in Rust, with substantial effort going into safe abstractions over C DRM code.
  • There is discussion of tests: conformance suites for OpenGL/Vulkan exist and are run, but continuous integration is hampered by lack of affordable/hostable M3 hardware (e.g., Mac mini).

LWN subscriber links & ethics

  • Consensus: LWN’s “subscriber links” are explicitly meant to be shared; the paywall expires after a delay.
  • Sharing them on forums is seen as acceptable and even beneficial advertising, though overuse could threaten funding.

Gaming, Proton & Mac/ARM

  • Several discuss the possibility of Proton‑like layers on macOS or Linux-on-Mac, and ARM‑capable Proton builds.
  • Apple’s Game Porting Toolkit and DirectX‑to‑Metal translation are noted, but some see third‑party solutions (e.g., Vulkan drivers on Asahi, Wine‑based tools) as more user‑friendly.
  • There’s debate over whether Apple should natively support Vulkan; some think Apple’s refusal is purely strategic, not technical.

Openness, Apple’s ecosystem & device longevity

  • Multiple commenters criticize Apple’s closed hardware, non‑standard page sizes, and incomplete disclosure, arguing it imposes unnecessary burdens on open‑source developers and complicates Linux support.
  • Others reply that Apple optimizes purely for its own stack (Metal, macOS) and mainstream users, not for third‑party OSes; the hardware’s quality is precisely why people want Linux on it.
  • Long‑term device use is a major theme: many report MacBooks and iPhones lasting 7–10+ years, though some counter with similarly long‑lived ThinkPads and argue that modern Macs are hard/expensive to repair and unfriendly to Linux.

Value of Asahi‑style efforts

  • Most see the project as inspiring and technically important, both for enabling Linux on powerful hardware and as a proof‑of‑concept for open drivers on closed GPUs.
  • A minority consider it “pissing in the wind,” given Apple’s incentives and ongoing architectural churn, but others reject the idea that the “community” should be centrally redirected; individuals should pursue what interests them.