# AMDGPU Full Integration Plan — linux-kpi → Mesa → Wayland

**Created:** 2026-05-30 · **Updated:** 2026-05-31 (636 errors — 96.8% reduced from 19,652. 181 headers, 0 fatals. atomic_long_t + bitmap functions added.)

**Milestones achieved:**
- Phase 0: ✅ Complete — amdgpu-source Linux 7.1 (970 C files)
- Phase 1: ✅ Complete — 180 linux-kpi headers, 0 fatal errors across all 12 core files
- Phase 2: 🔄 926 non-fatal errors (95.3% reduced from 19,652 peak)

**Milestones achieved:**
- Phase 0: ✅ Complete — amdgpu-source Linux 7.1 (970 C files)
- Phase 1: ✅ Complete — 177 linux-kpi headers, 0 fatal "file not found" errors across all 12 core files
- Phase 2: 🔄 In progress — ~1,700 non-fatal errors (92% reduced from 19,652 peak)

**Quality fixes delivered:**
- `-std=gnu11` in recipe CFLAGS (matches Linux 7.1 build standard)
- `__UNIQUE_ID` / `__PASTE` macro infrastructure in compiler.h
- `auto → __auto_type` mapping for C23 compatibility
- `typeof_member` / `typeof_unqual` for cleanup.h lock guard macros
- Proper `linux/cleanup.h` replacement (no auto/typeof dependency)
- Sparse annotations as no-ops (`__acquires`/`__releases`)
- `IS_ENABLED(CONFIG_*)` system in kconfig.h — eliminated ~17,800 errors
- Type system: `__s8`/`__s16`/`umode_t`/`fmode_t`/`BITS_PER_LONG`/`typeof()`/`rcuref_t`/`initcall_entry_t`/`locale_t`
- `<stdio.h>` removed from kernel.h (POSIX type pollution fix)
- `bitops.h → bitmap.h` include chain for DECLARE_BITMAP visibility
- Strategy: `-I${TOP_INC}` (real Linux 7.1 DRM headers) + linux-kpi shims blocking problematic imported headers

**Remaining 1,700 errors** are deep type/struct incompleteness in the imported include tree: `FILE` (54), `nodemask_t` (40), `__gnuc_va_list` (12), `__extension__` (9), `__attribute__` parse issues (6). These require either:
1. More linux-kpi shims to override problematic imported headers
2. Stub headers for `asm/` and `uapi/` chains that the imported tree expects
3. Or accepting that the imported `include/linux/` tree is too deep for full compatibility
**Authority:** This document is the canonical execution plan for full AMD GPU enablement on Red Bear OS through linux-kpi, covering kernel driver compilation, Mesa integration, and Wayland/KWin compositing.
**Position in doc set:** Beneath `CONSOLE-TO-KDE-DESKTOP-PLAN.md` and `DRM-MODERNIZATION-EXECUTION-PLAN.md` (Workstream B — AMD track).

## Executive Summary

| Component | Current State | Target State |
|---|---|---|
| **linux-kpi** | 148 C headers (+109 from original 39). Complete DRM KMS framework, TTM, core Linux subsystem shims. DRM atomic helpers declared. bitops/bitmap/DECLARE_BITMAP working. UAPI types (__u32/__u64). | Full Linux kernel API surface needed by amdgpu. Estimated +20-40 more headers + DRM atomic helper implementations. |
| **amdgpu kernel driver** | 970 C files imported (Linux 7.1). 12 core files compile through linux-kpi with 0 fatal errors. 280-1540 non-fatal errors per file (struct field + implicit decl). | 970 files compiled through linux-kpi, producing functional `libamdgpu_dc_redox.so`. |
| **libdrm amdgpu** | 12 files compiled via meson (`-Damdgpu=enabled`). DRM ioctl bridge patches applied. | Full libdrm_amdgpu with BO management, CS submission, VM management, GPU info queries — all through redox-drm scheme. |
| **Mesa radeonsi** | Not compiled (`-Dgallium-drivers` excludes radeonsi). | Cross-compiled for Redox target, linked against libdrm_amdgpu, rendering through redox-drm scheme. |
| **Mesa RADV** | Not compiled (`-Dvulkan-drivers=swrast` only). | Cross-compiled for Redox target. Deferred to Phase 4. |
| **Wayland/KWin** | DRM master via `/scheme/drm/card0`. Intel display path wired. AMD path uses synthetic EDID. | AMD display registered as DRM master through redox-drm. Atomic modeset, page flip, GBM buffer allocation via radeonsi. |
| **Hardware validation** | None. | Real AMD GPU output proven on at least one Navi/RDNA generation. |

**Total estimated effort**: 24–40 weeks with AMD GPU hardware access.
**Critical path**: linux-kpi gap filling → amdgpu core compilation → display output proof → Mesa radeonsi → KWin compositing.

---

## 1. Existing Infrastructure Assessment

### 1.1 linux-kpi Rust Implementation (7,464 lines)

The linux-kpi Rust crate provides real implementations (not stubs) for all major Linux kernel subsystems needed by GPU drivers:

