Files
RedBear-OS/local/recipes/gpu
kellito 9846f288b4 v5.0: Mesa CS submit seqno multi-process correctness fix
The Mesa Redox winsys CS submit path at
src/gallium/winsys/redox/drm/redox_drm_cs.c:156 faked the seqno with
'result.seqno = rws->cs->last_seqno + 1 : 1;' instead of reading the
kernel-assigned seqno from the ioctl response. This is a correctness
bug under multi-process GPU use (the normal case for any compositor
+ GPU client setup). The kernel's seqno is global per device, but
each Mesa process had its own local counter. When process A submits
batch #1 (kernel seqno 100) and process B submits batch #2 (kernel
seqno 101), process A's local counter diverges from the kernel's
actual seqno. Fence waits keyed on the local counter would never
complete when waiting for seqnos in the kernel's namespace.

Fix (three coordinated changes):

### 1. redox-drm kernel side (local/recipes/gpu/redox-drm/)

Following the standard DRM bidirectional-ioctl pattern that
DrmAmdgpuCsWire already uses:

a) driver.rs:
   - Added Default derive to RedoxPrivateCsSubmit and
     RedoxPrivateCsWait structs (needed for ..Default::default() at
     construction sites).
   - Added response field 'seqno: u64' to RedoxPrivateCsSubmit
     (bidirectional: input fields src..byte_count, output seqno).
   - Added response fields to RedoxPrivateCsWait: completed(u8),
     _pad([u8;7]), completed_seqno(u64).
   - Updated size tests: Submit 32->40 bytes, Wait 16->32 bytes.
   - Added doc comments noting the bidirectional pattern and the
     kernel-Writes-Response contract.

b) scheme.rs:
   - CS_SUBMIT handler writes resp.seqno back into req.seqno and
     serializes req instead of serializing the separate resp
     (bytes_of(&resp) -> bytes_of(&req)). This is the kernel
     returning the response in the same struct.
   - CS_WAIT handler similarly copies result fields into req.
   - req made mutable for in-place mutation before serialization.
   - All other places that construct these structs use
     ..Default::default() for the new response fields.

c) drivers/amd/mod.rs, intel/mod.rs, virtio/mod.rs:
   - Each cs_submit and cs_wait construction site now uses
     ..Default::default() for the new response fields. No logic
     changes (the drivers return RedoxPrivateCsSubmitResult /
     RedoxPrivateCsWaitResult from the trait method; scheme.rs
     copies the response into the bidirectional struct).

### 2. Mesa winsys source (local/recipes/libs/mesa/source/)

Merge the separate input/result wire structs into bidirectional
structs so the kernel's response is read back from the same struct
the caller passed to drmIoctl:

a) redox_drm_cs.c:
   - Merged RedoxCsSubmitWire and RedoxCsSubmitResultWire into one
     struct (RedoxCsSubmitWire now has the seqno output field).
   - Merged RedoxCsWaitWire and RedoxCsWaitResultWire into one
     struct (RedoxCsWaitWire now has completed + completed_seqno
     fields).
   - Removed 'result.seqno = rws->cs->last_seqno + 1 : 1;' fake.
     Instead, reads 'submit.seqno' and 'wait.completed_seqno' from
     the same struct after drmIoctl returns.
   - Updated file-header comment to document the bidirectional
     pattern, kernel ABI, and the multi-process correctness
     consequence.

b) Patches the durability:
   - Added 'mesa/26-cs-submit-bidirectional-seqno.patch' to the
     patches list in local/recipes/libs/mesa/recipe.toml.
   - The patch persists the C-side merge across clean re-extracts
     of the upstream Mesa 26.1.4 tarball.

Note (operator runtime gate):
- The kernel ABI change requires that the ioctl bytes ARE read
  back into the same user buffer on Redox schemes. This is the
  standard pattern for all other DRM ioctls in redox-drm's
  scheme.rs (DrmGemCreateWire, DrmAmdgpuCsWire, DrmCreateDumbWire
  etc.). Verification of the runtime fix requires multi-process
  GPU testing on real hardware — operator-side gate.
- Per AGENTS.md NO-FALLBACK policy: this fixes a real correctness
  bug. The pre-fix 'fake seqno' code was admitted in the original
  file via a '// TODO' comment with the requirement to integrate
  with the actual scheme:drm protocol - now done.

Files changed:
- local/recipes/gpu/redox-drm/source/src/driver.rs
- local/recipes/gpu/redox-drm/source/src/scheme.rs
- local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs
- local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs
- local/recipes/gpu/redox-drm/source/src/drivers/virtio/mod.rs
- local/recipes/libs/mesa/source/src/gallium/winsys/redox/drm/redox_drm_cs.c
- local/recipes/libs/mesa/recipe.toml
- local/patches/mesa/26-cs-submit-bidirectional-seqno.patch
2026-07-26 17:04:40 +09:00
..