marfrit/fresnel-fourier
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8b17bf797adac70ed3a487e67822b071953d3126
fresnel-fourier/README.md
T
claude-noether 60e62da666 phase 0 corrections: hantro RK3399 has no H.264; substrate is iter8 master 
Two empirical corrections to the morning-of-2026-05-07 phase 0 lock,
based on V4L2 inventory + iter8 fork build smoke captured this evening
on fresnel (kernel 6.19.9-99-eos-arm).

Correction 1 — hantro-vpu-dec on RK3399 does not advertise H.264.

phase0_findings.md morning lock claimed both rkvdec (/dev/video3)
and hantro-vpu-dec (/dev/video5) advertise H.264. Empirical
v4l2-ctl --list-formats-out shows hantro-vpu-dec exposes only
MG2S (MPEG-2) and VP8F (VP8) — no S264. Likely carryover from
RK3568 (ohm) hantro, which does support H.264; the RK3399 hantro
kernel variant in drivers/media/platform/verisilicon/ registers
a different codec list. Fix:

  - README.md hardware-target table: drop "+ H.264" from Decoder
    block 2.
  - README.md decode-side surface-area paragraph: note hantro is
    MPEG-2 + VP8 only and that there is exactly one bind for H.264
    (rkvdec).
  - phase0_findings.md mechanism table: drop H.264 from /dev/video5
    row; correct DT compatible to rockchip,rk3399-vpu (the actual
    parent device compatible — sysfs reports rockchip,rk3399-vpu,
    not rockchip,rk3399-vpu-dec which is just the v4l2 card type
    string).
  - phase0_findings.md "H.264 lands on both blocks" sentence:
    inverted to "H.264 lands only on rkvdec".
  - phase0_findings.md Open Question #2 (two-block H.264 routing):
    marked RESOLVED 2026-05-07 evening (null). Single bind, no
    routing decision, one test cell per codec.

Empirical evidence: phase0_evidence/2026-05-07/v4l2_inventory_findings.md
(distilled from v4l2_inventory.txt — the latter is gitignored as
raw data, regenerable via the v4l2-ctl invocation documented in
the findings file).

Correction 2 — substrate is iter8 master (65969da), not iter5-end.

phase0_findings.md morning lock framed the substrate as "iter5-end
fork." That was true on 2026-05-05 (iter5 close); between then and
the 2026-05-07 fresnel-fourier scaffold libva-multiplanar continued
through iter6 (per-OUTPUT-slot REINIT request_fd binding), iter7
(slot-leak fix, cap_pool harness, msync verify harness, OUTPUT-pool
teardown), and iter8 (perf binding cell harness, RK3566/3568 doc
fix). Building from master tip 65969da inherits all the iter6-iter8
hardening at zero cost. Fix:

  - phase0_findings.md substrate paragraph: strikethrough the
    "iter5-end" framing, add corrected paragraph naming master
    tip 65969da and listing what iter6/7/8 added.
  - phase0_findings.md top-of-doc: add an "Empirical corrections
    2026-05-07 evening" callout linking to the evidence files,
    so a reader spotting the locked-vs-corrected mismatch knows
    where the empirical update came from.

Empirical evidence: phase0_evidence/2026-05-07/iter8_build_smoke.md
(clean build, vainfo profile enumeration, HEVC anomaly write-up).

What's preserved on purpose:

The strikethrough rendering in phase0_findings.md keeps the original
locked text visible alongside the correction — campaign convention
treats locks as historical record, not editable state. A reader
landing on the file from a deep link sees both the morning's
intent and the evening's empirical update. Git history has the
clean diff if anyone wants the original without strikethrough.

What's not changed:

The codec scope in the locked research question stays correct in
count — five codecs (H.264 + HEVC + VP9 + MPEG-2 + VP8). The
routing table changes (H.264 → rkvdec only; MPEG-2 → hantro only;
no shared block) but the boolean-correctness pass/fail criterion
per codec is unaffected. Phase 1 lock can proceed on the corrected
map without re-opening scope.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 20:57:40 +00:00

