Original draft (PR #3) speculated wrongly on host-to-SoC mapping:
- hertz and tesla were listed under RK3588. Verified via
/proc/device-tree/compatible: both are raspberrypi,5-model-b /
brcm,bcm2712 (tesla is an LXD container hosted on hertz, so
necessarily shares the host SoC).
- boltzmann (the only actual RK3588 in the fleet, 32 GB, kernel-
dev / MCP hub, 8 W always-on) was omitted entirely.
- noether (Pi 4 / BCM2711, the user's interactive workstation,
where Firefox and mpv actually run) was omitted entirely.
Corrects the per-SoC coverage table:
BCM2712 Pi 5 — higgs, hertz, broglie, tesla (LXD on hertz)
BCM2711 Pi 4 — noether (workstation), dcw3, dcw2
RK3588 — boltzmann
Allwinner H6 — (not in fleet)
Reasoning consequences:
- Pi 5 row is now four hosts but one SoC. Adding a fifth Pi 5
doesn't pressure-test the architecture; substrate decisions
are identical across the row.
- The realistic forcing function for the Pi 4 path is "HW decode
on noether matters and rpivid is still unstable upstream" —
noether is a daily-driver Pi 4 workstation, so this is closer
than the original draft implied.
- The realistic forcing function for an RK3588 caps file is
"AV1 playback on boltzmann matters" — rkvdec doesn't cover
AV1, so Mali Valhall compute substrate becomes the only HW
acceleration option there.
"Re-read this when" list at the top + "Why deferred" section
+ decision log all updated. No change to the architecture sketch
(caps directory, plugin layout, two-backend conclusion) — those
were correct in the original; only the host-to-SoC mapping
underneath them was wrong.
Refs PR #3 (the merged original).
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.
claude-noether