diff --git a/docs/README.md b/docs/README.md index 84b0be5..3bd9fc1 100644 --- a/docs/README.md +++ b/docs/README.md @@ -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. diff --git a/docs/amd-gpus.md b/docs/amd-gpus.md new file mode 100644 index 0000000..a1a3426 --- /dev/null +++ b/docs/amd-gpus.md @@ -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.*