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.
This commit is contained in:
ScottW514
2026-08-24 09:59:32 -04:00
parent 24dd2b49f6
commit 62992fbd7d
3 changed files with 34 additions and 10 deletions
+12 -9
View File
@@ -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`
+21
View File
@@ -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
@@ -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"