Files
Jungfraujoch/tests
leonarski_fandClaude Opus 5 bec7e2e922 image_preprocessing: fuse the bitshuffle inverse with preprocessing, and verify the decode
The device decoder was byte-exact on every valid input - 994 production-compressed
images, 927 hand-built LZ4 blocks covering engineered (offset, matchlen) pairs across
the overlap branch boundary, 18000 repeat decodes, sanitizer-clean - and an audit
against LZ4_decompress_generic could not construct a valid block it mis-decodes. What
it did not do was notice when the input was NOT valid, and that mattered more than it
looks: the decode buffers are reused frame to frame, so a block that stopped early left
the PREVIOUS image in place, and in the bitshuffled layout the untouched tail is the
most significant byte-plane. A corrupt chunk therefore did not look like a missing
corner. It looked like thousands of real pixels several powers of two too bright, fed
to spot finding with no diagnostic, where the host decoder had raised an error.

So the kernel now flags a block that fails to reach its declared length while consuming
exactly its payload, and the host turns that into an exception once the caller has
synchronised. Reads are clamped against the end of the payload as well as the output,
both length chains are bounded exactly as read_variable_length bounds them, the two
offset bytes are bounded, and LZ4's parsing restrictions are enforced. On the host side
a block size that is not a multiple of 8 elements is rejected (it made the un-transpose
read uninitialised shared memory), the block count is bounded by what the chunk could
hold before it becomes an allocation (twelve header bytes could demand hundreds of MB
of pinned memory, permanently, per worker), trailing bytes are rejected, and the stream
is synchronised before any throw that happens after work is queued. An image of fewer
than 8 elements is all verbatim tail and now decodes rather than throwing. When the
device route fails for any reason the host decoder gets its turn, so it costs speed
rather than the acquisition.

The lanes cooperate on the copies and a later match can read bytes another lane wrote,
which since Volta needs an explicit __syncwarp(); it worked only because ptxas happened
to reconverge at the post-dominator. The prototype's offset == 1 and power-of-two fast
paths are also restored - the shipped kernel ran a runtime modulo, an emulated 32-bit
division per output byte, on the path its own comment calls the common case.

The un-transpose is now fused with preprocessing. One thread owns one group of 8
elements across every byte-plane, so once it has transposed its 8 bytes out of each
plane it holds 8 complete elements and emits 8 finished int32 pixels with the mask, the
error marker, the saturation cap and the statistics applied. The decompressed image is
never materialised: 0.623 -> 0.411 ms/frame at 18 Mpx, 0.523 -> 0.340 with 8 concurrent
workers. Staging nothing in shared memory also drops the 48 kB ceiling, which had made
any file whose bitshuffle blocks exceed it a hard failure; 64 kB blocks now decode.
gpu_compressed is sized from the chunk with grow-on-demand instead of from the
uncompressed size - it was reserving ~73 MB per worker to hold ~4 MB. Measured on a
1630x1553 uint32 rotation set at -N 32, peak GPU memory falls 3756 -> 3084 MiB; the
same model gives ~144 MB per worker on an 18 Mpx frame.

Decoding on the device also stopped reporting a decompression time, which blanked the
broker's compression plot trace and filled /entry/profiling/compressionTime with NaN.
The decoder brackets the decode with CUDA events and reports it again.

Tests: a differential fuzz suite against the CPU decoder - incompressible and highly
compressible data, engineered offsets, a size sweep hitting every rem%8 value twice,
all six element sizes, an 18 Mpx frame, decoder reuse, concurrency, hand-built LZ4
blocks across the overlap boundary, 26 foreign bitshuffle block sizes from 128 B to
64 kB, corrupt payloads and malformed containers, with a coverage report that proves
which LZ4 paths were reached rather than assuming it. Plus the fused path held byte for
byte against ImagePreprocessorCPU, statistics included, and against the host-upload
path on the same frame.

Battery: 37 crystals, every merged number identical to the host-decode run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:13:55 +02:00
..
2026-07-19 09:39:28 +02:00
2026-07-19 09:39:28 +02:00
2026-07-19 09:39:28 +02:00
2026-04-09 13:30:47 +02:00
2024-10-05 13:14:49 +02:00
2024-10-05 13:14:49 +02:00
2025-05-05 19:32:22 +02:00
2026-04-29 09:50:50 +02:00
2026-07-19 09:39:28 +02:00
2026-05-28 18:48:35 +02:00
2025-05-05 19:32:22 +02:00
2025-06-10 18:14:04 +02:00
2026-06-08 08:30:35 +02:00
2025-11-19 09:40:50 +01:00
2026-04-29 09:50:50 +02:00
2026-04-30 22:16:50 +02:00
2025-11-02 13:45:57 +01:00
2024-11-22 21:25:20 +01:00
2025-10-20 20:43:44 +02:00
2025-04-14 11:52:06 +02:00
2025-11-09 12:42:27 +01:00
2025-09-08 20:28:59 +02:00
2025-09-08 20:28:59 +02:00
2025-03-24 12:16:33 +01:00
2026-07-13 13:54:03 +02:00
2025-06-18 15:19:18 +02:00
2025-11-19 17:28:10 +01:00
2026-07-19 09:39:28 +02:00
2025-12-12 21:24:20 +01:00
2026-02-01 13:29:33 +01:00
2026-03-03 22:24:44 +01:00
2025-11-19 09:40:50 +01:00
2025-05-05 19:32:22 +02:00
2024-11-22 21:25:20 +01:00
2026-07-19 09:39:28 +02:00
2026-04-29 09:50:50 +02:00
2024-11-22 21:25:20 +01:00
2025-05-28 18:49:27 +02:00
2026-06-23 20:29:49 +02:00
2025-10-20 20:43:44 +02:00
2024-11-22 21:25:20 +01:00
2026-05-28 18:48:35 +02:00
2025-03-02 13:15:28 +01:00
2026-06-08 08:30:35 +02:00
2025-11-09 12:42:27 +01:00
2026-06-23 20:29:49 +02:00
2024-11-22 21:25:20 +01:00
2025-11-09 12:42:27 +01:00
2025-10-01 22:54:40 +02:00
2026-07-13 13:54:03 +02:00
2025-10-20 20:43:44 +02:00
2026-07-13 13:54:03 +02:00
2026-06-23 20:29:49 +02:00
2026-06-23 20:29:49 +02:00
2026-06-23 20:29:49 +02:00
2026-06-02 11:49:24 +02:00
2026-07-19 09:39:28 +02:00
2026-07-19 09:39:28 +02:00
2025-10-20 20:43:44 +02:00
2026-03-02 15:57:12 +01:00
2025-11-09 12:42:27 +01:00
2025-11-09 12:42:27 +01:00
2026-07-11 07:19:11 +02:00
2026-06-23 20:29:49 +02:00
2026-04-16 11:59:59 +02:00
2026-06-23 20:29:49 +02:00
2025-11-02 13:45:57 +01:00
2025-12-12 21:24:20 +01:00
2026-05-28 18:48:35 +02:00
2026-07-19 09:39:28 +02:00
2026-03-05 22:13:12 +01:00
2026-03-26 20:50:33 +01:00
2024-11-22 21:25:20 +01:00
2026-07-19 09:39:28 +02:00