| Module | Lines | Coverage |
|---|---|---|
| `pci.rs` | 777 | Full PCI: device enumeration via `enumerate_pci_all()`, BAR mapping via `/scheme/memory/physical`, MSI/MSI-X allocation, config space read/write, resource management |
| `irq.rs` | 228 | Full IRQ: threaded handler dispatch, masking, cancel, per-IRQ table with `scheme:irq` backed file descriptors |
| `dma.rs` | 434 | Full DMA: `virt_to_phys` via `/scheme/memory/translation`, DMA pools, GFP_DMA32 with retry, boundary-crossing detection, coherent allocation |
| `memory.rs` | 271 | Full memory: `kmalloc`/`kfree`/`vmalloc`/`vfree`/`krealloc`, GFP_DMA32 tracking with retries for sub-4GB allocations, allocation tracker |
| `firmware.rs` | 277 | Firmware: `request_firmware` via `/scheme/firmware/`, `release_firmware`, firmware cache |
| `workqueue.rs` | 372 | Workqueues: `schedule_work`, `schedule_delayed_work`, `flush_workqueue`, `cancel_work_sync`, threaded worker pool |
| `timer.rs` | 424 | Timers: `mod_timer`, `del_timer`, `del_timer_sync`, `setup_timer`, `msleep`/`udelay`/`mdelay`, jiffies tracking |
| `wait.rs` | 318 | Wait/completion: `init_completion`, `wait_for_completion`, `wait_for_completion_timeout`, `complete`, `reinit_completion` |
| `sync.rs` | 416 | Synchronization: `spin_lock`/`unlock`, `mutex_lock`/`unlock`, `atomic_read`/`set`/`inc`/`dec`/`cmpxchg`, `rcu_read_lock`/`unlock` stubs |
| `drm_shim.rs` | 374 | DRM shim: connector, CRTC, encoder, framebuffer structs, `drm_dev_register`, `drm_mode_config_init`, `drm_connector_init`, `drm_crtc_init_with_planes` |
| `io.rs` | 191 | I/O: `ioremap` via `/scheme/memory/physical` with `mmap`, `readl`/`writel`/`readb`/`writeb` via volatile pointers, `pci_iomap` |
| `idr.rs` | 243 | IDR: `idr_alloc`, `idr_find`, `idr_remove`, `idr_for_each_entry` |
| `list.rs` | 197 | Lists: `list_add`, `list_del`, `list_empty`, `list_for_each`, `list_for_each_entry` |
| `device.rs` | 155 | Device model: `struct device`, `dev_get_drvdata`, `dev_set_drvdata`, `dev_err`/`dev_warn`/`dev_info` logging |
| `net.rs` | 809 | Networking: `netdev_alloc`, `alloc_etherdev`, `register_netdev`, `sk_buff`, NAPI polling |
| `wireless.rs` | 1,002 | Wireless: `wiphy`/`ieee80211_hw` allocation, `wiphy_register`, `cfg80211_*` operations |
| `mac80211.rs` | 959 | mac80211: `ieee80211_register_hw`, `ieee80211_rx`, `ieee80211_tx`, `ieee80211_scan_*` |

**Key observation**: The linux-kpi already implements the infrastructure that the amdgpu C driver would call through C FFI. The C headers in `c_headers/` declare these functions, and the Rust implementations provide the runtime behavior. This is NOT a stub layer — it's a functional Linux kernel compatibility runtime.

### 1.2 C Header Compatibility Layer (39 headers)

The `c_headers/` directory provides `#include`-compatible declarations for the Linux kernel API. When the amdgpu C source is compiled with `-I${LINUX_KPI}`, it sees Linux kernel headers that resolve to the Rust implementations at link time.

### 1.3 libdrm amdgpu (12 files compiled)

The libdrm amdgpu backend compiles via meson with `-Damdgpu=enabled`. It provides the userspace side:
- BO (Buffer Object) allocation/management (`amdgpu_bo.c`)
- Command submission (`amdgpu_cs.c`)  
- VM management (`amdgpu_vm.c`, `amdgpu_vamgr.c`)
- GPU info queries (`amdgpu_gpu_info.c`, `amdgpu_asic_id.c`)
- Device initialization (`amdgpu_device.c`)

The DRM ioctl bridge (`P1-drm-ioctl-bridge.patch`) translates libdrm's `drmIoctl()` calls to redox-drm scheme operations.

### 1.4 Missing radeonsi in Mesa

The Mesa recipe builds `-Dgallium-drivers=swrast,virgl,iris` — radeonsi is not included. Adding it requires:
1. Functional libdrm_amdgpu (✅ already compiles)
2. Functional amdgpu kernel driver providing `/scheme/drm/card0` with AMD GPU
3. LLVM AMDGPU target for shader compilation (LLVM 21 is built — need to verify AMDGPU target)
4. Cross-compilation of radeonsi's LLVM IR generation for Redox target

### 1.5 AMD Source Tree Already Imported

The full Linux 7.1 AMD source (from the in-tree reference `local/reference/linux-7.1/`) is at `amdgpu-source/gpu/drm/amd/`:
- `amdgpu/` — ~300 C files (core driver)
- `display/` — ~510 C files (Display Core, including DCN 4.2 / RDNA4)
- `pm/` — ~85 C files (power management)
- `amdkfd/` — ~42 C files (compute)
- `ras/` — ~26 C files (reliability)
- Plus `drm/ttm/` and `include/` directories

The recipe's include paths, config defines, and compiler flags are already set up. The Stage 2-4 mechanism (`DISPLAY_SRCS=""`, `TTM_SRCS=""`, `CORE_SRCS=""`) is designed for progressive activation.

---

## 2. Implementation Phases

### Phase 0: Update amdgpu Imported Source to Linux 7.1 (1–2 days)

**Goal:** Replace the current imported amdgpu source (Linux 7.0-rc7 snapshot, 941 files) with the in-tree Linux 7.1 reference (`local/reference/linux-7.1/drivers/gpu/drm/amd/`, 970 files). This brings RDNA4 (DCN 4.2) support, SMU 15.0.8, and 7.0→7.1 bug fixes.

