fresnel-fourier

marfrit/fresnel-fourier

Fork 0

Commit Graph

Author	SHA1	Message	Date
claude-noether	d8a9903ef4	phase 0 deliverable 4: H.264 baseline trace — PASS boolean correctness H.264 hardware decode on RK3399 / rkvdec / libva-v4l2-request-fourier @ master tip 65969da (iter8 Phase 4) verified bit-exact correct against software reference, when read via the cache-safe DMA-BUF GL import path. Test method: - mpv --hwdec=vaapi --vo=image (DMA-BUF + EGL_EXT_image_dma_buf_import + glReadPixels + JPEG encode — cache-coherency-safe per the iter1 patch-0011 lesson). - Decoded 2 frames at +30s seek (mid-content bunny motion, not BBB intro fade-in) so size + content variation is genuine. - Compared HW JPEGs vs SW reference JPEGs (same mpv invocation with --hwdec=no). Result: HW frame 1 sha256 = f623d5f7... (651,726 bytes) byte-identical SW frame 1 sha256 = f623d5f7... (651,726 bytes) to SW reference HW frame 2 sha256 = 7d7bc6f2... (630,433 bytes) byte-identical SW frame 2 sha256 = 7d7bc6f2... (630,433 bytes) to SW reference Frames 1 vs 2 differ in size — real content change captured. Phase 0 boolean-correctness criterion for H.264: PASS. Contract trace: The V4L2 + media-request ioctl sequence per H.264 frame is the canonical iter6/iter7 pattern: S_EXT_CTRLS (CODEC_STATELESS class, request_fd=N) QBUF CAPTURE_MPLANE index=K QBUF OUTPUT_MPLANE index=K (compressed slice) MEDIA_REQUEST_IOC_QUEUE (request_fd=N) MEDIA_REQUEST_IOC_REINIT (request_fd=N) ← per-OUTPUT-slot reuse DQBUF OUTPUT_MPLANE index=K DQBUF CAPTURE_MPLANE index=K REINIT-before-DQBUF works because the kernel completes decode in ~0.6 ms (request → COMPLETE state), and mainline media_request_ ioctl_reinit accepts both IDLE and COMPLETE. iter7 cap_pool instantiates 24 slots cleanly: "v4l2-request: cap_pool_init: 24 slots ready" in mpv stdout. No EINVAL, no EBUSY, no errors observed across 5 frames. iter4's frame-11 EINVAL bug from libva-multiplanar does not reproduce on RK3399 in this short window (longer-run repro is Phase 1+ work). Side finding — cache-stale readback bug present in libva-backend's vaDeriveImage path on RK3399: When pixels are read via the cached-mmap path (libva's vaDeriveImage + vaMapBuffer, used by ffmpeg -hwaccel vaapi -hwaccel_output_format nv12), readback is corrupted in exactly the iter1 patch-0011 pattern: size=6,220,800 bytes (correct: 2 × 1920×1080×1.5 NV12) non-zero=544 (0.009%) pattern: 16 consecutive non-zero bytes at every 1920-byte row stride, rest of buffer reads as zero diff vs SW reference: 100% of bytes differ, MAE=53.3 per byte This is the canonical stale-cached-mmap pattern. Kernel writes real pixels (proven by DMA-BUF GL import readback succeeding), but the libva backend's image-export path returns a cached pointer without the correct cache-invalidation incantation. Userspace reads stale all-zero memory punctuated by whichever cache lines happened to fetch post-write. Phase 4 work item: audit whether the iter1 patch-0011 cache-flush fix is present, effective, or RK3399-routing-bypassed. Three possibilities: (a) fix landed for RK3568 but cache topology differs on RK3399, (b) fix is gated on something that's not true on RK3399, or (c) RK3399 V4L2_MEMORY_MMAP page protection bypasses the flush. Not gating Phase 0 — kernel-side decode is correct. Phase 1+ binding cells must use the DMA-BUF GL import path for pixel verification, not vaDeriveImage / cached-mmap. The iter1 lesson restated: cached-mmap readback is unreliable on this hardware family. Evidence files (under phase0_evidence/2026-05-07/h264_baseline_trace.md and h264_baseline/): - mpv.stdout — libva log, vaapi-copy engaged, cap_pool_init - h264_baseline_trace.md — full writeup with re-run incantations - mpv.strace.* (gitignored) — 19 per-thread ioctl/openat traces - ftrace_v4l2.txt (gitignored) — kernel qbuf/dqbuf events - merged_ioctls.tsv (gitignored) — time-sorted V4L2/MEDIA/DRM ioctls across all threads - .jpg (gitignored) — HW vs SW JPEG comparison artefacts - frames_hw_cached_readback.nv12 (gitignored) — broken nv12 readback for forensic reference gitignore: extended extension list (jpg, png, nv12, yuv, tsv, strace). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 21:32:36 +00:00
claude-noether	e83298f0da	phase 0 deliverables 1-3: SDDM watchpoint, V4L2 inventory, iter8 fork smoke Three Phase 0 deliverables, three findings worth flagging. Deliverable #1 — SDDM recovery (phase0_recovery_2026-05-07.md): Closed as watchpoint, not as root-caused fix. Greeter is green on this boot — mfritsche has been in Plasma Wayland on tty1 since 20:32. The "Process crashed (exit code 1)" in journalctl -u sddm is the post-login greeter teardown, not the pre-login crash described in ~/.claude/plans/dynamic-forging-piglet.md. No coredumps, no qFatal strings. No package changed since the 2026-04-28 Syyuu; the only difference between the failing boot and this one is a reboot — likely a flaky panfrost/GBM cold-init that happened to succeed. Plan procedures + /var/cache/pacman/pkg rollback candidates remain ready if regression fires. Deliverable #2 — V4L2 inventory (phase0_evidence/2026-05-07/ v4l2_inventory_findings.md, raw capture in v4l2_inventory.txt which is gitignored as raw data): Full v4l2-ctl --all + --list-ctrls-menus + --list-formats-out per node, plus media-ctl topology, plus DT compatibles. Authoritative codec map on running kernel 6.19.9-99-eos-arm: /dev/video3 (rkvdec, rockchip,rk3399-vdec): OUTPUT_MPLANE: S265 (HEVC), S264 (H.264), VP9F (VP9) CAPTURE_MPLANE: NV12 /dev/video5 (hantro-vpu-dec, rockchip,rk3399-vpu): OUTPUT_MPLANE: MG2S (MPEG-2), VP8F (VP8) CAPTURE_MPLANE: NV12 This contradicts phase0_findings.md (and README.md), which both claim hantro-vpu-dec on RK3399 also does H.264. It does not on this kernel. Open Question #2 from phase0_findings.md ("two-block H.264 routing") is null on RK3399. Correction commit follows. Deliverable #3 — iter8 fork build + vainfo (phase0_evidence/ 2026-05-07/iter8_build_smoke.md): Built libva-v4l2-request-fourier master tip 65969da on fresnel directly (no distcc per locked precedent), gcc 15.2.1, meson 1.11.1, ninja 1.13.2, libva 1.23.0, libdrm 2.4.131. Clean build, 302 KB .so, two harmless v4l2.h forward-decl warnings. Installed to /usr/lib/dri/v4l2_request_drv_video.so. vainfo enumerates: rkvdec bind: H.264 {Main, High, ConstrainedBaseline, MultiviewHigh, StereoHigh}, HEVCMain hantro-vpu-dec bind: MPEG-2 {Simple, Main} Substrate is iter8 master, not iter5 as the campaign docs frame — libva-multiplanar continued past iter5 into iter6-iter8 between the 2026-05-05 iter5 close and the 2026-05-07 fresnel-fourier scaffold. Building from master inherits per-OUTPUT-slot REINIT, slot-leak fix, cap_pool harness, msync verify harness, OUTPUT-pool teardown. Correction commit follows. HEVC anomaly worth flagging: src/config.c:146-151 probes V4L2_PIX_FMT_HEVC_SLICE before adding VAProfileHEVCMain. rkvdec advertises S265 so the probe succeeds; HEVCMain gets enumerated. But src/meson.build excludes h265.c from the build. A consumer that calls vaCreateConfig(VAProfileHEVCMain) will succeed (config.c validation list includes HEVCMain) but actual decode will fault at dispatch since no h265 symbols are linked. Phase 4 decision: re-enable h265.c, gate enumeration on a compile-time #ifdef, or strip enumeration honestly. Per-codec routing confirmed one-env-var-per-process: request.c:149 reads LIBVA_V4L2_REQUEST_VIDEO_PATH once at init. A single backend instance binds to either rkvdec or hantro-vpu-dec, not both. Phase 4 will need either a wrapper-script-per-consumer hack or a backend probe-loop change to route by VAProfile across both decode nodes. Build infrastructure (gitignore): Switched from blanket phase*_evidence/ exclude to extension-based allow-list — track narrative .md, ignore raw .txt/.log/.trace/.pcap/ .bin/.gz/.zst/.json/.dat/.ftrace/.strace. Keeps the V4L2 inventory text untracked (reproducible from the v4l2-ctl invocation) while preserving the findings narrative in-repo. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 20:54:38 +00:00

Author

SHA1

Message

Date

claude-noether

d8a9903ef4

phase 0 deliverable 4: H.264 baseline trace — PASS boolean correctness

H.264 hardware decode on RK3399 / rkvdec / libva-v4l2-request-fourier
@ master tip 65969da (iter8 Phase 4) verified bit-exact correct against
software reference, when read via the cache-safe DMA-BUF GL import path.

Test method:

  - mpv --hwdec=vaapi --vo=image (DMA-BUF + EGL_EXT_image_dma_buf_import
    + glReadPixels + JPEG encode — cache-coherency-safe per the iter1
    patch-0011 lesson).
  - Decoded 2 frames at +30s seek (mid-content bunny motion, not BBB
    intro fade-in) so size + content variation is genuine.
  - Compared HW JPEGs vs SW reference JPEGs (same mpv invocation with
    --hwdec=no).

Result:

  HW frame 1 sha256 = f623d5f7...  (651,726 bytes)  byte-identical
  SW frame 1 sha256 = f623d5f7...  (651,726 bytes)  to SW reference
  HW frame 2 sha256 = 7d7bc6f2...  (630,433 bytes)  byte-identical
  SW frame 2 sha256 = 7d7bc6f2...  (630,433 bytes)  to SW reference

  Frames 1 vs 2 differ in size — real content change captured.

Phase 0 boolean-correctness criterion for H.264: PASS.

Contract trace:

The V4L2 + media-request ioctl sequence per H.264 frame is the
canonical iter6/iter7 pattern:

  S_EXT_CTRLS (CODEC_STATELESS class, request_fd=N)
  QBUF CAPTURE_MPLANE  index=K
  QBUF OUTPUT_MPLANE   index=K  (compressed slice)
  MEDIA_REQUEST_IOC_QUEUE   (request_fd=N)
  MEDIA_REQUEST_IOC_REINIT  (request_fd=N)  ← per-OUTPUT-slot reuse
  DQBUF OUTPUT_MPLANE  index=K
  DQBUF CAPTURE_MPLANE index=K

REINIT-before-DQBUF works because the kernel completes decode in
~0.6 ms (request → COMPLETE state), and mainline media_request_
ioctl_reinit accepts both IDLE and COMPLETE. iter7 cap_pool
instantiates 24 slots cleanly: "v4l2-request: cap_pool_init: 24
slots ready" in mpv stdout.

No EINVAL, no EBUSY, no errors observed across 5 frames. iter4's
frame-11 EINVAL bug from libva-multiplanar does not reproduce on
RK3399 in this short window (longer-run repro is Phase 1+ work).

Side finding — cache-stale readback bug present in libva-backend's
vaDeriveImage path on RK3399:

When pixels are read via the cached-mmap path (libva's vaDeriveImage
+ vaMapBuffer, used by ffmpeg -hwaccel vaapi -hwaccel_output_format
nv12), readback is corrupted in exactly the iter1 patch-0011 pattern:

  size=6,220,800 bytes (correct: 2 × 1920×1080×1.5 NV12)
  non-zero=544 (0.009%)
  pattern: 16 consecutive non-zero bytes at every 1920-byte row stride,
           rest of buffer reads as zero
  diff vs SW reference: 100% of bytes differ, MAE=53.3 per byte

This is the canonical stale-cached-mmap pattern. Kernel writes real
pixels (proven by DMA-BUF GL import readback succeeding), but the
libva backend's image-export path returns a cached pointer without
the correct cache-invalidation incantation. Userspace reads stale
all-zero memory punctuated by whichever cache lines happened to fetch
post-write.

Phase 4 work item: audit whether the iter1 patch-0011 cache-flush
fix is present, effective, or RK3399-routing-bypassed. Three
possibilities: (a) fix landed for RK3568 but cache topology differs
on RK3399, (b) fix is gated on something that's not true on RK3399,
or (c) RK3399 V4L2_MEMORY_MMAP page protection bypasses the flush.
Not gating Phase 0 — kernel-side decode is correct.

Phase 1+ binding cells must use the DMA-BUF GL import path for pixel
verification, not vaDeriveImage / cached-mmap. The iter1 lesson
restated: cached-mmap readback is unreliable on this hardware family.

Evidence files (under phase0_evidence/2026-05-07/h264_baseline_trace.md
and h264_baseline/):

  - mpv.stdout — libva log, vaapi-copy engaged, cap_pool_init
  - h264_baseline_trace.md — full writeup with re-run incantations
  - mpv.strace.* (gitignored) — 19 per-thread ioctl/openat traces
  - ftrace_v4l2.txt (gitignored) — kernel qbuf/dqbuf events
  - merged_ioctls.tsv (gitignored) — time-sorted V4L2/MEDIA/DRM
    ioctls across all threads
  - *.jpg (gitignored) — HW vs SW JPEG comparison artefacts
  - frames_hw_cached_readback.nv12 (gitignored) — broken nv12
    readback for forensic reference

gitignore: extended extension list (jpg, png, nv12, yuv, tsv, strace*).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-07 21:32:36 +00:00

claude-noether

e83298f0da

phase 0 deliverables 1-3: SDDM watchpoint, V4L2 inventory, iter8 fork smoke

Three Phase 0 deliverables, three findings worth flagging.

Deliverable #1 — SDDM recovery (phase0_recovery_2026-05-07.md):

Closed as watchpoint, not as root-caused fix. Greeter is green on
this boot — mfritsche has been in Plasma Wayland on tty1 since 20:32.
The "Process crashed (exit code 1)" in journalctl -u sddm is the
post-login greeter teardown, not the pre-login crash described in
~/.claude/plans/dynamic-forging-piglet.md. No coredumps, no qFatal
strings. No package changed since the 2026-04-28 Syyuu; the only
difference between the failing boot and this one is a reboot —
likely a flaky panfrost/GBM cold-init that happened to succeed.
Plan procedures + /var/cache/pacman/pkg rollback candidates remain
ready if regression fires.

Deliverable #2 — V4L2 inventory (phase0_evidence/2026-05-07/
v4l2_inventory_findings.md, raw capture in v4l2_inventory.txt
which is gitignored as raw data):

