docs: amd-gpus.md — RDNA2 display-driver feasibility, the AMD companion survey

2026-07-22 12:25:07 +01:00
parent e63d6ef5ef
commit cacbacd76b
2 changed files with 347 additions and 2 deletions
@@ -94,9 +94,10 @@ rather than restate it. Roughly in the order things happen at runtime:
    scanout a pluggable backend — GOP floor + a native virtio-gpu driver, hot-attached, with
    runtime mode-set, EDID, fenced vsync presents, and restart re-attach:
    [display-v2.md](display-v2.md), plan [display-v2-plan.md](display-v2-plan.md). Looking
-    further out, two research snapshots survey what a *native* driver for real GPU silicon
+    further out, three research snapshots survey what a *native* driver for real GPU silicon
    would take as another `.scanout` backend: [nvidia-gpus.md](nvidia-gpus.md) (RTX 3060 /
-    Ampere) and [intel-igpu.md](intel-igpu.md) (Intel iGPU).
+    Ampere), [amd-gpus.md](amd-gpus.md) (RX 6600 / RDNA2), and [intel-igpu.md](intel-igpu.md)
    (Intel iGPU).
 23. **[halting.md](halting.md) — halting.** Why a kernel can't just "exit", and
    how `while (true) hlt` parks the CPU safely once there's nothing left to do.