**Why:** The Linux 7.1 reference source is already present in the tree at `local/reference/linux-7.1/`. The imported source at `local/recipes/gpu/amdgpu-source/gpu/drm/amd/` is from an earlier Linux 7.0-rc7 snapshot. Using the in-tree reference ensures we compile the latest available driver code.

**Delta between 7.0-rc7 and 7.1 (74 new files):**

| Category | New files | What they provide |
|---|---|---|
| **DCN 4.2 (RDNA4)** | 24 | Full DCN 4.2 display engine: `dcn42_clk_mgr`, `dcn42_hubbub`, `dcn42_hubp`, `dcn42_dpp`, `dcn42_mpc`, `dcn42_optc`, `dcn42_hwseq`, `dcn42_resource`, `dcn42_dio_link_encoder`, `dcn42_dio_stream_encoder`, `dcn42_hpo_dp_link_encoder`, `dcn42_mmhubbub`, `dcn42_irq_service`, `dcn42_gpio`, `dcn42_pg_cntl` |
| **DMUB DCN 4.2** | 1 | `dmub_dcn42.c` — microcontroller firmware interface for RDNA4 |
| **DML 2.1 for DCN 4.2** | 2 | `dml2_mcg_dcn42.c`, `dml2_pmo_dcn42.c` — display mode library calculations for RDNA4 |
| **Display core ISM** | 1 | `amdgpu_dm_ism.c` — Integrated System Management for display |
| **SMU 15.0.8** | 1 | `smu_v15_0_8_ppt.c` — power management tables for RDNA4 |
| **GPU codecs** | 3 | `jpeg_v5_0_2.c`, `vcn_v5_0_2.c`, `lsdma_v7_1.c` — hardware video encode/decode + DMA |
| **GPU reg access** | 1 | `amdgpu_reg_access.c` — register access helpers |
| **Other headers/assorted** | 41 | Updated headers, includes, and minor 7.1 changes |

**Procedure:**

```bash
# 1. Back up current import
cp -a local/recipes/gpu/amdgpu-source local/recipes/gpu/amdgpu-source.bak-7.0-rc7

# 2. Copy 7.1 amdgpu tree over the import
rsync -av --delete \
  local/reference/linux-7.1/drivers/gpu/drm/amd/ \
  local/recipes/gpu/amdgpu-source/gpu/drm/amd/

# 3. Also update TTM and DRM headers if needed
rsync -av \
  local/reference/linux-7.1/drivers/gpu/drm/ttm/ \
  local/recipes/gpu/amdgpu-source/drm/ttm/

# 4. Update include/ directory (DRM, display, bridge headers)
rsync -av \
  local/reference/linux-7.1/include/drm/ \
  local/recipes/gpu/amdgpu-source/include/drm/

# 5. Verify the update
echo "Files in updated import: $(find local/recipes/gpu/amdgpu-source/gpu/drm/amd -name '*.c' | wc -l)"
# Expected: 970

# 6. Git commit the update
git add local/recipes/gpu/amdgpu-source/
git commit -m "amdgpu-source: update imported AMD GPU tree to Linux 7.1 reference

- Replaces Linux 7.0-rc7 snapshot (941 C files) with Linux 7.1 (970 C files)
- Adds DCN 4.2 (RDNA4 / Radeon RX 9000 series) display engine support
- Adds SMU 15.0.8 power management tables
- Adds JPEG/VCN 5.0.2 hardware codec support
- 74 new files, various 7.0→7.1 fixes
- Source: local/reference/linux-7.1/drivers/gpu/drm/amd/"
```

**Impact on the plan:**
- The recipe's include paths and config defines in `amdgpu/recipe.toml` remain unchanged — they reference the `amdgpu-source/` tree which is now updated
- The linux-kpi gap audit (Phase 1) must account for any new Linux kernel APIs used by the 74 new DCN 4.2 files
- The minimum DC subset for Phase 2B should target DCN 3.1 (RDNA2/RDNA3) first, then add DCN 4.2 later — this avoids expanding the compilation scope before the base path works

**Exit criteria:**
- `local/recipes/gpu/amdgpu-source/gpu/drm/amd/` contains 970 C files matching Linux 7.1
- File count verification passes
- Git commit recorded

---

### Phase 1: linux-kpi Gap Filling (4–6 weeks) — **~85% COMPLETE**

**Status (2026-05-30):** All 12 core amdgpu files pass through linux-kpi without fatal "file not found" errors. 148 C headers created. 280-1540 non-fatal errors per file remain — predominantly from incomplete `struct amdgpu_device` sub-fields that require Linux kernel CONFIG_* option matching, plus ~50 implicit function declarations.

**Headers created (109 new beyond original 39):**
- **DRM KMS framework** (27): drm_drv, drm_crtc, drm_plane, drm_encoder, drm_connector, drm_framebuffer, drm_modes, drm_edid, drm_vblank, drm_atomic, drm_atomic_helper, drm_syncobj, drm_file, drm_gem, drm_gem_ttm_helper, drm_exec, drm_gpu_scheduler, drm_print, drm_probe_helper, drm_suballoc, drm_fbdev_generic, drm_fbdev_ttm, drm_client, drm_client_setup, drm_panic, drm_cache, drm_mm
- **TTM** (6): ttm_device, ttm_resource, ttm_range_manager, ttm_tt, ttm_bo, ttm_placement
- **Core Linux** (42): completion, dma-fence, dma-fence-array, kref, rbtree, hashtable, ktime, pm_runtime, kthread, iommu, irqdomain, mmu_notifier, bitmap, bitops, seq_file, pagemap, interval_tree, nospec, cc_platform, dynamic_debug, console, aperture, power_supply, suspend, delay, vmalloc, device, mutex, spinlock, workqueue, wait, etc.
- **Types** (8): __u32, __u64, __s32, __s64, __u16, __u8, __kernel_size_t, resource_size_t, __bitwise
- **Misc** (26): asm/bug, asm/linkage, asm/io, dt-bindings, uapi/sched, video/nomodeset, various platform stubs

