Dense FP32 (and FP16) matmul on the Android JNI tier: attention runs scalar today #1275

Context

A fully offline Android transcription app built on LiteRT (Whisper large-v3-turbo split encoder/decoder on OpenCL FP16, Parakeet TDT 0.6B, Silero VAD on ONNX Runtime) was evaluated as a SKaiNET consumer. Its author's own measurements on a Pixel 7 Pro are the bar: LiteRT CPU XNNPACK transcribes a 14 s memo in 82.2 s (RTF 5.9); the GPU path needs 34.4 s.

Since 0.50.0 the Android JNI tier (skainet-backend-jni-cpu) serves every GGML quant format from mapped weights on NEON, and 0.52.0 made the dispatch self-installing. That covers the weight side of a Whisper encoder (Q8_0 from whisper.cpp GGUFs, 874 MB). What it does not cover is the activation side.

Gap

The generated kernel support matrix (docs/.../reference/kernel-support-matrix.adoc, 0.54.0) lists Float32 and BFloat16 as scalar on Android, and native/skainet_jni.c exports only q40/q4k/q50/q51/q5k/q6k/q80 matmul entries plus the ternary gemv. A Whisper large-v3-turbo encoder issues, per layer, 20 heads of QKᵀ ([1500,64]×[64,1500]) and AV ([1500,1500]×[1500,64]) as FP32 activation × activation matmuls, 32 layers deep, plus two conv1d stem layers. On Android all of that runs through the scalar Kotlin path, so the quantized weight kernels cannot make the encoder fast on their own.

fp32_matmul.c already exists in skainet-backend-native-cpu (aarch64-verified, see #920) and the JVM reaches it through FFM; Android does not.

Scope

• JNI entries for dense FP32 matmul, including a batched variant and a transposed-right-operand variant (A × Bᵀ) so attention does not pay a transpose copy per head, using the existing skainet_row_threads pool.
• FP16 weight matmul on the JNI tier, since whisper.cpp ships F16 GGUFs and fp16_matmul.c is in tree (FP16: native FFM matmul kernel (priority 100) to match BF16's tier #885 tracks the FFM side of the same kernel).
• JniKernelProvider registrations so KernelDispatch selects them on Android at the native priority.
• Parity tests against ScalarFp32MatmulKernel in JniKernelParityTest, including offset/strided operands (the JVM Panama vector kernels: accept slab-backed (offset) FP32 operands #1173 class of bug).
• KernelSupportMatrixTest regenerated: Float32 and Float16 show native-jni on Android.
• Device measurement with the M2-A5 harness: whisper-tiny encoder before/after.

Acceptance

• Bit-identical results to the scalar path on device for the attention shapes above.
• whisper-tiny.en encoder on a Pixel 7 Pro / 8a class phone at least 5× faster than the scalar Android baseline.

Related

• Ship the aarch64-verified NEON kernels to mobile: Apple targets + Android JNI for skainet-backend-native-cpu (measured 21 → 1.0 → 0.11 tok/s cliff) #920 — NEON kernels to mobile (the JNI tier this extends)
• FP16: native FFM matmul kernel (priority 100) to match BF16's tier #885 — FP16 native kernel on the FFM tier
• Android eager decode is ~83% non-matmul overhead: base DefaultCpuOps runs boxed per-element ops — port the JVM primitive fast paths (#920 follow-up) #949 — the non-matmul Android overhead this issue does not address (see the companion issue on fused elementwise/norm kernels)