[michalharakal]

Summary

Third step of the JVM ↔ wasm compute parity series (after #1363 and #1364): the ternary kernels join the browser sidecar, and the JVM gets the direct x · Wᵀ kernel the sidecar has had since 0.61.0. Both directions of parity, both through the shared C tree.

Wasm: ternary kernels in the sidecar.

• native/build-wasm.sh compiles skainet_ternary_f32.c and bitnet_gemv.c and exports skainet_ternary_f32_gemv, skainet_ternary_lmhead_stage1, skainet_bitnet_gemv_tq2_0.
• The portable branch of skainet_ternary_f32.c (what MSVC and Emscripten build — the vendored NeoGPU file needs native pthreads and NEON) now holds the vendored kernel's 256-entry decode table as a compile-time constant (no init guard to race on), has a SIMD128 body for both the gemv and the fused four-plane lm_head (one LUT row is one f32x4 of decoded codes against four activations), and threads over output rows through the shared row pool. The scalar MSVC body computes exactly what it did before.
• bitnet_gemv.c: a SIMD128 body for the TQ2_0 block (same unpack as the NEON one, i32x4.dot_i16x8_s on widened halves) and row threading over output rows on every tier; the NEON and scalar block bodies are unchanged.
• WasmTernaryKernelPack (installed by WasmSimd.install()) registers three native faces — WasmTernaryF32Gemv, WasmTernaryLmhead, WasmBitNetGemv — through the same TernaryF32KernelPack / TernaryPlanesKernelPack / TernaryKernelPacks installs the JVM FFM and Android JNI packs use, so the dispatch keys and the kernel names (ternary_f32_gemv/wasm-simd128, …) are the same shape. Weights are uploaded once and stay resident; activation and output cross per call.

JVM: direct x · Wᵀ.

• Fp32MatmulWtKernel and KernelProvider.matmulFp32Wt() (common), Fp32MemSegMatmulWtKernel and MemSegKernelProvider.matmulFp32WtMemSeg() (JVM) expose skainet_fp32_matmul_wt. NativeFp32MatmulWtKernel binds it with a heap face and a segment face; NativeKernelProvider carries both; KernelProvider.supports("matmul_wt", ["Float32", "Float32"]) reports it.
• DefaultCpuOpsJvm.matmulWeightTransposed multiplies a dense [out, in] FP32 weight in place through the segment face: a segment-backed weight is read where it lies, a heap weight is made resident off-heap once (bounded cache keyed on the TensorData, replacing the transposed-copy cache for that case). No [k, n] transpose is materialised; the C kernel threads over output rows. Without the native library the cached-transpose path serves as before.
• WasmKernelProvider.matmulFp32Wt() (WasmFp32MatmulWtKernel) exposes the same accessor on wasm; WasmCpuOps.matmulWeightTransposed routes through it.

Matrix, bench, docs.

• Kernel support matrix: a fourth table, Kernel packs (view dispatch) — BitNet-b1.58 (FP32 activations), BitNet-planes, TQ2_0 (int8 activations) and Float32 x·Wᵀ direct per platform; the JVM cells are gated against the FFM provider and pack on the runner.
• engine-fp32-linear in jvm-cpu-publish and wasm-bench: a Linear layer's x · Wᵀ (16 tokens, 768 → 3072) through ctx.ops.matmulWeightTransposed; --provider panama measures the cached-transpose path, --provider ffm the direct kernel.
• eager-execution: ternary rows gain the wasm column, a x · Wᵀ direct row, the "Wasm ternary / BitNet" gap is removed.

Measured (Node, 12-core laptop; JVM on the same machine)

Scenario	JVM	wasm scalar	wasm simd128-st	wasm simd128-mt
engine-ternary-f32-gemv (2560×6912)	15.4 Gops (--provider ffm)	skipped (no kernel) → runs	16.5 Gops	55.3 Gops
engine-fp32-linear (16×768 · (3072×768)ᵀ via ctx.ops.matmulWeightTransposed)	panama (cached transpose + Vector GEMM) 5.0 GFLOPS → ffm direct 30.8 GFLOPS; scalar 1.1	2.6	7.8	30.0

The other engine-* scenarios are unchanged against #1364 within noise. On the JVM the direct kernel is 6× the cached-transpose path for this shape and allocates no transposed copy.

Verification

• :skainet-backends:skainet-backend-wasm-simd:wasmJsNodeTest — new: ternary f32 gemv (two activation rows, 600 output rows so the mt sidecar splits them), planes lm_head and TQ2_0 bitnet gemv through KernelDispatch against the Kotlin reference kernels with the serving kernel name asserted; the direct x · Wᵀ provider kernel resident and windowed. Plus the existing eight tests.
• :skainet-backends:skainet-backend-native-cpu:jvmTest — new NativeFp32MatmulWtKernelTest (heap face vs row-dot reference incl. the threaded regime, offsets, k == 0, segment face bit-identical to the heap face, provider accessors) and JvmDirectWeightTransposedTest (ops layer, heap and segment-backed weights, activation ranks 1–3, threaded rows, vs transpose-then-matmul); KernelSupportMatrixTest with the new table; the existing ternary FFM tests cover the vendored branch (unchanged).
• C: the changed files compiled for wasm32 SIMD128 (emcc 4.0.14), the host portable branch (clang, scalar) and aarch64 NEON (bitnet_gemv.c, syntax check); CI macos-arm64 runs the NEON bitnet_gemv body with its row threading through the JNI-shaped C.
• generateKernelMatrix, apiDump, scripts/pr-gate.sh --quick, full gate.

Next in the series: resident activations (Storage.WasmLinear) and sidecar elementwise/activation kernels, then fused softmax/norms/SDPA on both tiers, then the browser IO gaps.