**Compilation strategy validated:** linux-kpi-only includes (no imported Linux `include/` tree — avoids infinite dependency chains). Added include paths for amdgpu internal headers: `display/include/`, `amdgpu/`.

**Next for Phase 1 completion:**
1. Fix ~50 implicit function declarations (add missing function stubs to existing headers)
2. Match Linux CONFIG_* options so conditional struct fields are present (CONFIG_DRM_AMDGPU_VIRT, CONFIG_DRM_AMD_DC_DCN, etc.)
3. Complete DRM atomic helper implementations (currently declared-only)

**Goal:** Expand linux-kpi C headers and Rust implementations to cover all Linux kernel APIs that the amdgpu driver calls. Without this, the 941 C files will fail to compile.

#### 1A: Audit amdgpu API requirements

Method: Attempt to compile a subset of amdgpu C files through linux-kpi, collect errors, prioritize by frequency.

**Initial compile target** (smallest useful subset):
```
amdgpu_drv.c         — PCI probe entry point
amdgpu_device.c      — GPU device init
amdgpu_kms.c         — KMS integration
amdgpu_irq.c         — Interrupt handling
amdgpu_fence.c       — GPU fence/synchronization
amdgpu_bo.c          — Buffer object management
amdgpu_gem.c         — GEM integration
amdgpu_gtt_mgr.c     — GTT management
amdgpu_vm.c          — Virtual memory (page tables)
amdgpu_ih.c          — Interrupt Handler ring
```

**Likely gap categories:**

| API Category | Missing Functions (expected) | Implementation Complexity |
|---|---|---|
| **PCI config space** | `pci_read_config_dword`, `pci_write_config_dword`, `pci_find_capability`, `pci_save_state`, `pci_restore_state`, `pci_set_power_state` | LOW — exist as declarations, need full impl |
| **MSI/MSI-X** | Full capability walking for MSI-X table offset/BIR | MEDIUM — needs PCIe capability chain parsing |
| **MMIO** | `pci_iomap_range`, `ioremap_wc`, `ioremap_np`, `memcpy_toio`, `memset_io` | LOW — mostly exist or are trivial |
| **DMA** | `dma_set_mask_and_coherent`, scatter-gather mapping (`dma_map_sg`, `dma_unmap_sg`), `dma_sync_sg_for_cpu/device`, streaming DMA | HIGH — scatter-gather is complex |
| **Power management** | `pm_runtime_get_sync`, `pm_runtime_put_autosuspend`, `pm_runtime_allow`, system suspend/resume callbacks | LOW — can be stubs returning success |
| **Regmap / IO** | `regmap_read`, `regmap_write`, `regmap_update_bits` | MEDIUM — need regmap implementation |
| **Clock / delay** | `usleep_range`, `msleep_interruptible`, `ktime_get`, `ktime_get_real` | LOW — mostly exist |
| **Random** | `get_random_bytes`, `prandom_u32` | LOW — host random |
| **Debug** | `WARN_ON`, `BUG_ON`, `dump_stack`, `dev_dbg` | LOW — already have equivalents |
| **ACPI** | Full ACPI stubs — amdgpu calls ACPI for backlight, power, platform info | LOW — all stubs returning "not found" |
| **DRM framework** | `drm_dev_alloc`, `drm_dev_register`, `drm_dev_unregister`, `drm_connector_list_iter_begin`, `drm_mode_config_reset`, `drm_atomic_helper_check`, `drm_atomic_helper_commit`, `drm_atomic_helper_swap_state`, `drm_atomic_state_alloc`, `drm_atomic_get_crtc_state`, `drm_atomic_get_plane_state`, `drm_atomic_get_connector_state`, `drm_crtc_vblank_get`, `drm_crtc_vblank_put`, `drm_crtc_handle_vblank`, `drm_crtc_send_vblank_event`, `drm_crtc_arm_vblank_event`, `drm_crtc_vblank_count`, `drm_atomic_crtc_set_property` | VERY HIGH — the DRM atomic modeset framework is the largest gap. The `drm_shim.rs` (374 lines) provides basic structs but NO atomic helper implementation. |

**DRM atomic helpers are the single biggest missing piece.** AMD DC (Display Core) uses the DRM atomic modesetting framework extensively. Without it, the display path cannot function.

#### 1B: Implement critical missing APIs

Priority order:

1. **DRM atomic helper shim** (largest, 4–8 weeks alone)
   - `drm_atomic_helper_check` — validate atomic state
   - `drm_atomic_helper_commit` — apply atomic state  
   - `drm_atomic_state_alloc/swap_state`
   - `drm_atomic_get_crtc_state`, `drm_atomic_get_connector_state`, `drm_atomic_get_plane_state`
   - `drm_crtc_vblank_get/put/handle_vblank/send_vblank_event/arm_vblank_event`
   - `drm_mode_config_reset`
   - CRTC/connector/plane helper registration

