[ktf]

GPUTPCCFDecodeZSDenseLink decodes a page with one warp, walking it
timebin by timebin and link by link. For every link header, the warp
also collected the channels with data, a thread per channel with three
warp scans, inside a serial chain of dependent loads that is the
latency limit of the kernel.

On Metal the header loop now only walks the headers, and thread 0
stores each link's level-2 bitmask and the offset of its channel
bitmask in shared memory (+64 bytes). The channels are then collected
with one thread per byte of a link's channel bitmask: one warp scan per
32 bytes instead of about three per link. Same samples in the same
order, same pointers into the page, including into the next one, same
error paths.

On an M1 Max the decode takes 23 to 39% less time per launch in normal
multi-stream runs (pbpb30 4.9 -> 3.7 ms, 50 kHz TF0 6.7 -> 4.2 ms),
about 1 to 2% of the full time frame. The cluster dumps are
byte-identical: sim5pp against the CPU, 30 kHz (1 of 4) and 50 kHz TF0
before against after. pbpb30 in deterministic mode gives 22,183 tracks
as before, and a 36 against 36 pass comparison at 50 kHz shows no
difference in the track count.

It is Metal-only for now, since it was measured only there: CUDA, HIP,
OpenCL and the CPU compile the existing code unchanged. The chain it
shortens is there on every backend, so it could be enabled for them
once timed.

[ktf]

@davidrohr does it make any sense?

[davidrohr]

in some sense, usually I try to make options configurable, so that they are available for all backends. I prefer this over special cases with #ifdef. Otherwise, fine with me.
In any case, why did you close it?
Perhaps we can discuss in person how to do optimizations.

[ktf]

I must have clicked by accident.

[ktf]

The little friend did it only for metal because we couldn't verify the effect on CUDA / HIP. In principle it should work for all backends, though. Yes, we should discuss about the optimisations and how to go on from now on.