@@ -0,0 +1,344 @@
 # Native AMD GPU support — feasibility and roadmap
 **Status: research snapshot, not implemented.** This records what a *minimal, display-only*
 native driver for a real discrete AMD GPU — specifically an **RX 6600-class card (Navi 23,
 RDNA2, DCN 3.0.2)**, the market analog of the RTX 3060 — would take, and how it slots into
 danos's pluggable scanout architecture. It is a survey of primary sources (the Linux
 [amdgpu Display Core](https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/amd/display)
 driver and its [kernel documentation](https://docs.kernel.org/gpu/amdgpu/display/index.html),
 the AtomBIOS interpreter in
 [drivers/gpu/drm/amd](https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/amd),
 linux-firmware's `LICENSE.amdgpu`, and Haiku's
 [radeon_hd](https://github.com/haiku/haiku/tree/master/src/add-ons/kernel/drivers/graphics/radeon_hd)),
 not an implementation. It completes the trilogy with [nvidia-gpus.md](nvidia-gpus.md) and
 [intel-igpu.md](intel-igpu.md) and should be read against both — AMD lands *between* them:
 NVIDIA-class discrete-card mechanics, but Intel-class (better, in one way) reference material.
 Read [display.md](display.md) and [display-v2.md](display-v2.md) first — this doc assumes the
 v2 model where scanout is a **pluggable backend** and a native driver is just another `.scanout`
 service (like the virtio-gpu one), announcing to the compositor over `attach_scanout`.
 ## TL;DR
 - **AMD's decisive advantage is that the vendor's own display driver is the register manual, and
  it's MIT-licensed.** The entire Display Core (DC) — hardware sequencer, per-block code for
  OTG/OPTC, HUBP, DPP, MPC, DIO/link encoders, plus the `asic_reg` register headers — ships in
  the Linux tree under MIT/X11, deliberately written OS-agnostic because AMD shares it across
  operating systems. You can study it, port it, even copy from it into a danos driver without
  license contamination. NVIDIA has no analog (nouveau is GPL); Intel has PRM prose but you
  still write the code yourself.
 - **The firmware wall is one small blob, not a GSP.** The only display-side firmware the Linux
  driver hard-requires is **DMCUB** (the display microcontroller), and only on **DCN 2.1
  through 4.x** — which includes Navi 23. It is redistributable from linux-firmware, and it is
  a display helper, not a full-card resource manager: on DCN 3.0.x, hardware init
  (`dcn30_init_hw`) is **host-driven direct register programming** — the only DMUB call in it
  is a capability query. All DCE generations, DCN 1.0 (Raven), and DCN 2.0 (Navi 10/12/14) run
  display with **no display firmware at all**.
 - **Whether the *silicon* (vs. the Linux driver) needs DMCUB for a bare GOP-inheriting modeset
  is unproven** — Linux fails init with `-EINVAL` if the blob is missing on a DMUB ASIC, but
  what it's *used for* at minimum scope (vs. PSR/ABM/offloaded DP link training) isn't
  documented. The safe plan ships the blob; it's legally and practically cheap to do so.
 - **Programming model is direct MMIO, not channel DMA.** DCN mode-set is ordered register-write
  sequences (the DC "hardware sequencer") against named, header-documented registers — no
  pushbuffers, no method streams, no RAMHT, no supervisor-interrupt handshake. This deletes the
  hardest structural layer of the NVIDIA path.
 - **Scanout is VRAM-only on discrete cards** — the claim that DCN can scan out of GTT/system
  memory was checked and *refuted* for dGPUs (Linux allows GTT scanout only on select APUs). So
  a small VRAM allocator + BAR CPU mapping is required, same as NVIDIA. Pitch-linear surfaces
  are supported; no DCC/tiling needed.
 - **danos's GOP boot helps here too, with a caveat.** DC explicitly models taking over a
  VBIOS/GOP-lit pipe (`dc_validate_boot_timing` reads back live DIG/OTG/pixel-clock state), so
  "repoint the surface on the running pipe" is demonstrably hardware-feasible — but Linux's
  seamless-boot path is **eDP-only and default-off on discrete cards**, so plan on a full
  self-owned modeset (including DP retrain) right after first light rather than living on the
  inherited link.
 - **AMD has real non-Linux prior art — but only for the old hardware.** Haiku's MIT `radeon_hd`
  mode-sets by executing VBIOS **AtomBIOS command tables** through AMD's own MIT interpreter;
  its compiled-in ceiling is **DCE 8.5 (Hawaii, ~2013)** — every Polaris/Vega/Navi entry sits
  in a `#if 0` block. There is zero non-Linux DCN precedent; a danos DCN driver would be first.
 - **Effort tier ≈ high-3 to 4** for a native DCN 3.0.x display-only driver on Navi 23 — the raw
  register surface is GA106-class (tier 4), but the MIT vendor reference, the one-blob firmware
  wall, and the absence of channel-DMA plumbing pull real risk out. The AtomBIOS-interpreter
  route is tier ≈ 3 but dead-ends at pre-2016 silicon.
 - **Recommendation:** the same sober conclusion as the other two docs — GOP already gives
  native-res scanout for zero code — but if danos ever does drive real discrete silicon
  natively, **an RDNA2 card is the best target of the three**: modern, mainstream, in-warranty
  hardware with a legally clean, vendor-authored reference. That combination exists nowhere
  else.
 ## The firmware wall (a fence, next to NVIDIA's wall)
 AMD GPUs carry a zoo of firmware: PSP (security processor), SMU (power/clock management), CP/RLC
 (graphics), SDMA, VCN (media) — and, on the display side, DMCU (legacy) then **DMCUB**
 ("Display Micro-Controller Unit, version B"), a per-generation blob in linux-firmware
 (`navi23_dmcub.bin` etc.). The display-only question is: which of these does a scanout driver
 actually need?
 The Linux answer is precise and readable in
 [`amdgpu_dm.c`](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c):
 `dm_init_microcode()` switches on the display IP version — **DCN 2.1 (Renoir) through DCN
 3.0.x / 3.1.x / 3.2 / 3.5 / 4.x** request a DMCUB blob as `AMDGPU_UCODE_REQUIRED`, and
 `dm_dmub_hw_init()` fails driver init with `-EINVAL` if it's absent. Everything earlier — **all
 of DCE (Southern Islands through Vega), DCN 1.0 (Raven), and DCN 2.0 (Navi 10/12/14)** — hits
 the `default:` case, `dmub_srv` stays NULL, and display runs with no display firmware at all
 ([kernel display-manager doc](https://docs.kernel.org/6.2/gpu/amdgpu/display/display-manager.html)).
 Two nuances survive verification:
 - **The requirement is Linux-driver enforcement backed by real functional need, and it's
  version-sensitive.** AMD force-switched all Renoir ASICs to DMUB to fix a USB-C/resume bug
  (kernel commit `652de07addd2`, "with new dmub f/w dmcu is superseded"), which regressed users
  on old blobs and had to be patched with explicit `dmcub_fw_version` gating (`91adec9e0709`).
  What DMUB is *used for* varies with blob version. Ship a current blob.
 - **DMCUB is an architectural fixture, not a bolt-on** — the DCN hardware itself contains a DMU
  block housing the microcontroller
  ([DCN overview](https://docs.kernel.org/gpu/amdgpu/display/dcn-overview.html)) — but it is
  **not a mediator of the programming model** on DCN 3.0: `dcn30_init_hw()` initializes clocks,
  disables power gating, and powers up link encoders via direct register writes; its sole DMUB
  interaction is `dc_dmub_srv_query_caps_cmd`. Firmware-*assisted* PHY/link bring-up appears
  from **DCN 3.1** onward — one more reason to target 3.0.x. Features like PSR and ABM are
  DMUB-offloaded on all generations; a minimal driver simply doesn't enable them.
 **Contrast with NVIDIA's GSP:** the GSP is a full resource manager with a signed multi-stage
 boot chain and a firmware ABI that breaks every driver release. DMCUB is a display helper blob
 you copy onto the boot image once, load into a reserved buffer, and mostly ignore. There is no
 signature fuse-matching, no WPR carve-out, no RPC-only register access. The one genuinely open
 question — whether a GOP-inheriting minimal modeset could skip DMCUB entirely on DCN 3.0.2 —
 doesn't need answering, because shipping the blob costs nothing (see [Licensing](#licensing)).
 **PSP/SMU remain the flagged risk.** Nothing display-only touches CP/RLC/SDMA (those gate the
 graphics rings, exactly like NVIDIA's PGRAPH — irrelevant here). But `dcn30_init_hw` calls into
 the clock manager, and on discrete cards the clock manager may message the SMU to change display
 clocks (DISPCLK/DPPCLK). Whether inherited GOP boot clocks suffice for a same-or-lower mode —
 avoiding SMU (and hence PSP firmware-load) entirely — is the largest unverified assumption in
 the milestone list below. The survey produced no confirmed claim either way.
 ## The display engine landscape
 Two eras, one boundary that matters:
 | Generation | Display IP | Cards | Display firmware | Route |
 |---|---|---|---|---|
 | GCN 1–4 (SI→Polaris) | DCE 6/8/10/11 | HD 7000 → RX 580 | none | AtomBIOS tables or direct DCE registers |
 | Vega / Raven | DCE 12 / DCN 1.0 | Vega 56/64, APUs | none | DC code (first DCN) |
 | Navi 1x (RDNA1) | DCN 2.0 | RX 5500–5700 | none | DC code |
 | Renoir APU | DCN 2.1 | 4000-series APUs | **DMCUB required** | DC code |
 | **Navi 2x (RDNA2)** | **DCN 3.0.x** | **RX 6600–6900** | **DMCUB required** | **DC code, host-driven init** |
 | RDNA3/RDNA4+ | DCN 3.1+/3.2/3.5/4.x | RX 7000/9000 | DMCUB required, fw-assisted PHY | DC code, more DMUB offload |
 The best modern first-pixel target is **DCN 3.0.x**: it has the full MIT block stack from the
 June 2020 Sienna Cichlid patch series (207 patches, Linux 5.9; Navi 23 reuses the dcn30
 sequencer), host-driven hardware init, and sits *before* the DCN 3.1 shift toward
 firmware-assisted link management. Older DCE cards are even simpler (no firmware at all, plus
 the AtomBIOS escape hatch) but are 2013–2016 hardware; newer DCN 3.5/4.x pushes more into DMUB.
 The DCN pipe, in one line each (the vocabulary the DC code speaks —
 [programming model](https://docs.kernel.org/next/gpu/amdgpu/display/programming-model-dcn.html)):
 **HUBP** fetches and unpacks the surface from memory (this is where the scanout address and
 pitch live), **DPP** scales/converts colors, **MPC** blends planes (bypassable for one plane),
 **OPP** packs output, **OTG/OPTC** generates raster timings (the CRTC), and the **DIO** block's
 DIG encoders + PHY drive the connector. Mode-set is the DC *hardware sequencer* walking these
 blocks with ordered register writes — plain MMIO with polling, no pushbuffer channels, no
 supervisor interrupts. Structurally this is Intel-shaped, not NVIDIA-shaped.
 ## Two routes: AtomBIOS interpreter vs. native DC-derived registers
 **AtomBIOS** is AMD's VBIOS bytecode: every card's ROM carries *data tables* (connector
 topology, clock limits — the DCB equivalent) and *command tables* (`SetPixelClock`,
 `SetCRTC_Timing`, `EnableCRTC`, DIG encoder/transmitter control), executed by a small
 interpreter the driver embeds (`atom.c`, ~1.5k lines). The classic radeon driver and Haiku's
 `radeon_hd` mode-set this way: parse the tables, execute them, and the VBIOS does the
 register-level work for you — inherently per-board correct, since the tables come from the
 card's own ROM.
 - **Where it's proven:** through DCE 8.5 (Haiku's ceiling, below) and in Linux's pre-DC code
  through Polaris (DCE 11.2). AMD's interpreter itself is MIT (Haiku ships AMD's own
  `atom.cpp`, "Copyright 2008 Advanced Micro Devices").
 - **Where it's unproven:** DCN. amdgpu's DC still *uses* AtomBIOS for init sub-steps
  (`bios_golden_init` in `dcn30_init_hw` executes host-interpreted tables) and reads the data
  tables for connector topology — but nobody drives a full DCN modeset from command tables, and
  whether RDNA2 VBIOSes still carry a complete modeset path or vestigial init-only tables is an
  open question no source answers. Do not bet on it.
 **The native route** is: port the relevant slice of DC. Not wholesale — in-tree DC has
 accumulated Linux-isms (kernel-FPU guards around DML, the bandwidth-calculation library, which a
 single-plane fixed-mode driver can largely sidestep) — but the DC core is *designed* to be
 retargeted: the kernel docs state outright that DC "is shared with other OSes" and holds the
 OS-agnostic hardware programming behind a `dm_services` shim (register access, memory, delays,
 firmware loading). Dave Airlie initially rejected the DAL/DC merge in 2016 *because* it was
 AMD's cross-OS codebase — hostile-witness confirmation that this exact code runs outside Linux.
 Reimplement the shim in Zig, and the dcn30 sequences sit on top.
 ## The memory floor
 Same shape as NVIDIA's, and the survey *hardened* one assumption:
 - **VRAM-only scanout on discrete cards.** The documented DCN fetch path is VRAM → Data Fabric
  (SDP) → DCHUB → HUBP; the claim that display buffers can live in GTT/system memory was
  refuted for dGPUs in verification — Linux permits GTT scanout only on select APUs. The NVIDIA
  doc's "maybe sysmem ctxdma?" hope has a firm *no* here. Budget for a small VRAM allocator.
 - **Pitch-linear is fine.** HUBP programs a surface address + pitch; linear (untiled, no DCC)
  surfaces are first-class for scanout. No tiling math.
 - **CPU access via the VRAM BAR.** Compositing writes go through the PCI VRAM aperture;
  resizable BAR helps but isn't needed — one pitch-linear surface fits comfortably in a
  fixed 256 MB small-BAR window.
 - **No GPU VMM.** Display addresses are physical VRAM addresses programmed into HUBP; no page
  tables, no GEM/TTM, no eviction.
 **Net:** (1) a contiguous aligned VRAM allocator, (2) a BAR CPU mapping, (3) a small reserved
 buffer for the DMCUB firmware regions. That's the whole memory story.
 ## Inheriting GOP state
 danos's GOP boot pays off again, with sharper edges than on NVIDIA:
 - **DC models pipe takeover explicitly.** `dc_validate_boot_timing()`
  ([dc.c](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/dc/core/dc.c))
  reads back *live* hardware — `is_dig_enabled` on the link encoder, OTG timing registers,
  pixel clock within tolerance — and keeps the VBIOS/GOP-lit pipe running until first flip.
  This is a vendor-blessed recipe for milestone 2 below: the exact register set that tells you
  which pipe is alive and how it's configured.
 - **But Linux's seamless path is eDP-only and APU-gated.** The code comment is blunt: "Support
  seamless boot on EDP displays only", and the enabling check requires an APU with DCN ≥ 3.0
  unless forced with `amdgpu.seamless=1`. On a discrete RX 6600 with DP/HDMI, Linux does a full
  modeset at takeover. Read that as a warning, not a prohibition: repointing HUBP at your own
  surface on the live pipe should still work (the readback code proves the state is
  inspectable), but plan the full self-owned modeset — **including DP retraining** — as the
  immediate next step, not a someday.
 - **No supervisor handshake exists to re-learn.** The NVIDIA doc's SV1/SV2/SV3 open question has
  no AMD counterpart; commit sequencing is ordered register writes + vblank/lock waits in the
  hwseq, all visible in MIT source.
 ## Licensing
 The inverse of the NVIDIA situation, and the single strongest argument for AMD:
 - **The reference code is MIT.** `amdgpu_dm.c` carries `SPDX-License-Identifier: MIT`;
  `dc/core/dc.c` and `dmub_srv.h` carry the full X11-style grant (use, copy, modify, merge,
  publish, distribute, sell). The `asic_reg` register headers ship under the same terms. One
  diligence note: SPDX tagging isn't uniform across the tree, so header-check each file before
  copying from it — but no GPL files are known inside `dc/`. Where nouveau forces a
  GPL-or-clean-room choice, here the *easy technical path and the permissive path are the same
  path*.
 - **Firmware redistribution is a solved problem.** linux-firmware's `LICENSE.amdgpu` grants
  anyone a royalty-free right to reproduce and distribute the blobs, binary-only, with the
  license text attached — no OSI-license gate like NVIDIA's, no AMD agreement needed. danos can
  ship `navi23_dmcub.bin` (and PSP/SMU blobs if ever needed) on its boot image today. The same
  license **prohibits reverse-engineering the blobs** — all programming knowledge must come
  from the MIT source, never from blob disassembly. (VBIOS images aren't in linux-firmware;
  they're read from the card's own ROM, as Haiku does.)
 - **Prose register docs are a DCE-era artifact.** AMD's classic X.Org-hosted PDFs cover the old
  families — and the famous `R6xx_3D_Registers.pdf` turns out to be 3D-only (verified: zero
  display content; the display material lives in the separate per-ASIC Register Reference
  Guides). For DCN there is **no prose display spec at all**: the MIT DC source plus the
  `asic_reg` headers *are* the register manual. Plan accordingly.
 ## Prior art
 AMD, unlike NVIDIA, has genuine working non-Linux precedent — with a hard generational ceiling:
 - **Haiku `radeon_hd`** (MIT, still in the tree): a real, shipping, from-scratch display driver
  that executes AtomBIOS command tables via AMD's own MIT interpreter. Verified ceiling:
  the last *enabled* device entry is **Hawaii (DCE 8.5, 0x67be)**; everything newer —
  Tonga/Fiji, Carrizo/Polaris, Vega/Raven, and every Navi/RDNA2 entry up to the RX 6900 XT —
  sits inside one `#if 0 /* disabled for R1/beta5 */` block under the comment "WARN: DCE
  versions below here get sketchy."
 - **AmigaOS/MorphOS RadeonHD drivers** (hdrlab): commercial non-Linux Radeon display drivers,
  again for the DCE era.
 - **FreeBSD** `drm-kmod`: a port of Linux amdgpu (DC and all), not independent prior art — but
  proof the DC codebase transplants.
 **Nobody has driven DCN outside Linux-derived code.** A danos DCN 3.0.x driver would be a
 first — but a first with the vendor's MIT code as its map, which is a different proposition
 from nouveau-as-only-reference.
 ## Alternatives
 | Option | What you get | The tradeoff |
 |---|---|---|
 | **Stay on GOP** (working today) | Native-res scanout, zero GPU code/firmware/maintenance | Resolution frozen at ExitBootServices; no runtime mode change, no hardware vsync, no multihead |
 | **AtomBIOS interpreter on an old DCE card** | Proven end-to-end (Haiku); interpreter is small + MIT; board-correct by construction | 2013–2016 hardware ceiling; tier ≈ 3; teaches AtomBIOS, not modern DCN |
 | **Native DCN 3.0.x on RX 6600** (this doc) | Runtime modeset, vsync, multihead on modern silicon; MIT vendor reference; one redistributable blob | Tier ≈ high-3–4; SMU/clock question open; no non-Linux precedent |
 | **Port DC wholesale** (reimplement `dm_services`) | Vendor-maintained sequences verbatim; designed-for-porting seam | Big codebase to carry (DML, abstractions); Linux-isms to shear off; overkill for one plane |
 | **RDNA3+/DCN 3.5+** | Newer cards | More DMUB offload (fw-assisted PHY from DCN 3.1); strictly harder than 3.0.x for no display-only gain |
 ## "First light" milestones (native DCN 3.0.x path)
 Framed as a danos `.scanout` service, inheriting the GOP-initialized display:
 1. **PCI/BAR bring-up** — enumerate Navi 23, map the register BAR and the VRAM BAR via danos
   MMIO grants; prove the pipe is GOP-live by writing pixels into the *existing* GOP
   framebuffer through the VRAM BAR.
 2. **Read back the live pipe** — port the `dc_validate_boot_timing` register set: which OTG is
   running, its timings, which DIG/link encoder is enabled, current HUBP surface address/pitch.
   This is pure reads — zero risk, high information.
 3. **Repoint the surface** — allocate a danos-owned pitch-linear VRAM surface, program the HUBP
   surface address/pitch on the live pipe at vblank. First self-owned pixel with **no modeset,
   no firmware, no clock changes**.
 4. **DMCUB bring-up** — load `navi23_dmcub.bin` (redistributed per `LICENSE.amdgpu`) into its
   reserved regions, minimal `dmub_srv` init, verify the caps query answers.
 5. **Full owned modeset** — port the dcn30 hwseq slice: OTG timing programming, MPC bypass
   (single plane), DIG/PHY enable, **DP link retrain** (or start on HDMI to defer it, exactly
   as the NVIDIA doc advises). This is where the SMU/clock question lands — first attempt:
   reuse inherited boot clocks for a same-or-lower mode.
 6. **EDID** — AUX (DP) / DDC (HDMI) over the DCN AUX engine registers; parse and build the mode
   list; connector topology from the VBIOS AtomBIOS data tables.
 7. **Wire into the compositor** — `attach_scanout`, vsync from the vblank/pageflip interrupt,
   then multihead.
 Keep the GOP backend as the fallback the whole way — a stall at any step still leaves danos with
 a working display (the resilience v2 already provides via re-attach).
 ## Reading list
 **The DC core (MIT — the register manual for DCN):**
 - `drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c` — hardware init + the modeset
  sequencer for the target generation (host-driven; one DMUB caps query).
 - `dc/dcn30/` + `dc/dcn302/` blocks: `dcn30_hubp.c` (surface address/pitch — milestone 3),
  `dcn30_optc.c` (OTG timings), `dcn30_dio_link_encoder.c` (DIG/PHY), `dcn30_mpc.c` (bypass),
  `clk_mgr/dcn30/` (the SMU question, read before milestone 5).
 - `dc/core/dc.c` — `dc_validate_boot_timing()`: the GOP-takeover readback recipe.
 - `asic_reg/dcn/dcn_3_0_0_{offset,sh_mask}.h` — every register name and bitfield.
 - `dmub/` (`dmub_srv.h`, `src/dmub_dcn30.c`) — firmware regions + bring-up for milestone 4.
 **The Linux glue (for logic, not porting):**
 [`amdgpu_dm.c`](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c)
 — `dm_init_microcode` / `dm_dmub_hw_init` (the firmware-wall switch), seamless-boot gating.
 **Kernel docs (read first):**
 [DCN overview](https://docs.kernel.org/gpu/amdgpu/display/dcn-overview.html) (the block diagram
 + VRAM→DF→DCHUB fetch path) ·
 [DC programming model](https://docs.kernel.org/next/gpu/amdgpu/display/programming-model-dcn.html)
 (dc_plane/dc_stream/dc_link objects, hwseq, block APIs) ·
 [display manager](https://docs.kernel.org/6.2/gpu/amdgpu/display/display-manager.html).
 **AtomBIOS:** `drivers/gpu/drm/amd/amdgpu/atom.c` (the interpreter), `atombios.h` (table
 formats), [osdev AMD AtomBIOS](https://wiki.osdev.org/AMD_Atombios) (hobby-OS orientation),
 Haiku [`radeon_hd`](https://github.com/haiku/haiku/tree/master/src/add-ons/kernel/drivers/graphics/radeon_hd)
 (a complete worked example, MIT, through DCE 8.5).
 **Licensing:** linux-firmware
 [`LICENSE.amdgpu`](https://github.com/endlessm/linux-firmware/blob/master/LICENSE.amdgpu);
 DCE-era prose specs at [x.org/docs/AMD](https://www.x.org/docs/AMD/) (Register Reference
 Guides — display; note `R6xx_3D_Registers.pdf` is 3D-only).
 ## Open questions (unresolved by the survey)
 - **Does DCN 3.0.2 silicon need DMCUB for a bare inherit-and-modeset path**, or only for
  PSR/ABM/offloaded features? (Moot if the blob is shipped regardless — but it decides whether
  milestone 3 can precede milestone 4.)
 - **Can a display-only driver avoid PSP and SMU entirely** by inheriting GOP boot clocks — what
  does the dcn30 clock manager actually require from SMU messaging on Navi 23 for a
  same-or-lower mode? *The largest open risk in the plan.*
 - **Do RDNA2 VBIOS command tables still carry a complete modeset path**, or are they vestigial
  init-only tables? (Would open a Haiku-style route on modern cards; no source answers it.)
 - **Is the DCN 3.0 AUX/DDC engine and DP retrain fully host-drivable without DMUB**, as
  `dcn30_hwseq` implies?
 - Exact HUBP surface alignment/pitch constraints for linear scanout on Navi 23 (in the headers;
  not captured verbatim in the survey).
 ---
 *Research snapshot (2026-07); findings pinned to Linux master and Haiku master as of the survey
 date. DMUB coverage only grows with new DCN generations — re-verify the firmware-wall switch in
 `amdgpu_dm.c` against current source before building.*