2. **PCI config space** (2–3 weeks)
   - Full capability chain walking for MSI/MSI-X
   - Config space read/write through `/scheme/pci/` scheme
   - Power state management

3. **DMA scatter-gather** (2–3 weeks)
   - `struct scatterlist`, `sg_table`
   - `dma_map_sg`, `dma_unmap_sg`, `dma_sync_sg_for_cpu/device`
   - `sg_alloc_table`, `sg_free_table`, `for_each_sg`

4. **Regmap** (1–2 weeks)
   - `regmap_init_mmio` — register map backed by MMIO
   - `regmap_read`, `regmap_write`, `regmap_update_bits`
   - `regmap_set_bits`, `regmap_clear_bits`

5. **Additional DRM/KMS helpers** (1–2 weeks)
   - `drm_connector_list_iter_begin/end/next`
   - `drm_edid_read`, `drm_add_edid_modes`, `drm_edid_is_valid`
   - `drm_dp_dpcd_read`, `drm_dp_dpcd_write`, `drm_dp_link_train_channel_eq_delay`

#### 1C: C header declarations

For each implemented Rust function, add the corresponding C declaration to the `c_headers/` tree. Ensure header include chains are correct (e.g., `linux/pci.h` includes `linux/types.h` includes `linux/compiler.h`).

**Exit criteria:**
- `bash compile-test.sh` compiles a test set of 10–20 amdgpu C files through linux-kpi with zero "implicit declaration" or "undefined reference" errors
- DRM atomic helper shim passes a basic "allocate state → add connector → add CRTC → check → commit" test

---

### Phase 2: amdgpu Core Compilation (6–10 weeks)

**Goal:** Compile the full amdgpu core driver (excluding Display Core initially) through linux-kpi and produce a functional `libamdgpu_dc_redox.so`. Prove basic GPU initialization on real hardware.

#### 2A: GPU device initialization path

**Target files (from `amdgpu/` directory):**
```
amdgpu_drv.c           — PCI probe, driver registration
amdgpu_device.c        — Device init, IP block discovery, GPU reset
amdgpu_kms.c           — DRM KMS integration
amdgpu_irq.c           — Interrupt handler registration, IH ring
amdgpu_fence.c         — Fence/sync timeline
amdgpu_bo.c            — Buffer object (alloc/free/map/unmap)
amdgpu_gem.c           — GEM integration (PRIME, mmap)
amdgpu_gtt_mgr.c       — GTT memory manager
amdgpu_vram_mgr.c      — VRAM memory manager (optional)
amdgpu_vm.c            — GPU virtual memory (page tables)
amdgpu_ih.c            — Interrupt Handler ring buffer
amdgpu_ucode.c         — Microcode/firmware loading
amdgpu_psp.c           — Platform Security Processor firmware
amdgpu_smu.c           — System Management Unit (power)
amdgpu_gmc.c           — Graphics Memory Controller (GART, VM)
```

**Compilation strategy:**
1. Add files one by one to `CORE_SRCS` in the recipe
2. For each compilation error, either:
   - Add the missing linux-kpi function (preferred)
   - Add a `#ifndef __redox__` guard around unsupported code paths
   - Add a stub implementation in `redox_stubs.c`
3. Keep a running list of "deferred files" that have too many dependencies

**Expected challenges:**
- The amdgpu driver uses Linux kernel idioms extensively (container_of, linked lists, IDR, kref, workqueues, completion, mutex/spinlock, atomic ops, bitops, io read/write, DMA mapping, PCI config, module params, sysfs/debugfs, kernel threads)
- GPU registers are accessed through abstractions that assume Linux MMIO APIs
- Interrupt handling assumes Linux's `request_irq`/`free_irq` with `IRQF_SHARED`
- Firmware loading assumes `request_firmware` with `/lib/firmware` path
- Power management assumes Linux PM framework
- GPU reset assumes Linux workqueue + completion

#### 2B: Display Core (DC) compilation

**This is the largest and most complex subsystem.** The AMD Display Core (~510 C files, including DCN 4.2 from Linux 7.1) implements:
- DCN hardware abstraction (dcn10/dcn20/dcn21/dcn30/dcn301/dcn31/dcn32/dcn35)
- Display pipe configuration (OPP, DPP, MPC, HUBP)
- Link training (DP, HDMI)
- DSC (Display Stream Compression)
- DMUB (microcontroller firmware)
- HDCP content protection
- FreeSync / Adaptive Sync
- HDR / color management

**Strategy for DC**: DO NOT attempt to compile all 487 files at once. Instead:

1. **Identify the minimum DC subset for basic display output** (likely 30–50 files):
   - `dc.c` — DC core (init, create, destroy)
   - `dc_link.c` — link management
   - `dcn10/dcn10_hw_sequencer.c` or `dcn20/dcn20_hw_sequencer.c` — hardware sequencing
   - `dcn10/dcn10_hubbub.c` — display buffer hub
   - `dcn10/dcn10_hubp.c` — display pipe
   - `dcn10/dcn10_dpp.c` — display pipe processing
   - `dcn10/dcn10_opp.c` — output pixel processing
   - `dcn10/dcn10_mpc.c` — multi-plane compositor
   - `dcn10/dcn10_hw_sequencer_debug.c`
   - `dce/dce_clock_source.c` or `dcn10/dcn10_clk_mgr.c` — clock management
   - `core/dc_resource.c` — resource management
   - `core/dc_link_dp.c` — DP link management
   - `core/dc_link_hwss.c` — link hardware sequencing
   - `core/dc_link_ddc.c` — DDC I2C for EDID
   - `dc_edid_parser.c` — EDID parsing
   - `dmub/*` — DMUB firmware interface
   - One DCN generation's register headers