Full v4l2-ctl --all + --list-ctrls-menus + --list-formats-out per
node, plus media-ctl topology, plus DT compatibles. Authoritative
codec map on running kernel 6.19.9-99-eos-arm:

  /dev/video3 (rkvdec, rockchip,rk3399-vdec):
    OUTPUT_MPLANE: S265 (HEVC), S264 (H.264), VP9F (VP9)
    CAPTURE_MPLANE: NV12

  /dev/video5 (hantro-vpu-dec, rockchip,rk3399-vpu):
    OUTPUT_MPLANE: MG2S (MPEG-2), VP8F (VP8)
    CAPTURE_MPLANE: NV12

This contradicts phase0_findings.md (and README.md), which both
claim hantro-vpu-dec on RK3399 also does H.264. It does not on
this kernel. Open Question #2 from phase0_findings.md ("two-block
H.264 routing") is null on RK3399. Correction commit follows.

Deliverable #3 — iter8 fork build + vainfo (phase0_evidence/
2026-05-07/iter8_build_smoke.md):

Built libva-v4l2-request-fourier master tip 65969da on fresnel
directly (no distcc per locked precedent), gcc 15.2.1, meson 1.11.1,
ninja 1.13.2, libva 1.23.0, libdrm 2.4.131. Clean build, 302 KB
.so, two harmless v4l2.h forward-decl warnings. Installed to
/usr/lib/dri/v4l2_request_drv_video.so. vainfo enumerates:

  rkvdec bind: H.264 {Main, High, ConstrainedBaseline, MultiviewHigh,
                      StereoHigh}, HEVCMain
  hantro-vpu-dec bind: MPEG-2 {Simple, Main}

