leonarski_fandClaude Opus 5.5
10f83da9e8
Build Packages / build:jfjoch:ubuntu2204:nocuda (push) Successful in 21m25s
Build Packages / Create release (push) Successful in 8s
Build Packages / build:portable:linux-x86_64:nocuda (push) Failing after 8m11s
Build Packages / build:portable:linux-x86_64:cuda (push) Failing after 10m22s
Build Packages / build:jfjoch:rocky8:nocuda (push) Successful in 22m3s
Build Packages / build:portable:windows-x86_64:cuda (push) Failing after 24m19s
Build Packages / Build documentation (push) Successful in 44s
Build Packages / build:rugnux:linux-aarch64:cuda (push) Successful in 9m33s
Build Packages / build:portable:macos-arm64:nocuda (push) Failing after 2m54s
Build Packages / build:jfjoch:rocky9:nocuda (push) Successful in 25m42s
Build Packages / Generate python client (push) Successful in 25s
Build Packages / build:portable:windows-x86_64:nocuda (push) Failing after 22m30s
Build Packages / HDF5 consumer tests (DIALS, XDS) (push) Successful in 24m36s
Build Packages / build:jfjoch:ubuntu2204:cuda (push) Failing after 1m16s
Build Packages / build:jfjoch:ubuntu2404:nocuda (push) Successful in 26m16s
Build Packages / build:jfjoch:rocky8:cuda-sls9 (push) Successful in 28m46s
Build Packages / build:jfjoch:rocky9:cuda-sls9 (push) Successful in 31m40s
Build Packages / build:jfjoch:rocky8:cuda (push) Successful in 29m47s
Build Packages / build:jfjoch:rocky9:cuda (push) Successful in 28m29s
Build Packages / build:jfjoch:ubuntu2404:cuda (push) Successful in 24m27s
Build Packages / Unit tests (push) Successful in 1h36m2s
Build Packages / Validation Battery (push) Failing after 1h29m55s
The FPGA receiver held every frame for the GPU analysis in a heap vector sized to a full buffer slot and then shrunk, which keeps the capacity: ~25 MB per JUNGFRAU 8M frame instead of its compressed size, in a queue with no bound. During the pre-pass (~1000 frames at 100 Hz), or whenever the analysis runs slower than the frames arrive, that grew the broker's heap without limit on top of the configured image buffer. A held frame is now compressed straight into a slot of the receiver's ImageBuffer, the configured buffer the frames are written from. Two buckets per frame: the slot the compressed image waits in (in preparation, so never previewed or sent), and the slot GPUSink writes the CBOR message, analysis and image to, which is sent as before. The waiting slot goes back to the buffer, unsent, when the last copy of the HeldImage is gone. Nothing is copied to the heap and no frame memory is allocated per frame. The two buckets are also two pools: at most half the buffer's slots wait for analysis (the hold queue is bounded to total_slots / 2), so the analysed frames always find slots to be sent from. A frame that finds no free slot, or the hold queue full, is dropped and writer_queue_full is set, as the receiver does for any frame that finds the image buffer full; the frame thread never blocks. A full hold queue also starts the pre-pass on what it has. Analysis slower than the arrival rate therefore costs frames, not memory. jfjoch_stills_gpu_replay holds its frames in an ImageBuffer too (-b MiB, default 8192), and waits for a slot rather than drop a frame. Measured on the HLS-simulated CrMX JUNGFRAU 8M broker (40 frames, image buffer 8 GiB): RSS grew by ~26 MB per held frame before, linearly until the pre-pass; now it is flat once the receiver threads have warmed up (+1.05 GB less at 40 frames, ~25 GB less for a 1000-frame pre-pass). The stills replay of a stored serial collection gives the same beam centre, distance, mask and indexed count as before the change. Test: StillsGPUAnalysis_HoldIsBounded; the other StillsGPUAnalysis tests check every slot is returned. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UqXYdJKPUFLoeAchjzv3x4