2. **Compile the minimum subset through linux-kpi**
3. **Target DCN 3.1 (RDNA2/RDNA3) first** — this is the most mature and well-tested DCN generation in Linux 7.1. DCN 4.2 (RDNA4) was added in 7.1 and may have more linux-kpi dependencies. Once DCN 3.1 works, expand to DCN 3.2, 3.5, then 4.2.
4. **Prove display output on real hardware** (this is the critical validation gate)
4. **Incrementally expand** to multi-display, HDR, FreeSync, DSC, etc.

#### 2C: Recipe activation

Update the `amdgpu/recipe.toml` Stages 2–4 to include compiled files:

```bash
# Stage 2: AMD Display Core
DISPLAY_SRCS="${AMD_SRC}/display/dc/core/dc.c
             ${AMD_SRC}/display/dc/core/dc_resource.c
             ..."

# Stage 3: TTM
TTM_SRCS="${TTM_SRC}/ttm_bo.c ..."

# Stage 4: amdgpu core
CORE_SRCS="amdgpu_drv.c amdgpu_device.c amdgpu_kms.c ..."
```

#### 2D: Redox-specific glue for amdgpu internals

Some Linux kernel APIs used by amdgpu have no direct Redox equivalent and cannot be shimmed trivially. These need Redox-native alternatives:

| Linux API | Redox Alternative |
|---|---|
| `/sys/kernel/debug/dri/` (debugfs) | Log to stderr, skip debug output |
| `/sys/class/drm/` (sysfs) | Skip entirely |
| `MODULE_PARM_DESC(name, desc)` | Already no-op |
| Kernel threads (`kthread_run`) | `std::thread::spawn` |
| `synchronize_rcu()` / RCU | No-op (single-threaded GPU ops) |
| `pci_save_state` / `pci_restore_state` | No-op (Redox kernel handles this) |
| ACPI (`acpi_evaluate_object`, `acpi_get_table`) | Stub returning "not found" |
| `drm_dp_mst_topology_mgr` (DP MST) | Skip for Phase 2, add later |
| `drm_hdcp_*` (HDCP) | Skip for Phase 2, add later |

**Exit criteria:**
- `libamdgpu_dc_redox.so` links successfully with all core amdgpu files + minimum DC subset
- GPU device init succeeds on real AMD hardware: MMIO mapped, GPU ID read, firmware loaded, ring buffers initialized
- Basic display output proven: single CRTC, single connector, at least one resolution

---

### Phase 3: Mesa radeonsi Cross-Compilation (4–6 weeks)

**Goal:** Cross-compile the radeonsi Gallium driver for the Redox target, link against libdrm_amdgpu, and prove software-rendered OpenGL through the AMD GPU path.

#### 3A: LLVM AMDGPU target verification

Mesa radeonsi requires LLVM with the AMDGPU target for shader compilation.

```bash
# Check if the Redox toolchain's LLVM includes AMDGPU target
${TARGET}-llvm-config --targets-built
# Should include "AMDGPU" in the output

# If not, rebuild LLVM with AMDGPU target
```

The current mesa recipe uses `llvm21` as a dependency. Verify:
1. LLVM 21 is built with the AMDGPU target
2. The target's `llvm-config` reports AMDGPU support
3. The mesa build can find the LLVM AMDGPU libraries

If AMDGPU target is missing, rebuild LLVM:
```bash
# In the LLVM recipe or toolchain build:
-DLLVM_TARGETS_TO_BUILD="X86;AMDGPU"
```

#### 3B: Mesa recipe modification

Add radeonsi to the Gallium drivers list:

```diff
- -Dgallium-drivers=swrast,virgl,iris \
+ -Dgallium-drivers=swrast,virgl,iris,radeonsi \
```

Additional meson flags needed:
```bash
-Dvulkan-drivers=swrast \          # Keep swrast only for now (RADV deferred)
-Dllvm=enabled \                   # Already enabled
-Dgallium-va=disabled \            # Disable VA-API (no AMD video accel yet)
-Dgallium-vdpau=disabled \         # Disable VDPAU
-Dgallium-omx=disabled \           # Disable OpenMAX
-Dgallium-nine=false \             # Disable Direct3D 9
-Dgallium-opencl=disabled \        # Disable OpenCL (needs ROCm)
-Dvideo-codecs=[] \                # No hardware video codecs yet
```

#### 3C: libdrm_amdgpu runtime validation

Verify libdrm_amdgpu works with redox-drm scheme:
1. `amdgpu_device_initialize()` — opens `/scheme/drm/card0`, reads GPU info
2. `amdgpu_bo_alloc()` — allocates GEM buffer via `DRM_IOCTL_AMDGPU_GEM_CREATE`
3. `amdgpu_bo_cpu_map()` — mmaps GEM buffer via redox-drm scheme
4. `amdgpu_cs_submit()` — submits command buffer via `DRM_IOCTL_AMDGPU_CS`

These ioctls must flow through the DRM ioctl bridge patch (`P1-drm-ioctl-bridge.patch`) to the redox-drm scheme. The scheme must understand AMD GPU ioctl codes and dispatch them to the amdgpu kernel driver.

#### 3D: radeonsi winsys integration

The radeonsi winsys (`src/gallium/winsys/radeon/drm/`) must be adapted:
1. `radeon_drm_winsys.c` — opens DRM fd, queries GPU info
2. `radeon_drm_bo.c` — buffer allocation/free/map
3. `radeon_drm_cs.c` — command stream submission