102 lines
9.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# fresnel-fourier
## TL;DR
Peer campaign to [`libva-multiplanar`](../libva-multiplanar/README.md), targeting **fresnel** (Pinebook Pro / Rockchip **RK3399**) instead of ohm (PineTab2 / RK3566). Same deliverable shape — make `libva-v4l2-request-fourier` work end-to-end, for production VA-API consumers — but on a different SoC with a different (and broader) V4L2 decoder surface.
The libva backend fork itself (`libva-v4l2-request-fourier`) is shared: it lives at [`../libva-multiplanar/libva-v4l2-request-fourier/`](../libva-multiplanar/libva-v4l2-request-fourier/). This campaign does not nest a second copy. Code-side work that turns out to be RK3399-specific lands either as `#ifdef`/runtime-detected paths inside that fork's `master` or, if scope diverges sharply, on a feature branch — Phase 2 source-read of each iteration decides.
## Origin
`libva-multiplanar` reached iter5-close on 2026-05-05 with the ohm path solid: hantro (`rk3568-vpu` DT compatible) decodes H.264 to NV12 dmabufs end-to-end, three iterations of bugs fixed, mpv `--hwdec=vaapi` smooth, firefox-fourier RDD-sandboxed Firefox engages the backend without `MOZ_DISABLE_RDD_SANDBOX=1`, chromium-fourier 149 confirmed as the regression-check consumer.
That campaign's README explicitly names fresnel (RK3399) and ampere/boltzmann (RK3588) as **"future iterations after ohm path is solid"** (libva-multiplanar/README.md:87). fresnel-fourier is the formal peer campaign for the RK3399 leg of that promise.
**Topology choice (LOCKED 2026-05-07):** peer campaign, not child of libva-multiplanar. Each runs its own 8(+1) phase loop. Cross-link only — fresnel-fourier results do *not* gate libva-multiplanar's Phase 8 close (which already happened iteration-by-iteration on ohm).
## Hardware target
**fresnel** — Pinebook Pro laptop. See [`reference_fresnel_kernel_constraints.md`](../../.claude/projects/-home-mfritsche-src-fourier/memory/reference_fresnel_kernel_constraints.md) for the custom-OC-kernel discipline (don't let `pacman -Syu` clobber the OC DTB) and [`project_fresnel.md`](../../.claude/projects/-home-mfritsche-claude/memory/project_fresnel.md) for fleet placement.
| Property | Value |
|---|---|
| SoC | Rockchip **RK3399** (2× Cortex-A72 + 4× Cortex-A53) |
| GPU | Mali-T860 MP4 (Midgard, panfrost) |
| Decoder block 1 | **rkvdec** (`/dev/video3`) — H.264 + HEVC + VP9 |
| Decoder block 2 | **hantro-vpu-dec** (`rk3399-vpu-dec`, `/dev/video5`) — MPEG-2 + VP8 (RK3399 hantro does **not** advertise H.264; corrected 2026-05-07 from empirical V4L2 enumeration — see [`phase0_evidence/2026-05-07/v4l2_inventory_findings.md`](phase0_evidence/2026-05-07/v4l2_inventory_findings.md)) |
| Encoder block | **hantro-vpu-enc** (`/dev/video4`) — JPEG only |
| OS | EndeavourOS-ARM (Arch derivative; same pacman + marfrit-packages mechanism as ohm) |
| Kernel | `linux-eos-arm 6.19.9-99` — **CONFIG_FTRACE=y, CONFIG_FUNCTION_TRACER=y, CONFIG_DYNAMIC_FTRACE=y, CONFIG_TRACING=y** verified 2026-05-07. No rebuild needed for trace work. |
The decode-side surface area is genuinely broader than ohm. ohm has hantro (H.264 + MPEG-2 + VP8) and an rkvdec block whose mainline `rkvdec2`/`vdpu346` driver isn't merged. fresnel has hantro (MPEG-2 + VP8 only — empirical, see correction note in the table above) **plus** a fully-driven mainline `rkvdec` covering H.264 + HEVC + VP9. So this campaign exercises codecs (HEVC, VP9) the libva-v4l2-request-fourier fork has **never run on real hardware** to date, and there is exactly **one** decoder bind for H.264 (rkvdec) — no two-block routing decision.
GPU side: panfrost on Mali-T860 (Midgard) is a different generation than ohm's Mali-G52 (Bifrost). KWin / Mesa / panfrost stack regressions or wins on T860 are **not** assumed to track G52 — the kwin-fourier verdict from `fourier_attribution` doesn't transfer for free.
## Scope (LOCKED 2026-05-07 in phase0_findings.md)
**In scope:**
- libva-v4l2-request-fourier backend exercised on fresnel V4L2 decode nodes (`rkvdec` + `hantro-vpu-dec`).
- **Codecs: everything decode-capable** — H.264 + HEVC + VP9 (via rkvdec) + MPEG-2 + VP8 (via hantro-vpu-dec). This is the explicit broadening from libva-multiplanar's H.264-first locked scope.
- Test consumers: `vainfo`, `mpv --hwdec=vaapi`, Firefox via `media.ffmpeg.vaapi.enabled`, chromium-fourier 149 (regression check).
- Phase 1 success criterion (matching libva-multiplanar): **boolean correctness** — "libva accepted + providing access to hardware decoder for each codec." Performance metrics deferred.
- **Phase 0 task 1: recover fresnel from the SDDM greeter crash-loop** (per `~/.claude/plans/dynamic-forging-piglet.md`). Recovery is bookkept as substrate work inside this campaign, not as a separate prereq.
**Out of scope:**
- Front-end libva (API library). Backend only.
- Other hardware (ohm + ampere/boltzmann are libva-multiplanar's iterations).
- AV1 (no decoder block on RK3399 supports it).
- Performance metrics — fresnel CPU/GPU benchmarking is a separate iteration after correctness lands.
- `cros-codecs` Rust replacement (per [`user_stance_rust.md`](../../.claude/projects/-home-mfritsche-src-fourier/memory/user_stance_rust.md)).
- Bootlin / Collabora upstreaming default-deferred (per [`feedback_no_upstream.md`](../../.claude/projects/-home-mfritsche-src/memory/feedback_no_upstream.md)). Same discipline as libva-multiplanar.
- KWin / panfrost / Mali-T860 work — orthogonal until proven otherwise; a parallel `kwin-fourier-fresnel` campaign would be a separate decision.
## Process
8(+1) phase loop per [`feedback_dev_process.md`](../../.claude/projects/-home-mfritsche-src/memory/feedback_dev_process.md). Phase 0 substrate is in `phase0_findings.md`. Phase 5 review uses the sonnet-architect subagent pattern (`Plan` with `model: sonnet`).
In-session-acquired data discipline per [`feedback_replicate_baseline_first.md`](../../.claude/projects/-home-mfritsche-src-kwin-overlay-subsurface/memory/feedback_replicate_baseline_first.md): libva-multiplanar's ohm-side measurements are **reference history**, not threshold sources for fresnel-fourier cells.
## Predecessor work this campaign builds on
- **[`../libva-multiplanar/`](../libva-multiplanar/)** — five closed iterations on ohm. Read in order:
- `README.md` — current state, codec scope, file map.
- `phase8_iteration5_close.md` — most recent close. The iter5-end backend is the substrate fresnel-fourier starts from.
- `phase0_findings.md` (and `phase0_findings_iter[2-5].md`) — locked-scope precedent for codec breadth and consumer matrix on ohm; useful frame-of-reference when locking fresnel-side scope.
- `phase8_iteration1_close.md` — iter1 surface-export DMA-BUF lifecycle race + multi-resolution cache + 64-pitch alignment bugs. Likely re-surface candidates on RK3399.
- **[`../libva-multiplanar/libva-v4l2-request-fourier/`](../libva-multiplanar/libva-v4l2-request-fourier/)** — the fork itself. 12 commits ahead of bootlin tip plus iter1..iter5 work. `git log` for the actual landing record.
- **[`~/.claude/plans/dynamic-forging-piglet.md`](../../.claude/plans/dynamic-forging-piglet.md)** — fresnel SDDM greeter crash diagnosis + recovery plan. Phase 0 task 1 picks up from here.
- **`~/src/fourier_attribution/`** — ohm-only attribution matrix. The chromium-fourier WHEAT-but-fragile verdict and Cell E (vanilla Chromium 149 control) item are ohm-side context, not fresnel data.
External reference (carry-over from libva-multiplanar):
- Mozilla bug 1833354 / 1965646 (Firefox HW decode on RK35xx via libva-v4l2-request).
- Bootlin upstream `bootlin/libva-v4l2-request` — dormant since 2021.
- Linux kernel `drivers/staging/media/rkvdec/` — RK3399 rkvdec H.264/HEVC/VP9 control protocol reference.
- Linux kernel `drivers/media/platform/verisilicon/hantro_*` — RK3399-vpu-dec MPEG-2/H.264/VP8 control protocol reference.
## Repository layout
```
~/src/fresnel-fourier/ <- this campaign (its own git repo)
├── README.md <- this file
├── phase0_findings.md <- locked research question + Phase 0 work list
├── (worklist.md, phase[2-8]*.md as phases land)
└── (the libva fork is NOT here — see ../libva-multiplanar/libva-v4l2-request-fourier/)
```
The campaign repo and the fork repo stay **separate**. fresnel-fourier commits its findings here; code changes to the backend land on the fork's `master` (or a branch named per the iteration if scope diverges from libva-multiplanar's ohm-side `master`).
Operator-facing repo URL: `git.reauktion.de/marfrit/fresnel-fourier` — created empty during scaffolding, no push until first iteration finds something worth publishing.
## Non-upstreaming default
Inherited from libva-multiplanar / `feedback_no_upstream.md`. Patches must be aligned to upstream in syntax and semantics; PR/MR/bug-report only on explicit operator instruction.
## Build infrastructure
distcc/cross-build path is the existing fleet: `aarch64crosscompiler` LXD on data, `tesla` LXD on hertz, `dcc1` on dcw3. See `reference_distcc_kernel_builds.md` for invocation. **Per the locked Phase 0 answer for libva-multiplanar (item 9), no distcc for libva builds** — libva is small and links fast, hand-build on fresnel directly. Same default applies here unless a specific reason emerges.
For chromium-fourier 149 / firefox-fourier rebuilds against fresnel-side findings, the boltzmann LXD container path from libva-multiplanar iter3 is reusable.
Reference in New Issue View Git Blame Copy Permalink