forgectrl pinned at the two-frame pipeline: ~14 fps on the GPU path

The pin moves to forgectrl deee6a1: the render overlaps the previous
frame' copies and encodes behind an EGL fence, measured 13.8 fps
single-viewer at ~14 percent CPU and 9.8 fps with both stream types
served at once, luma bit-clean throughout. CAMPAIGN-LOG carries the
dated record; BRINGUP item 20 is down to MSE playback, the
coexistence drill, and the campaign.

docs/BRINGUP.md

@@ -1466,15 +1466,18 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
     artifact of the first session). The **CSI hardware frame skip is
     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;
-    (e) `camera.h264-stream` and the full campaign on an image carrying
-    the fixes. Switches to strip a suspect layer: `FORGECTRL_NO_GPU`,
+    that is the recommended low-CPU configuration today. Third session
+    (2026-08-24 night, forgectrl deee6a1): the render and the encode now
+    overlap - a frame renders behind an EGL fence while the previous
+    frame is IPU-cropped, encoded and published (two IPU source buffers;
+    the rendering frame's capture buffer held until its fence clears) -
+    measured **13.8 fps single-viewer at ~14 % CPU** (fence stall
+    7-9 ms of the 64 ms render, so it is fully hidden), **9.8 fps with
+    MJPEG and H.264 served at once** (stall 0), luma still bit-clean.
+    Remaining: (a) browser MSE playback of the panel's H.264 view;
+    (b) the stream-during-jog coexistence drill with the GPU path
+    active; (c) `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`; diagnostics under `FORGECTRL_GPU_CHECK`

docs/CAMPAIGN-LOG.md

@@ -3697,6 +3697,27 @@ Second session on the flashed fixes (dev 20260824131335, drills from
 
 Bench left clean; stock service restored.
 
+## 2026-08-24: the pipeline goes two frames deep
+
+Third session, on dev 20260824133616 (drills from /tmp, forgectrl
+deee6a1). The serialized loop (wait 26, render 64, IPU copy 14,
+encode 7) became a two-frame pipeline: a frame's render is kicked
+behind an EGL fence and the previous frame's finished render is
+cropped, encoded and published while it runs. ipu_copy keeps two
+source buffers so the rendering and the copying frame never share one;
+the rendering frame's capture buffer stays out of the queue until its
+fence clears, and every teardown, failure and frame-health queue cycle
+settles the in-flight state first.
+
+Measured: 13.8 fps single-viewer (from 9.2), fence stall 7-9 ms
+against the 64 ms render - the render is hidden behind the copies,
+the encodes and the frame wait. Daemon ~14 % CPU at that rate with a
+WiFi viewer attached (the NEON path: 15 fps at 41 %). MJPEG and H.264
+served together run 9.8 fps with the stall at zero (two IPU copies and
+two encodes per frame, 33 ms, all still off-CPU). Luma stays bit-clean
+against the CPU demosaic; H.264 fragments now carry the delivered
+frame's timestamps. Bench left clean; stock service restored.
+
 ## Superseded status notes
 
 ### Shared machine services — remaining polish, as listed 2026-08-13