Since Redox uses a scheme-based DRM (not Linux ioctls), the winsys needs to:
1. Open `/scheme/drm/card0` instead of `/dev/dri/card0`
2. Use `call()` scheme messages instead of `ioctl()` syscalls
3. Map GEM buffers through scheme mmap path

The existing libdrm ioctl bridge patch (`P1-drm-ioctl-bridge.patch`) handles this translation in libdrm. mesa's radeonsi winsys calls libdrm_amdgpu functions (not raw ioctl), so the bridge should work transparently IF libdrm_amdgpu functions are correctly implemented.

**Exit criteria:**
- Mesa compiles with `-Dgallium-drivers=...radeonsi` for Redox target
- `radeonsi_dri.so` produced in `usr/lib/dri/`
- `glxinfo` (or equivalent) reports radeonsi as the renderer
- Software rendering through radeonsi produces correct output (e.g., glxgears runs)

---

### Phase 4: Wayland/KWin Compositing (4–6 weeks, parallel with Phase 3)

**Goal:** KWin Wayland compositor uses AMD GPU for display output and OpenGL rendering through radeonsi.

#### 4A: AMD as DRM master

When redox-drm detects an AMD GPU on the PCI bus, it must:
1. Initialize the amdgpu kernel driver (call into `libamdgpu_dc_redox.so`)
2. Register `/scheme/drm/card0` with the AMD backend
3. Expose the AMD connector/CRTC/encoder topology through KMS ioctls
4. Handle page flip events from AMD display interrupts

The current `redox-drm/src/drivers/amd/mod.rs` provides connector detection and modesetting via the C FFI. This must be expanded to use the full amdgpu Display Core once compiled.

#### 4B: GBM buffer allocation

GBM (Generic Buffer Manager) needs to allocate buffers on the AMD GPU:
1. `gbm_create_device()` — opens `/scheme/drm/card0` (AMD)
2. `gbm_bo_create()` — allocates via `amdgpu_bo_alloc()` → `DRM_IOCTL_AMDGPU_GEM_CREATE`
3. `gbm_bo_map()` — mmaps via scheme
4. `gbm_bo_get_fd()` — exports PRIME fd (needs PRIME support in redox-drm)

The Mesa GBM backend (`src/gbm/backends/dri/gbm_dri.c`) uses libdrm — if libdrm_amdgpu is functional, GBM should work transparently.

#### 4C: KWin DRM backend

KWin's DRM backend (`src/plugins/drm/`) needs:
1. Open `/scheme/drm/card0` as the primary DRM device
2. Enumerate connectors/modes via libdrm
3. Create framebuffers via GBM
4. Perform atomic modeset via `drmModeAtomicCommit()`
5. Handle page flip events

The `KWIN_DRM_DEVICES=/scheme/drm/card0` environment variable is already set in `redbear-full.toml`. KWin must be able to open this path and use it as a DRM fd.

**Challenge**: KWin's DRM backend expects Linux `/dev/dri/card0` semantics. The libdrm patches translate ioctls, but the fd must behave like a DRM device node (select/poll for events, mmap for buffers). The redox-drm scheme already handles this — verified with Intel display path.

**Exit criteria:**
- KWin opens `/scheme/drm/card0` on AMD hardware
- Connector enumeration shows AMD display outputs
- KWin compositor renders at native resolution with radeonsi OpenGL
- Page flip events trigger frame scheduling
- Hardware cursor visible

---

### Phase 5: Hardware Validation (4–8 weeks, overlaps Phases 2–4)

**Goal:** Prove the full stack works on real AMD GPU hardware.

#### 5A: Test hardware requirements

- AMD GPU with Display Core support: Navi 1x (RDNA1), Navi 2x (RDNA2), or Navi 3x (RDNA3)
- PCIe x16 connection (desktop) or internal eDP (laptop)
- Display connected via DP or HDMI
- Red Bear OS bootable via UEFI

#### 5B: Validation gates

| Gate | What to check | Tools |
|---|---|---|
| **G1: GPU probe** | `lspci` shows AMD GPU. `redox-drm` logs "AMD driver ready" with device ID. | `redbear-hwutils phase5-gpu-check` |
| **G2: Firmware load** | amdgpu firmware blobs loaded via `scheme:firmware`. DMCUB firmware uploaded to GPU. | `redbear-info` firmware section |
| **G3: Display init** | DC initializes. Connectors enumerated. EDID read from real monitor. | `cat /scheme/drm/card0/connectors` |
| **G4: Modeset** | CRTC set to native resolution. Display shows Red Bear framebuffer. | Visible output on monitor |
| **G5: Page flip** | Smooth framebuffer transitions. No tearing. | `redbear-phase5-gpu-check --page-flip` |
| **G6: OpenGL render** | Mesa radeonsi renders OpenGL triangle. Output visible on display. | `glxgears` or equivalent |
| **G7: KWin compositor** | KWin starts on AMD GPU. Desktop visible. Window management works. | Boot to desktop |
| **G8: KDE Plasma** | Plasma desktop runs with OpenGL compositing on AMD GPU. | Full desktop session |

#### 5C: Test scripts

Create `local/scripts/test-amdgpu-full.sh`:
```bash
#!/bin/bash
# Full amdgpu validation harness
# Phases: probe → firmware → display → modeset → pageflip → opengl → kwin → plasma
```

