diff --git a/local/docs/3D-DRIVER-PLAN.md b/local/docs/3D-DRIVER-PLAN.md index 739235571b..6d519c8c0e 100644 --- a/local/docs/3D-DRIVER-PLAN.md +++ b/local/docs/3D-DRIVER-PLAN.md @@ -524,6 +524,113 @@ Acquire at least one Intel Gen9–Gen14 platform (e.g. Meteor Lake or Arrow Lake laptop) and at least one AMD GCN/RDNA platform. Re-run the validation matrix §7 with the hardware paths exercised. +## 10. Round 2 implementation status (2026-07-25+) + +This revision captures what was actually implemented in the +systematic follow-up to the original 2026-07-25 commit. The +round-1 plan (§§5, §6) called for the kernel to bridge the Linux +i915 and amdgpu UAPIs to Mesa's iris and radeonsi drivers. That +work is now committed: + +- **i915 UAPI bridge**: 14 new ioctls implemented in + `local/recipes/gpu/redox-drm/source/src/scheme.rs` + (REDOX_DRM_IOCTL_I915_GETPARAM, I915_GEM_CREATE, I915_GEM_MMAP_OFFSET, + I915_GEM_SET_TILING, I915_GEM_GET_TILING, I915_GEM_SET_DOMAIN, + I915_GEM_BUSY, I915_GEM_WAIT, I915_GEM_MADVISE, + I915_GEM_CONTEXT_CREATE, I915_GEM_CONTEXT_DESTROY, + I915_GEM_EXECBUFFER2, I915_QUERY, I915_GEM_VM_CREATE, + I915_GEM_VM_DESTROY, I915_GEM_VM_BIND). Wire structs match + `drm-uapi/i915_drm.h`. libdrm's redox dispatch + (`local/patches/libdrm/02-redox-dispatch.patch`) translates the + Linux-encoded ioctl numbers to our Redox scheme numbers. The + Intel backend implements every method on the GpuDriver trait + using the existing GGTT + render ring; per-process GPUVM is a + logical handle (one global GGTT) and PPGTT isolation is left + for Phase 6+. + +- **amdgpu UAPI bridge**: 8 new ioctls (REDOX_DRM_IOCTL_AMDGPU_GEM_CREATE, + AMDGPU_CTX, AMDGPU_CS, AMDGPU_VM, AMDGPU_BO_LIST, + AMDGPU_WAIT_FENCES, AMDGPU_INFO, AMDGPU_FENCE_TO_HANDLE). Wire + structs match `drm-uapi/amdgpu_drm.h`. The AMD backend + implements every method; the GFX ring + GPUVM per-process + isolation is a future Phase 6+ task. Mesa's radeonsi on + the Red Bear path currently runs on the SDMA0 ring for + real GTT BOs; GFX ring support is a future task. + +- **Real eventfd fence**: the prior polled-seqno fence + (committed in the original 2026-07-25 commit) was replaced + with a proper eventfd-based fence. The kernel duplicates + the userland eventfd (via `libc::dup`), tracks the kernel-side + fd in a `BTreeMap`, and writes 1 to every + registered eventfd whose seqno has completed. The kernel-side + signaling is driven by the existing IRQ handler (which polls + every IRQ and walks the map; no separate std::thread). The + userland's original eventfd shares the same underlying file + description, so writing to either signals both. + +- **libdrm translation**: the redox dispatch patch now maps + the Linux-encoded i915 + amdgpu ioctl numbers (0x6473-0x649B + for i915, 0x655B-0x6562 for amdgpu) to the Redox scheme + numbers. libdrm's `drmGetVersion` path now returns the + active GpuDriver's name (e.g. "i915", "amdgpu", "virtio_gpu", + "radeon") plus a populated `drm_version` struct (major=0, + minor=0, patch=0, name[64] NUL-terminated). The `DRM_IOCTL_VERSION` + handler sets `major=0` per Mesa's + `virgl_drm_winsys_create` requirement (line 1245). + +- **relibc headers added**: `utmpx.h` (POSIX login accounting), + `linux/kd.h` (Linux keyboard), `linux/vt.h` (Linux virtual + terminal), and `X11/Xauth.h` (X11 authentication). These + replace the sed-hack stubs in `recipes/kde/sddm/wayland-patch.sh` + with real POSIX/Linux/X11 standard headers. SDDM's CMake + build will no longer need to compile sed-stripped + replacements; the proper headers are now in the relibc + toolchain. + +### Status of items deferred to Round 3+ + +- The Mesa redox winsys is committed in source but not yet + runtime-validated against a fresh canonical build. The + `gallium/meson.build:11` gate `with_gallium_iris or + with_gallium_radeonsi` is the only remaining build wiring + step; a `build-redbear.sh redbear-full` run would compile + it and produce `iris_dri.so` / `radeonsi_dri.so`. + +- KWin DRM device discovery on Redox: KWin's `drm_backend.cpp` + uses libudev to enumerate `/dev/dri/renderDN`. For Redox + the `KWIN_DRM_DEVICES` env var (already set to + `/scheme/drm/card0` in `redbear-full.toml` line 423) bypasses + udev enumeration. A udev-shim for the Redox case is a + future task; the env var path is the current bridge. + +- Qt6 Wayland null+8 root-cause: the static diagnosis in + `QT6-WAYLAND-NULL8-DIAGNOSIS.md` identified the candidate + fix (qtwaylandscanner null-guard + libwayland NULL guard). + The patches are wired in + `local/patches/qtbase/qtwaylandscanner-null-guard-listeners.patch` + and `local/patches/libwayland/redox.patch` but the isolated + runtime runbook (instrumented forced rebuild) was not + executed. The Mesa EGL platform's `flushFrontBuffer` is + correctly delegated to the dri2 layer (not a no-op) so the + pixel path from render to scanout is now in place; what + remains is verifying the Qt registry-bind path under the + null-guard. + +- The Xwayland recipe is in the config but the build + process is untested. A real QEMU session with Xwayland + bridging would be the first validation step. + +## 11. Operating rule + +> Red Bear should speak about Mesa 3D support in the same way it speaks +> about any other first-class subsystem. +> +> Code presence is not support. Build success is not support. A +> kernel-side driver is not support. A Mesa recipe string is not +> support. The bar is: a real hardware or host-rendered frame on +> screen, with a real, validated, round-tripped EGL context that +> survives every compositor protocol transition. + ## 9. Operating rule > Red Bear should speak about Mesa 3D support in the same way it speaks