RedBear-OS/local/docs/AMDGPU-LINUX-KPI-FULL-INTEGRATION-PLAN.md

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:

# 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)

5. Incrementally expand to multi-display, HDR, FreeSync, DSC, etc.

2C: Recipe activation

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

# 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.

# 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:

# In the LLVM recipe or toolchain build:
-DLLVM_TARGETS_TO_BUILD="X86;AMDGPU"

3B: Mesa recipe modification

Add radeonsi to the Gallium drivers list:

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

Additional meson flags needed:

-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:

#!/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.