From 62992fbd7d2124a820274ecacf616a0dc0ece8d6 Mon Sep 17 00:00:00 2001 From: ScottW514 Date: Mon, 24 Aug 2026 09:59:32 -0400 Subject: [PATCH] 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 | 21 +++++++++++-------- docs/CAMPAIGN-LOG.md | 21 +++++++++++++++++++ .../forgectrl/forgectrl-pin.inc | 2 +- 3 files changed, 34 insertions(+), 10 deletions(-) diff --git a/docs/BRINGUP.md b/docs/BRINGUP.md index a4be8a4..22c753e 100644 --- a/docs/BRINGUP.md +++ b/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` diff --git a/docs/CAMPAIGN-LOG.md b/docs/CAMPAIGN-LOG.md index 550c79e..17536e7 100644 --- a/docs/CAMPAIGN-LOG.md +++ b/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 diff --git a/meta-forgefirm/recipes-forgefirm/forgectrl/forgectrl-pin.inc b/meta-forgefirm/recipes-forgefirm/forgectrl/forgectrl-pin.inc index 7c9d2da..0e4cad4 100644 --- a/meta-forgefirm/recipes-forgefirm/forgectrl/forgectrl-pin.inc +++ b/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 = "2d59d78524d08a789502a3f2df58861a08af8798" +SRCREV = "deee6a1b9a502cb7d464aeecc3e081103e4e3351" PV = "0.1.0"