forgectrl pinned at the 64 ms render; frame skip proven; the record

The pin moves to forgectrl 2d59d78: the chroma passes point-sample
instead of box-averaging, taking the GPU render from 140 ms to 64 and
the stream to ~9 fps at ~7 percent CPU, with luma measured bit-clean
against the CPU path (which also retired the bottom-row artifact).
The CSI hardware frame skip is live-proven with the GPU path and is
the recommended low-CPU configuration. CAMPAIGN-LOG carries the dated
second-session record; BRINGUP item 20 now lists the render-encode
overlap as the path to 15 fps, then MSE playback, the CPU measure,
coexistence, and the campaign.

docs/BRINGUP.md

@@ -1456,22 +1456,31 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
     meet, so the IPU crops between them, 14 ms, no CPU touch) → VPU
     encode, `convert: "gpu"`, image correct to within 2 counts of the
     scalar demosaic; `/cam/h264` serving valid fragmented MP4 on
-    hardware (avc1.424020, ~480 kbit/s on a static bed). Remaining, in
+    hardware (avc1.424020, ~480 kbit/s on a static bed). Second session
-    order: (a) **GPU render time, 140 ms/frame** (~6 fps ceiling; the
+    (2026-08-24 evening, forgectrl 2d59d78): the render decomposed to
-    core runs its full 528 MHz, suspicion is the pre-HALTI
+    41 ms luma + 49 ms per chroma pass; the chroma passes now
-    linear-texture sampling path - decompose per-pass, consider a tiled
+    point-sample instead of box-average (16x fewer per-fragment fetch
-    shadow copy or fewer chroma taps); (b) the **bottom output row**
+    chains), taking the render to 64 ms - **~9 fps at ~7 % CPU**
-    differs from the CPU demosaic (1296 samples, max delta 134; suspect
+    against the NEON path's 15 fps at 41 % - with luma measured
-    the IC's last-line behavior); (c) browser MSE playback of the panel's
+    bit-clean against the CPU path (which also retired the bottom-row
-    H.264 view; (d) measured CPU with an H.264 viewer vs the 41 % MJPEG
+    artifact of the first session). The **CSI hardware frame skip is
-    baseline; (e) CSI hardware frame-skip exercise; (f) the
+    live-proven** with the GPU path (`FORGECTRL_STREAM_FPS=7` →
+    `hw_fps_skip: true`, steady ~7 fps, daemon sampling 0.0 % in top):
+    that is the recommended low-CPU configuration today. Remaining:
+    (a) 15 fps on the GPU path needs the render overlapped with the
+    encode of the previous frame (double-buffered ipu_copy source,
+    deferred glFinish - the loop today serializes wait 26 + render 64 +
+    copy 14 + encode 7); (b) browser MSE playback of the panel's H.264
+    view; (c) measured CPU with an H.264 viewer; (d) the
     stream-during-jog coexistence drill with the GPU path active;
-    (g) `camera.h264-stream` and the full campaign on an image carrying
+    (e) `camera.h264-stream` and the full campaign on an image carrying
     the fixes. Switches to strip a suspect layer: `FORGECTRL_NO_GPU`,
     `FORGECTRL_NO_H264`, `FORGECTRL_NO_HW_SKIP`, plus the existing
     `FORGECTRL_NO_VPU` / `FORGECTRL_NO_NEON` /
-    `FORGECTRL_NO_CACHED_BUFS`; `FORGECTRL_GPU_CHECK` tightens the
+    `FORGECTRL_NO_CACHED_BUFS`; diagnostics under `FORGECTRL_GPU_CHECK`
-    stream-stats cadence and logs the render-versus-copy split.
+    (tight stats cadence, render-versus-copy split, luma/chroma
+    compare) plus `FORGECTRL_GPU_PASSES` (limit the draws) and the
+    frame-wait column in the stream stats.
 
 **Deliberately not gated:** an armed GRBL job after an underrun cuts at the
 stale origin unless homing is required (GRBL mode permits unhomed cutting; the

docs/CAMPAIGN-LOG.md

@@ -3669,6 +3669,34 @@ sampling), so the GPU path holds ~6 fps until that is run down. The
 `getenv` implicit-declaration fix in debayer.c rode along. Bench left
 clean; stock service restored.
 
+## 2026-08-24: the render run to ground, and the chroma box paid for
+
+Second session on the flashed fixes (dev 20260824131335, drills from
+/tmp, forgectrl 2d59d78). Findings by measurement:
+
+- The GPU has LINEAR_TEXTURE_SUPPORT (minor_features1 bit 22 read from
+  debugfs), so Mesa samples the imported buffers directly: no shadow
+  copy, and no risk of the seqno-gated shadow going stale under
+  external DMA - a hazard that was checked for and does not exist here.
+- FORGECTRL_GPU_PASSES decomposed the 140 ms render: 41 ms for luma,
+  49 ms per chroma pass. The chroma box filter (four superpixels, 32
+  dependent fetches per fragment) was the cost, sixteen times the
+  per-fragment price of the luma pass.
+- The chroma passes now point-sample the block's top-left superpixel:
+  render 64 ms, stream ~9 fps at ~7 % daemon CPU (NEON: 15 fps at
+  41 %). Luma stays bit-clean against the CPU path (max delta 1, zero
+  samples off by more than 2), and the first session's bottom-row
+  artifact went with the old chroma pass. Chroma against the box
+  reference reads mean 1.7 on the bench scene: detail, not error.
+- CSI hardware frame skip proven with the GPU path:
+  FORGECTRL_STREAM_FPS=7 programs keep-1-of-2 in the receiver,
+  hw_fps_skip true, steady ~7 fps, the daemon sampling 0.0 % in top.
+  The loop split at rest: wait 26, render 64, IPU copy 14, encode 7 -
+  15 fps needs the render overlapped with the previous frame's encode,
+  recorded as the item-20 remainder.
+
+Bench left clean; stock service restored.
+
 ## Superseded status notes
 
 ### Shared machine services — remaining polish, as listed 2026-08-13

meta-forgefirm/recipes-forgefirm/forgectrl/forgectrl-pin.inc

@@ -2,5 +2,5 @@
 # only SRCREV and PV here - the image manifest leaves *-pin.inc out of the
 # layer content hash because the component entry already identifies the
 # pinned source (forgefirm-image-manifest.bbclass).
-SRCREV = "66148337ee748ce6f57a398c4ba5e7452319fa07"
+SRCREV = "2d59d78524d08a789502a3f2df58861a08af8798"
 PV = "0.1.0"