# Iteration 12 — Phase 8 (close)

Closes 2026-05-14. iter12 = integrate RFC v2 (vb2_dma_resv producer fences) into linux-fresnel-fourier kernel + verify. PARTIAL close.

## Outcome

| Metric | Value |
|---|---|
| Iteration target | Kernel substrate upgrade (RFC v2) + Bug 4/5 retest |
| Kernel version | `linux-fresnel-fourier 7.0-1` → `7.0-2` |
| Build host | boltzmann (~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/linux-fresnel-fourier/) |
| Build duration | ~50 min on 8-core boltzmann, native (no distcc per kernel-agent policy) |
| Build hash (kernel pkg) | `843fd4462a09b3d9…` |
| Reboot | Successful; sddm autologin for mfritsche kicked in cleanly |
| Bug 4 / Bug 5 | **NO MOVEMENT** — 5-codec hashes byte-identical to anchors |

## 5-codec sweep post-reboot

| Codec | Anchor | iter12 hash | Verdict |
|---|---|---|---|
| H.264 | `71ac099b…` | `71ac099b…` | unchanged (Bug 4 still open) |
| HEVC | `06b2c5a0…` | `06b2c5a0…` | unchanged (Bug 5 still open) |
| VP9 | `4f1565e8…` | `4f1565e8…` | PASS unchanged |
| MPEG-2 | `19eefbf4…` | `19eefbf4…` | PASS unchanged |
| VP8 | `bcc57ed5…` | `bcc57ed5…` | unchanged (Bug 6 still open) |

## What RFC v2 fixes (and doesn't)

Confirmed by re-reading `reference_dmabuf_resv_blocker.md` in light of this result:

> vaDeriveImage / cached-mmap returns all-zero on RK3399; mpv --vo=image or ffmpeg-v4l2request DRM_PRIME are the cache-safe verifiers.

RFC v2 publishes a real `dma_resv` exclusive WRITE fence on V4L2-produced dmabufs at `device_run` time. Consumers that observe via:
- `poll(POLLIN)` on the dmabuf fd
- `DMA_BUF_IOCTL_EXPORT_SYNC_FILE` + sync_file wait
- EGL/Vulkan implicit-sync extensions

…now see a real signalled fence after decode completes (was a stub fence pre-RFC). This addresses the **compositor / GL consumer** problem: Wayland compositors importing CAPTURE dmabufs no longer pull pre-decode-complete pixels (the "solid green frames" symptom from RK3566+Mali-G52 paneled in mfritsche's RFC v1 cover letter).

**RFC v2 does NOT touch the cached-mmap readback path** that libva-vaapi + ffmpeg-hwdownload exercises. Libva does:
1. mmap CAPTURE buffer at init.
2. After DQBUF, call vaDeriveImage; pointer is the mmap region.
3. ffmpeg-hwdownload memcpy's from that pointer.
4. Without `DMA_BUF_IOCTL_SYNC(START)` to invalidate CPU caches, the CPU sees stale data relative to kernel DMA writes.

This path needs `dma_buf_begin/end_cpu_access` or explicit DMA_BUF_IOCTL_SYNC on every read. The 2024 Ming Qian (NXP) videobuf2 cache-sync patch and Hans Verkuil's 9-year-old `vb2-cpu-access` branch are the alternative tracks for this fix. RFC v2 is orthogonal.

## Why VP9 works while H.264 / HEVC don't (via libva)

Empirical observation iter11/iter12: VP9 hash matches kdirect byte-identical via libva on the SAME readback mechanism that fails for H.264/HEVC. The cache-coherency theory predicts ALL codecs should fail — they don't.

Plausible explanations (defer to a future iteration for empirical confirmation):
- VP9 decode timing is short enough that the mmap region's CPU cache is naturally clean by the time hwdownload reads (test fixture is 720p10s with sparse keyframes).
- VP9's NV12 output may land in a different memory region (different cap_pool allocation pattern) that has different cache characteristics.
- VP9's smaller frame size (1280×720) fits in L2/L3 cache windows where H.264 1080p doesn't.

Either way: the readback path is fragile, not uniformly broken.

## Lessons

1. **Kernel substrate upgrade does not necessarily move codec-correctness needles.** RFC v2 is a real architectural improvement but addresses a path orthogonal to libva's mmap readback. Memorialize.
2. **The PROMISE of `reference_dmabuf_resv_blocker.md` was always conditional**: vb2_dma_resv patches help DRM_PRIME consumers. The libva cached-mmap readback was never specifically RFC v1/v2's target.
3. **The campaign's transitive-proof discipline** (backend payload == kdirect, kdirect == SW) remains the valid verification path for libva codec correctness. RFC v2 is upstream-direction work that benefits Wayland compositors and explicit-sync consumers — orthogonal to the campaign's libva→ffmpeg-vaapi→hwdownload chain.

## What did move

Substrate state update:
- `reference_fresnel_kernel_substrate.md` no longer says "vb2_dma_resv … excluded pending RFC v2." RFC v2 is INCLUDED in 7.0-2. Memory entry needs updating.
- Fresnel kernel pkg sha256: 7.0-1 `(prior)` → 7.0-2 `843fd4462a09b3d9…`.
- Backend SHA unchanged (`521c1474…` from iter11 close still installed; no libva rebuild this iter).

## iter12 → iter13 handoff

Substrate at close:
- Kernel `7.0-2` with RFC v2 patches.
- Backend `521c1474…` (iter11 close, α-13 + α-14 wire hygiene shipped).
- sddm autologin as mfritsche persisted in `/etc/sddm.conf.d/20-autologin.conf`.

Iter13 candidates (Bug 4 / Bug 5 still open):

- **α-17 DMA_BUF_IOCTL_SYNC**: explicit cache invalidation before CAPTURE buffer read in libva backend. Add `ioctl(dmabuf_fd, DMA_BUF_IOCTL_SYNC, DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ)` and END at copy_surface_to_image entry/exit. ~30 LOC backend change.
- **α-18 DRM_PRIME path**: switch libva backend's image export to use VIDIOC_EXPBUF + DRM_PRIME mmap. Bigger refactor but uses the cache-coherent path.
- **α-16 OUTPUT byte dump (deferred from iter12 Phase 0)**: instrument source_data pre-QBUF to verify bitstream content matches kdirect's. Rules out OUTPUT-side bug class.
- **Bug 6 VP8 partial output (sister direction)**: re-investigate now that kernel substrate moved.

α-17 is the natural follow-on given the iter12 finding. The cache-sync ioctl is exactly the path Tomasz Figa pointed at in the 2024 linaro-mm-sig discussion (userspace responsibility for explicit sync on cached-mmap V4L2 buffers).

## Memory rule

To save in this iteration:
- **RFC v2 (vb2_dma_resv producer fences) addresses compositor/GL/EGL implicit-sync consumers, NOT libva-vaapi's cached-mmap pixel readback.** Future Bug 4/Bug 5 work must NOT assume the upstream fence series is the fix. The libva path needs explicit `DMA_BUF_IOCTL_SYNC` or DRM_PRIME-mediated reads.

## Substrate memory needs updating

`reference_fresnel_kernel_substrate.md` currently says:
> running `linux-fresnel-fourier 7.0-1` (kernel-agent product, mmind v7.0 + 3 PBP DTS patches). NOT besser-direct. vb2_dma_resv + panfrost iommu-cache excluded pending RFC v2.

Should update to:
> running `linux-fresnel-fourier 7.0-2` (mmind v7.0 + 3 PBP DTS + RFC v2 vb2_dma_resv producer fence patches). panfrost iommu-cache still excluded.