From 60e62da66676fcc3989c144fafdbf5d794b26abe Mon Sep 17 00:00:00 2001 From: "Claude (noether)" Date: Thu, 7 May 2026 20:57:40 +0000 Subject: [PATCH] phase 0 corrections: hantro RK3399 has no H.264; substrate is iter8 master MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- README.md | 4 ++-- phase0_findings.md | 10 ++++++---- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 9621da2..6ec7d79 100644 --- a/README.md +++ b/README.md @@ -23,12 +23,12 @@ That campaign's README explicitly names fresnel (RK3399) and ampere/boltzmann (R | 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 + H.264 + VP8 | +| 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 **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. +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. diff --git a/phase0_findings.md b/phase0_findings.md index 995c699..7bafc98 100644 --- a/phase0_findings.md +++ b/phase0_findings.md @@ -2,6 +2,8 @@ This campaign's substrate, locked research question, and pre-Phase-1 inventory work for the fresnel/RK3399 leg of the libva-v4l2-request-fourier rollout. Peer to libva-multiplanar (ohm/RK3568); see [`README.md`](README.md) for topology. +**Empirical corrections 2026-05-07 evening.** This document was locked 2026-05-07 morning before the V4L2 surface was empirically enumerated and before iter6–iter8 work in libva-multiplanar was reflected in fresnel-fourier's substrate framing. Two facts have been corrected inline: (1) hantro-vpu-dec on RK3399 does **not** advertise H.264 — only MPEG-2 + VP8 (so Open Question #2 is null); (2) substrate is libva-v4l2-request-fourier `master` tip `65969da` (iter8 Phase 4), not "iter5-end". See [`phase0_evidence/2026-05-07/v4l2_inventory_findings.md`](phase0_evidence/2026-05-07/v4l2_inventory_findings.md) and [`phase0_evidence/2026-05-07/iter8_build_smoke.md`](phase0_evidence/2026-05-07/iter8_build_smoke.md) for the empirical evidence. + ## Campaign-contained data discipline (governing rule) Per [`feedback_dev_process.md`](../../.claude/projects/-home-mfritsche-src/memory/feedback_dev_process.md) Phase 0 + [`feedback_replicate_baseline_first.md`](../../.claude/projects/-home-mfritsche-src-kwin-overlay-subsurface/memory/feedback_replicate_baseline_first.md): @@ -25,9 +27,9 @@ fresnel exposes **two** V4L2 stateless decode interfaces (verified 2026-05-07 vi | Node | Driver | DT compatible | Codecs (kernel CIDs) | Capture format | |---|---|---|---|---| | `/dev/video3` | `rkvdec` | `rockchip,rk3399-vdec` | H.264 (`V4L2_PIX_FMT_H264_SLICE`), HEVC (`V4L2_PIX_FMT_HEVC_SLICE`), VP9 (`V4L2_PIX_FMT_VP9_FRAME`) | NV12 | -| `/dev/video5` | `hantro-vpu` | `rockchip,rk3399-vpu-dec` | H.264 (`V4L2_PIX_FMT_H264_SLICE`), MPEG-2 (`V4L2_PIX_FMT_MPEG2_SLICE`), VP8 (`V4L2_PIX_FMT_VP8_FRAME`) | NV12 | +| `/dev/video5` | `hantro-vpu` | `rockchip,rk3399-vpu` | MPEG-2 (`V4L2_PIX_FMT_MPEG2_SLICE`), VP8 (`V4L2_PIX_FMT_VP8_FRAME`) | NV12 | -Both are `V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE` + `V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`, both speak the request-API for control submission, both produce NV12 output. **H.264 lands on both blocks** — the libva backend has to choose which device to bind for an H.264 surface, and that decision matters for performance even if not for correctness. +Both are `V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE` + `V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`, both speak the request-API for control submission, both produce NV12 output. **H.264 lands only on rkvdec** — RK3399's hantro-vpu-dec does not advertise H.264 (corrected 2026-05-07 evening; the original lock cited H.264 on hantro, which was incorrect on running kernel 6.19.9-99-eos-arm). There is no two-block routing decision for H.264 on this SoC. VA-API consumers (mpv, Firefox, chromium-fourier, vainfo) speak libva. The bridge they expect is `libva-v4l2-request-fourier`. As of libva-multiplanar iter5-close (2026-05-05), the fork is hardened against ohm's hantro-vpu (`rk3568-vpu`) — the test consumers run end-to-end on H.264 with all known iter1..iter4 bugs fixed. Whether that hardening transfers to: @@ -57,7 +59,7 @@ The full chain of bugs found and fixed on ohm/RK3568 hantro is the substrate. Re - `phase8_iteration4_close.md` — iter4: frame-11 EINVAL fixed (DPB `fields=FRAME_REF`, fresh request_fd per frame, B-slice L1 reflist `.fields` copy-paste). mpv 2130 BeginPictures over 90s with 0 EINVAL. - `phase8_iteration5_close.md` — iter5: ~339 lines of debug instrumentation removed; firefox-fourier 150.0.1-1.1 rebuilt non-PGO (21× smaller libxul, 2.7× faster decode); `LAST_OUTPUT_*` moved per-driver-data; mpv `--vo=gpu` 0 segfaults. **iter6+ caveat: cap_pool resolution-change race latent under untested consumer probe patterns** (Phase 5 sonnet C4). -The iter5-end fork is the substrate fresnel-fourier starts from. Codepaths not exercised on ohm — the rkvdec driver path entirely; HEVC + VP9 + MPEG-2 + VP8 control submission — are unknown territory and the most likely Phase 6 work. +~~The iter5-end fork is the substrate fresnel-fourier starts from.~~ **Corrected 2026-05-07 evening:** the substrate is `master` tip `65969da` (iter8 Phase 4) — libva-multiplanar continued past iter5 into iter6 (per-OUTPUT-slot REINIT request_fd binding), iter7 (slot-leak fix, cap_pool harness, msync verify, OUTPUT-pool teardown), and iter8 (perf binding cell harness) between the 2026-05-05 iter5 close and the 2026-05-07 fresnel-fourier scaffold. Building from master inherits all that hardening at zero cost. Codepaths not exercised on ohm — the rkvdec driver path entirely; HEVC + VP9 + MPEG-2 + VP8 control submission — are unknown territory and the most likely Phase 6 work. ### From the libva-v4l2-request-fourier fork itself @@ -110,7 +112,7 @@ This recovery is fresnel-fourier Phase 0 task 1 (LOCKED 2026-05-07). Without gra ## Open questions before Phase 1 lock 1. **SDDM recovery root cause** — is the `qFatal` from a Mesa 26.0.5 panfrost regression on Mali-T860 (Midgard), Qt 6.11.0 xcb-glx-integration internals, or qt6-declarative? Phase 0 task 1 must determine this before Phase 1 locks, because it affects rig stability for measurement. -2. **Two-block H.264 routing** — both rkvdec and hantro-vpu-dec advertise H.264. Which does the libva backend currently bind to? Is the device-selection logic explicit or first-match? The Phase 0 inventory needs to capture the existing fork's device-discovery path before Phase 4 plans how/whether to make this configurable. (Two test cells per codec: rkvdec-bound H.264 and hantro-vpu-dec-bound H.264.) +2. ~~**Two-block H.264 routing**~~ — **RESOLVED 2026-05-07 evening (null).** Empirical V4L2 enumeration showed hantro-vpu-dec on RK3399 does not advertise H.264. Only rkvdec accepts H.264 on this SoC. Single bind, no routing decision, single test cell per codec. 3. **HEVC control-submission contract on rkvdec** — the fork has had HEVC stripped per the libva-multiplanar build-cleanly stack. Re-introducing it for rkvdec is a code addition, not a regression-test. Phase 2 source-read of rkvdec H.265 path + FFmpeg's `v4l2_request_hevc.c` is gating. 4. **VP9 control-submission contract on rkvdec** — never been in the fork. Same Phase 2 source-read need: kernel `rkvdec_vp9.c` + FFmpeg `v4l2_request_vp9.c`. Plus VAAPI-VP9 consumer testing — does mpv exercise it? does Firefox? 5. **MPEG-2 control-submission contract on hantro-vpu-dec** — was iter1 backlog in libva-multiplanar, dropped at iter6 close because A55 CPU handles it fine. On RK3399 the A53 cluster is weaker; HW MPEG-2 decode might be more useful. Phase 2 source-read: kernel `hantro_mpeg2.c` + FFmpeg `v4l2_request_mpeg2.c`.