INT4 Scheduler Emulation and INT8 State Leakage

Tools: examples/i4.c + examples/test_matmul.c + examples/test_speed.c Environment: RK3588 target board, governors pinned.

The Problem

Recent commits introduced regressions in two critical paths:

1. INT4 Multi-Row Emulation Bounds (SIGSEGV): The emulated loop inside i4_mcworker iterating over multi-row chunk splits miscalculated array bounds when partitioning activation buffers for manual M-dimension slicing, leading to segfaults on sizes not perfectly divisible by the chunk loop.
2. INT8 Context State Leakage: Moving from disjoint single-submission requests directly to chained ork_mm_run_chain_i8 multi-submissions caused memory overlaps and incorrect matrix results due to the NPU's physical pipeline registers persisting state. The internal datapath lacked an explicit flush command between disparate chaining modes.

The Solution

1. Manual Chunking Loop Boundaries: Fixed the activation slice pointer math and bound checks inside i4_mcworker to guarantee memory-safe boundaries during partial $M$-chunks. The INT4 driver now perfectly segments row computations without overflowing buffer dimensions.
2. Explicit NPU Reset: Intercepted mode switches inside ork_mm_run_chain_i8 to aggressively issue a self-healing RKNPU_ACT_RESET ioctl, safely clearing residual cache descriptors and physical pipeline states before submitting new chained tasks on a dirty handle.

Strict Metric and Testing Enforcement

We constructed rigorous correctness bounds and merged them directly into the validation suite to prevent future degradation:

• test_matmul.c: Now aggressively tests the precise leakage pattern by running disjoint single-task matmuls immediately followed by multiple check_chain_i8 multi-submissions on the exact same dirty context to catch any missing resets.
• i4.c: Automatically fuzzes the manual boundary sizes testing $M \in {1, 2, 3, 4, 8}$ across synthetic memory allocations to crash instantly if the chunk boundaries violate array bounds.
• test_speed.c (NEW): Checks multi-core prefill latency metrics across cores. Asserts that the single-core execution time scaled out to N-cores maintains a $\ge 1.4\times$ parallelization multiplier, and absolute execution latency for $M=512, K=2048, N=2048$ workloads does not exceed $9000 \mu s$, verifying that our regression fixes didn't trigger threadpool dragging artifacts.

Verdict

✅ Success. The driver correctly processes complex INT4 chaining dimensions and guarantees clean execution contexts during mode switching. Multi-core latency thresholds enforce that prefill speed remains stable.