# Iteration 13 — Phase 8 (close)

Closes 2026-05-14. iter13 = α-17 DMA_BUF_IOCTL_SYNC around CAPTURE buffer read. PARTIAL close. Cache-sync hypothesis empirically falsified.

## Outcome

| Metric | Value |
|---|---|
| Iteration target | Fix Bug 4 + Bug 5 via explicit cache sync on libva CAPTURE read |
| Fork tip start | `8e2c04f` (iter11 close) |
| Fork tip end | `ca4dd88` (1 commit: α-17 DMA_BUF_IOCTL_SYNC) |
| LOC delta | +70 in `src/image.c` |
| Backend SHA on fresnel | `9ba47002f2760eb4af60d48cf821adb705604e73a92b547ea403bd067b183956` |
| Phase 1 criteria | 5/6 PASS (C1 PARTIAL — Bug 4 + Bug 5 hashes unchanged) |
| Wire-byte verification | All ioctls fire correctly: 4 VIDIOC_EXPBUF + 8 DMA_BUF_IOCTL_SYNC (START+END pairs per frame), all return 0 |

## 5-codec sweep on α-17 backend

| Codec | Anchor | iter13 hash | Verdict |
|---|---|---|---|
| H.264 | `71ac099b…` | `71ac099b…` | unchanged |
| HEVC | `06b2c5a0…` | `06b2c5a0…` | unchanged |
| VP9 | `4f1565e8…` | `4f1565e8…` | PASS unchanged |
| MPEG-2 | `19eefbf4…` | `19eefbf4…` | PASS unchanged |
| VP8 | `bcc57ed5…` | `bcc57ed5…` | unchanged |

## Empirical finding

α-17 added `VIDIOC_EXPBUF` → `DMA_BUF_IOCTL_SYNC(START|READ)` → memcpy → `DMA_BUF_IOCTL_SYNC(END|READ)` → close(fd) around the libva CAPTURE-buffer read in `copy_surface_to_image`. Strace confirms:

```
ioctl(5, VIDIOC_EXPBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, index=0, plane=0, flags=O_RDONLY} => {fd=24}) = 0
ioctl(24, DMA_BUF_IOCTL_SYNC, ...) = 0     # START
ioctl(24, DMA_BUF_IOCTL_SYNC, ...) = 0     # END
```

All ioctls succeed; the dma-buf fd is valid; the kernel accepts the cache-sync requests. Yet:
- HEVC libva still produces `06b2c5a0…` (all-zero, identical to pre-α-17).
- H.264 libva still produces `71ac099b…` (16×32 partial-fill).
- The 4 working anchors hold byte-identical.

## What this rules out

**Cache-sync on the cached-mmap path is NOT the bug.** The DMA_BUF_IOCTL_SYNC ioctl is operating correctly (returns 0, fd is valid), but the buffer's CPU view does not change in a way that reflects different kernel-side writes between HEVC and VP9.

The likely root cause now: **rkvdec on RK3399 writes correctly to the CAPTURE buffer for VP9, and writes nothing-or-garbage for HEVC and H.264.** This is structurally the same conclusion the campaign reached at iter8 Phase 7 (γ dump confirmed `destination_data[]` post-DQBUF contains exactly what the YUV output shows). The kernel decode is the deciding mechanism, and we have not found a libva-side change that affects what the kernel writes.

The 6 wire-byte eliminations from iter9 + 4 from iter11 + α-17 cache-sync test together exhaust the libva-side hypothesis surface for "what's different from kdirect."

## What's left

After iter13, the unexamined surfaces are:

- **OUTPUT bitstream byte dump (α-16)** — confirm libva writes the same H.264/HEVC slice bytes to OUTPUT buffer as kdirect.
- **rkvdec source-side investigation** — kernel-agent workflow. Compare what the RK3399 rkvdec-hevc.c and rkvdec-h264.c code paths do at each kernel-write site that produces zero output. Methodology Bommarito demonstrated: KUnit harness wrapping the helper, KASAN-detect write patterns.
- **Hardware-state investigation** — rkvdec MMIO trace via uio + register dump per-frame to see if hardware actually runs.

## Lessons

1. **Three consecutive PARTIAL closes (iter11, iter12, iter13)** confirms the libva-backend-side hypothesis space for Bug 4+5 is essentially exhausted. No wire-byte change, no kernel patch in the RFC v2 fence series, and no cache-sync ioctl changes the codec readback hashes.
2. **The campaign's transitive proof contract** (`reference_dmabuf_resv_blocker.md`) remains the valid verification for libva codec correctness, but it specifically masks the kind of kernel-side write-failure that iter13 has now empirically pinned down as the live source of Bug 4+5.
3. **α-17 is real progress** even as a non-fix: the libva backend now follows the V4L2+dma-buf cache-sync contract correctly (Figa's "userspace responsibility" satisfied). Future kernels that DO have a real cache-coherency issue on the cached-mmap path would now sync correctly via our code.

## Substrate state at iter13 close

- Fork tip `ca4dd88` on noether + fresnel + gitea.
- Backend SHA `9ba47002…` on fresnel (α-13 + α-14 + α-17 cumulative).
- Kernel `linux-fresnel-fourier 7.0-2` (iter12).
- All diagnostic instrumentation preserved.

## iter14 candidates

- **α-16 OUTPUT byte dump** — deferred since iter12 Phase 0. Quick way to rule out OUTPUT-side bug class. ~30 LOC.
- **kernel-side rkvdec audit** — read rkvdec-hevc.c (RK3399 variant) + rkvdec-h264.c carefully; trace what each writes per-frame. If a write is missing or conditional on a flag we don't set, that's the bug.
- **Pivot to Bug 6 (VP8 partial)** — different bug, may have different cause-class. Could open a tangent.
- **Document campaign close-out** — given the diminishing returns, consider whether the campaign should close as "VP9 + MPEG-2 PASS direct via libva; HEVC + H.264 + VP8 still need kernel/HW investigation."

The user's "continue until user intervention" goal means iter14 should pick one of these. α-16 is the cheapest remaining check; kernel-agent workflow for rkvdec audit is the deepest.

Memory rule worth recording: **DMA_BUF_IOCTL_SYNC on V4L2 cached-mmap CAPTURE buffers is necessary for spec compliance but not sufficient for Bug 4/5 fix on RK3399 rkvdec — the underlying issue is kernel-side write-completeness for HEVC and H.264, distinct from cache visibility.**