An Update on Apple M1/M2 GPU Drivers

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.