**Exit criteria:**
- Gate G4 (modeset) minimum for Phase 2 completion
- Gate G6 (OpenGL) minimum for Phase 3 completion
- Gate G7 (KWin) minimum for Phase 4 completion

---

### Phase 6: Optimization and Polish (4–6 weeks)

**Goal:** Production-quality AMD GPU support.

#### 6A: Performance
- Enable GPU power management (DPM, clock gating)
- Enable DC states (DC5/DC6) for power saving
- Enable display compression (DSC) for high-resolution displays
- Optimize buffer allocation (VRAM vs GTT placement)

#### 6B: Multi-display
- Enable multi-CRTC support (multiple monitors)
- Test different connector types (DP, HDMI, eDP)
- Test hotplug (connect/disconnect while running)

#### 6C: Full feature set
- Hardware cursor (already have cursor infrastructure)
- Gamma/degamma color correction
- FreeSync/Adaptive Sync (if display supports it)
- Backlight control (for laptop panels)

#### 6D: Mesa RADV (Vulkan)
- Add `-Dvulkan-drivers=swrast,amd` to Mesa recipe
- Cross-compile RADV for Redox target
- Test Vulkan applications through KWin

---

## 3. Dependency Graph

```
linux-kpi gap filling (Phase 1)
          |
          v
amdgpu core compilation (Phase 2A)
          |
          v
amdgpu DC minimum subset (Phase 2B) ──────────────────────┐
          |                                                  |
          v                                                  v
amdgpu display output proof (Phase 2B gate)    Mesa radeonsi (Phase 3)
          |                                                  |
          v                                                  v
libdrm_amdgpu runtime validation (Phase 3C)     radeonsi winsys adapt (Phase 3D)
          |                                                  |
          +────────────────────┬─────────────────────────────+
                               |
                               v
                    KWin DRM backend (Phase 4)
                               |
                               v
                    Hardware validation (Phase 5)
                               |
                               v
                    Optimization & RADV (Phase 6)
```

## 4. Resource Requirements

| Resource | Need |
|---|---|
| **AMD GPU hardware** | Navi/RDNA GPU (RX 5000/6000/7000 series). Desktop preferred for PCIe debugging. |
| **Developer time** | 24–40 weeks full-time. Can parallelize: Phase 1 + Phase 2A by one developer, Phase 3 + Phase 4 by another once Phase 2 gate passes. |
| **Linux reference** | `local/reference/linux-7.1/drivers/gpu/drm/amd/` — already present |
| **Test infrastructure** | QEMU with VFIO GPU passthrough (for early bringup without bare metal) |

## 5. Risk Register

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| DRM atomic helpers too large to shim | HIGH | Blocker for Phase 2B | Consider implementing a minimal "non-atomic to atomic" adapter that satisfies DC's atomic API calls without full atomic infrastructure |
| AMD DC depends on undocumented HW behavior | MEDIUM | Display corruption or no output | Use Linux as reference; test on exactly the GPU generation documented in Linux DC source |
| linux-kpi API surface too large | HIGH | Phase 1 drags beyond 6 weeks | Aggressively stub non-critical paths (debugfs, sysfs, ACPI, HDCP, FreeSync). Only implement what compilation demands. |
| Mesa radeonsi won't cross-compile | MEDIUM | Phase 3 blocked | LLVM AMDGPU target must be in toolchain. Fallback: use `swrast` only and focus on display path first. |
| No AMD GPU hardware available | HIGH | Cannot validate | Prioritize QEMU VFIO passthrough as intermediate step. Acquire hardware early in Phase 1. |
| libdrm_amdgpu ioctl bridge incomplete | MEDIUM | Mesa can't talk to AMD GPU | Extend `P1-drm-ioctl-bridge.patch` with missing AMD-specific ioctls as needed during Phase 3C. |

## 6. Success Criteria

- [ ] `libamdgpu_dc_redox.so` links all core amdgpu files + minimum DC subset
- [ ] Red Bear OS boots on AMD GPU hardware and detects the GPU via PCI
- [ ] AMD Display Core initializes and enumerates connected displays
- [ ] At least one display mode is set and visible output is produced
- [ ] Mesa radeonsi cross-compiles for Redox target
- [ ] OpenGL application renders through radeonsi on AMD GPU
- [ ] KWin Wayland compositor runs with DRM master on AMD GPU
- [ ] KDE Plasma desktop session functions with AMD GPU compositing
- [ ] Hotplug detection works (connect/disconnect monitor)
- [ ] System is stable for >1 hour of desktop use

## 7. Alternative Approaches

### 7A: Skip DC, use simple display

Instead of compiling the full AMD Display Core, use the existing bounded display glue path (`amdgpu_redox_main.c`) and expand it incrementally. This avoids the DRM atomic helper dependency entirely for display, while still enabling GPU compute/render through the core driver.

**Tradeoff**: No multi-display, no HDR, no FreeSync, no DSC. But gets basic display + 3D rendering working faster.

### 7B: Use virtio-gpu passthrough

For initial Mesa validation without real AMD hardware: pass through a physical AMD GPU to a QEMU VM via VFIO, then run Red Bear OS inside QEMU with the passed-through GPU. This avoids bare-metal boot debugging overhead.

### 7C: Rust-native AMD driver (longer-term)

Instead of compiling Linux amdgpu through linux-kpi, write a Rust-native AMD GPU driver using the same pattern as the Intel driver. This avoids the linux-kpi compatibility tax entirely but requires reimplementing the entire 941-file codebase in Rust.

**Tradeoff**: Much cleaner architecture, better safety, no C dependency. But 10–20x more implementation work. Not recommended as the primary path.