Substrate is iter8 master, not iter5 as the campaign docs frame —
libva-multiplanar continued past iter5 into iter6-iter8 between the
2026-05-05 iter5 close and the 2026-05-07 fresnel-fourier scaffold.
Building from master inherits per-OUTPUT-slot REINIT, slot-leak
fix, cap_pool harness, msync verify harness, OUTPUT-pool teardown.
Correction commit follows.

HEVC anomaly worth flagging: src/config.c:146-151 probes
V4L2_PIX_FMT_HEVC_SLICE before adding VAProfileHEVCMain. rkvdec
advertises S265 so the probe succeeds; HEVCMain gets enumerated.
But src/meson.build excludes h265.c from the build. A consumer
that calls vaCreateConfig(VAProfileHEVCMain) will succeed (config.c
validation list includes HEVCMain) but actual decode will fault
at dispatch since no h265 symbols are linked. Phase 4 decision:
re-enable h265.c, gate enumeration on a compile-time #ifdef, or
strip enumeration honestly.

Per-codec routing confirmed one-env-var-per-process: request.c:149
reads LIBVA_V4L2_REQUEST_VIDEO_PATH once at init. A single backend
instance binds to either rkvdec or hantro-vpu-dec, not both. Phase 4
will need either a wrapper-script-per-consumer hack or a backend
probe-loop change to route by VAProfile across both decode nodes.

Build infrastructure (gitignore):

Switched from blanket phase*_evidence/ exclude to extension-based
allow-list — track narrative .md, ignore raw .txt/.log/.trace/.pcap/
.bin/.gz/.zst/.json/.dat/.ftrace/.strace. Keeps the V4L2 inventory
text untracked (reproducible from the v4l2-ctl invocation) while
preserving the findings narrative in-repo.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-07 20:54:38 +00:00

2 Commits