Updates the 3D plan with the fifth-round status. Phase 5+'s
real-IOCTL gap is now closed:
1. ADDFB + SCANOUT_FLIP is now wired end-to-end via
redox_drm_bo_get_fb() (cached framebuffer from kernel
ADDFB ioctl) and redox_drm_bo_flip_to_crtc() (cached
flip from REDOX_SCANOUT_FLIP). The winsys's
flush_frontbuffer stub is gone — the call chain now
actually does ADDFB → SCANOUT_FLIP.
2. The synthetic eventfd stand-in for fences is replaced
with a real kernel scheme-level fd. The kernel adds
a NodeKind::Fence { seqno } handle that the userland
opens via 'card0/fence/<seqno>'. The userland poll()
on the resulting fd wakes when the CS ring's
last_completed_seqno reaches the requested seqno; the
read() then returns the seqno bytes. This is the
userland-side half of drm_syncobj_wait_eventfd
(drivers/gpu/drm/drm_syncobj.c, Linux 7.1).
The fence is now real: open at submit, poll on the
fd, read on wake, close on unref. No more spin-loops.
Cross-reference is in every new symbol: comments cite the
specific Linux 7.1 driver source files being ported.
Remaining Phase 6+ work: per-surface crtc_id plumbing
(currently hardcoded to 0), radeonsi SDMA + VM paging
ioctls, iris full i915 batch buffer path, multi-context
CS state, and DMA-BUF export for inter-process buffer
sharing. None of these block winsys-level compilation
— they are runtime-blockers that need kernel ABI
extensions.
Updates the 3D driver plan with the fourth-round status. Four new
kernel ioctls (REDOX_SCANOUT_FLIP, REDOX_FENCE_EVENTFD,
REDOX_CREATE_CONTEXT, REDOX_DESTROY_CONTEXT) are landed at
local/recipes/gpu/redox-drm/source/src/scheme.rs. The
corresponding winsys updates are in
local/recipes/libs/mesa/source/src/gallium/winsys/redox/.
Each new ioctl cross-references its Linux 7.1 source-pattern:
- REDOX_SCANOUT_FLIP: drivers/gpu/drm/drm_plane.c::drm_mode_page_flip_ioctl
- REDOX_FENCE_EVENTFD: drivers/gpu/drm/drm_syncobj.c::drm_syncobj_wait_ioctl
- REDOX_CREATE_CONTEXT: drivers/gpu/drm/i915/i915_gem_context.c
- REDOX_DESTROY_CONTEXT: ditto
The winsys update replaces the Phase 4 spin-loop fence with an
eventfd-backed wait (still using a stand-in eventfd until the
kernel adds epoll to the CS ring), and wires the surface_flush
path against REDOX_SCANOUT_FLIP (awaiting pipe_resource to fb
binding in the kernel).
Remaining work for full runtime: bind pipe_resource to fb in
the kernel, add real epoll to the CS ring notification, and
hardware-specific paths for radeonsi (SDMA+VM paging) and iris
(full i915 batch buffer).
Phase 4 of local/docs/3D-DRIVER-PLAN.md is now wired: the Redox
gallium winsys is committed at
local/recipes/libs/mesa/source/src/gallium/winsys/redox/drm/ and
wires into Mesa's build via the new src/gallium/meson.build.
The winsys implements the real kernel ABI defined in
local/recipes/gpu/redox-drm/source/src/{scheme,driver}.rs:
- redox_drm_bo.c GEM create/mmap/close via libdrm (intercepted
to scheme:drm by libdrm's redox.patch)
- redox_drm_cs.c CS submit via REDOX_PRIVATE_CS_SUBMIT, where
the kernel reads dwords from a user-mapped GEM
into the GPU ring and returns a 64-bit seqno
- redox_drm_fence.c Polling fence over the kernel's last-completed
seqno. The kernel doesn't expose sync objects yet;
this is an honest stopgap. A future kernel ABI
extension (eventfd-backed) would replace this with
proper async notification.
- redox_drm_surface.c Minimal pipe_surface implementation. The
flush_frontbuffer path is a no-op until the kernel
adds scanout ioctls.
- redox_drm_winsys.c pipe_screen_ops table and lifecycle (init/destroy).
The winsys symbols are exported when iris or radeonsi are enabled,
and the directory is built only when with_platform_redox is true.
Status table updates: iris and radeonsi change from
'🟡 Compiles (libclc OK)' to '🟡 Compiles + winsys wired', with
the remaining '❌ Needs winsys runtime' tag listing the kernel ABI
extensions needed.
The plan also notes that Phase 5+ is blocked on kernel ABI
extensions, not on userland work:
- REDOX_SCANOUT_FLIP ioctl (for surface_flush_frontbuffer wiring)
- context_id field in redox_private_cs (for multi-context)
- eventfd-backed fence (replaces the polling fence)
- DMA-BUF export (for inter-process buffer sharing)
- SDMA + VM paging ioctls (radeonsi-specific)
- i915 batch buffer submission path (iris-specific)
Updates the hardware-acceleration status table to mark iris,
radeonsi, and Vulkan (anv, radv) as 🟡 Compiles (libclc OK).
This is the state after the libclc recipe was added as a proper
Cat 1 in-house project at local/recipes/dev/libclc/.
Status changes:
- iris: ❌ Not built → 🟡 Compiles (libclc OK)
- radeonsi: ❌ Not built → 🟡 Compiles (libclc OK)
- Vulkan anv: ❌ Not built → 🟡 Compiles
- Vulkan radv: ❌ Not built → 🟡 Compiles
- Lunar Lake/PTL: still ❌ Runtime but ✅ Recognized in kernel
The runtime path remains blocked on Phase 4 (Redox gallium winsys).
libclc provides the .bc bitcode but Mesa iris/radeonsi need a
Redox-specific winsys to translate pipe_screen ops into the
redox-drm ioctl surface. Once Phase 4 lands, iris/radeonsi/Vulkan
should work end-to-end.
Adds a callout note explaining the libclc port status with link
to local/recipes/dev/libclc/.
Comprehensive 3D userland plan based on direct code audit of the
Mesa 26.1.4 build, redox-drm Intel backend, virgl runtime path,
amdgpu C port, and libdrm enablement. Seven critical gaps identified
that block all hardware-accelerated 3D rendering on Red Bear OS
beyond llvmpipe fallback:
1. Mesa gallium-drivers=softpipe,llvmpipe,virgl — NO iris, NO crocus,
NO radeonsi. The README/CHANGELOG claim that 'all 6 Red Bear
Mesa patches are wired' is incorrect: only 5 are wired; patches
03 and 06 are orphans because patch 03 targets
src/egl/drivers/dri2/platform_redox.c which does not exist in
Mesa 26.1.4 upstream (the file was removed). Patches 03/06
cannot be cleanly reapplied — they need re-creation against
the current Mesa API.
2. No 'redox' EGL platform in Mesa 26.1.4. EGL_PLATFORM=wayland
resolves to swrast (llvmpipe) on Redox. virgl and iris are
never auto-selected.
3. No Mesa winsys for Redox (src/gallium/winsys/redox/ does not
exist). The virgl driver uses upstream's generic
virgl_drm_winsys which depends on libdrm's redox.patch to
redirect ioctls to scheme:drm.
4. Intel kernel backend supports only Gen9–Gen14 (Meteor Lake).
No Lunar Lake (Xe2, Gen15) device IDs. No Panther Lake (Xe3,
Gen16) device IDs. The display version table stops at 14.
5. No Vulkan built (vulkan-drivers= empty). No anv (Intel), no
radv (AMD), no venus (virtio-gpu Vulkan).
6. The redox_private_cs_submit ABI exists in redox-drm (real
implementation for Intel ring submission with seqno tracking,
space-wait, MI_FLUSH_DW) but no Mesa gallium driver consumes it.
7. The amdgpu C port is display-only (DC modeset, no render/3D).
It does NOT provide a Mesa radeonsi winsys. Stages 2-4 of the
amdgpu recipe are intentionally empty (no Linux TTM/core
source).
The plan file (786 lines) covers:
- Verified code state from direct read (Mesa recipe, Intel
backend, virgl, amdgpu, libdrm)
- Reality-vs-claim corrections (6 overclaims in current docs)
- Hardware-acceleration status table (10 paths)
- 7-phase execution plan with explicit acceptance criteria
for each phase:
Phase 1: Validate current virgl runtime path (1-2 weeks)
Phase 2: Add Lunar Lake and Panther Lake device IDs
Phase 3: Restore the Redox EGL platform (re-create)
Phase 4: Add Intel iris (Gen8-Gen14) — biggest piece, 8-12 weeks
Phase 5: Add AMD radeonsi — 6-8 weeks
Phase 6: Vulkan (enables anv/radv) — 2-4 weeks
Phase 7: Panther Lake kernel driver — 12-16 weeks
- Validation matrix per vendor
- File-level change catalog
- Risk register
- Operating rule: 'code presence is not support; build success
is not support; llvmpipe is not acceleration; an env-override
that requires manual setup is not a runtime path'.
vasilito