Add measured Galaxy S26 NPU/GPU encoder rows
Following up on the earlier card work with an accelerator section: measured Galaxy S26 (SM8850) rows under Performance, labeled encode-signature-only so they are not confused with the end-to-end CPU table above.
The short version: the Adreno runs the f32 encoder in 5.4 ms; the Hexagon runs the i8 file in ~1.26 s and each accelerator refuses the other's file, so the GPU+f32 pairing is the only fast accelerated path on this device. Conditions inline (CompiledModel 2.2.0, 50-run medians, thermal NONE, delegate confirmed from logcat).
Happy to reshape to match the card.
The cross-rejection is worth preserving in the card because it prevents the 5.4 ms vs ~1.26 s result from being read as a clean GPU-vs-NPU comparison. One reproduction detail would help: were the 50-run medians collected after delegate compilation/cache warm-up, and is the ~1.26 s Hexagon figure per encoder invocation? AI-assisted wording; no affiliation.
Thanks for the close read, and for the note on keeping the cross-rejection in the card: that misreading is exactly what the wording was meant to head off.
Yes to both. The medians were collected after compilation and after warm-up, and the ~1.26 s is the cost of one encode invocation, with the whole encoder on the Hexagon.
Each NPU row is its own process. CompiledModel.create is timed on its own and reported as the Load column: 13.1 s in the process that JIT-compiled the file, 0.37 s in a fresh process that loaded the compiled context from LiteRT's JIT cache. The harness then runs 5 untimed warm-up invocations and 50 timed ones; median and min are over those 50.
One timed sample is one run() of the encode signature ([1, 80000] float32 in, [1, 207, 288] out) plus reading the output buffer back; the read sits inside the timed window so any asynchronous completion is counted. The device log agrees: each process shows exactly 55 Hexagon graph executions, spaced 1.25–1.34 s apart from the first pair onward, so no warm-up transient is hiding in the median.
On placement, my 08-26 log excerpt had truncated the runtime's partition report, so I re-ran the same invocation today with the full log kept. It reads Replacing 1 out of 1 node(s) with delegate (DispatchDelegate) node, yielding 1 partitions for subgraph 0 (encode): the encoder is a single Hexagon partition with no CPU-resident op, and each invocation logs exactly one HTP graph execution. The medians reproduced within 0.15% (first-launch process 1.294 s both days; cached process 1.263 s today vs 1.264 s). One more reproduction detail: the timed runs use the input buffer as the API allocates it, with no waveform written in; the encode graph is fixed-shape with no data-dependent ops, so the work per invocation is the same. The decode signature, which the table does not quote, is a mix: 62 of its 124 nodes go to the Hexagon and the remainder to the CPU.
Harness at the commit current when these rows were taken (the timed loop is runInternal): https://github.com/john-rocky/LiteRT-Models/blob/6bca2b380783c28364aff47592a9dc9ee763c05b/npubench/app/src/main/java/com/litertzoo/npubench/NpuBenchmark.kt
Thanks again for the careful read.