docs: architecture backlog for multi-SoC daedalus generalization #3
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: marfrit/daedalus-fourier#3
Reference in New Issue
Block a user
Delete Branch "noether/architecture-backlog"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Captures the design draft for generalizing daedalus across the fleet (Pi 5 + Pi 4 + RK3588 + Allwinner H6) while explicitly deferring the work until a second SoC creates a forcing function.
Document-only change: 1 file, +254 lines, no code touched.
TL;DR
daedalus_recipe_dispatch_*) already abstracts substrate selection per kernel. Scaling to multi-SoC is a data extension (caps/<soc>.toml), not new architecture.What the document contains
/usr/lib/daedalus/{shaders,caps,plugins}bcm2712.toml+rk3588.tomlcaps files (TOML keys are TBD)Forcing functions (when to revisit)
Until one of those fires: keep daedalus daemon Pi 5 specific. Pivot to bug-fix backlog (daedalus-v4l2 #145 daemon SEGV, #146 D-state) once cycle 9 deploys.
Refs reauktion/daedalus-v4l2#11 — substitution arc closing.
Captures the design draft for generalizing the daedalus daemon across the fleet (Pi 5 + Pi 4 + RK3588 + Allwinner H6) while explicitly DEFERRING the work until a second SoC creates a forcing function. Key conclusions: - The recipe layer in daedalus-fourier (daedalus_recipe_dispatch_*) already abstracts substrate selection per kernel; scaling to multi-SoC is a data extension (caps/<soc>.toml), not new architecture. - libva-v4l2-request-fourier already abstracts over any V4L2 stateless decoder node; the cross-SoC seam is at the V4L2 device level, where the upstream stateless API put it. - The conceptual gap is that hardware decoders are NOT made of shaders — rkvdec on RK3588, Hantro G1/G2, VPU8, rpi-hevc-dec on Pi 5 are bitstream-in NV12-out monoliths. A generalized daemon needs TWO backends: substrate-composed (today's path) and codec-level pass-through to vendor V4L2 decoders. - On RK3588 + every codec rkvdec supports, the daedalus daemon is bypassed entirely — libva talks to rkvdec directly. The daemon is only ever in the path on SoCs where at least one codec needs substrate composition. Forcing functions for revisiting: - Pi 4 enters daily use with rpivid still unstable upstream (would require a V3D4 substrate-composed path with its own caps file and substrate verdicts). - A third-party user needs to swap shaders for V3D firmware experiments without rebuilding the daemon. - An x86 / panvk host enters the fleet needing dynamic SoC discovery rather than build-time pinning. Until then: keep daedalus daemon Pi 5 specific, push cross-SoC abstraction up to libva-v4l2-request-fourier (which already does most of it). Document covers: - current stack diagram (cycles 1-9 closed) - per-SoC codec coverage matrix - refined sketch: /usr/lib/daedalus/{shaders,caps,plugins} - illustrative bcm2712.toml + rk3588.toml caps files - where it gets hard (probing, fallback, stateful vs stateless, CI matrix, libva node selection) - open questions - decision log No code changes; document only. Refs reauktion/daedalus-v4l2#11 substitution arc closing; pivot to bug-fix backlog (#145 daemon SEGV, #146 D-state) is the next work block once cycle 9 deploys.