Latest Results
Add an asynchronous cancellation API for in-flight operations
Long-running BLAS calls (a large gemm can run for minutes) cannot
currently be interrupted: callers embedding OpenBLAS (e.g. the Julia
runtime responding to a user's ^C) can only wait for completion or kill
the process. Add a minimal cooperative cancellation protocol:
Every thread owns a pointer-sized generation slot in thread-local
storage, whose stable address is returned by openblas_cancel_token().
Instrumented compute drivers advance the slot to a fresh even
generation at operation entry on the issuing thread (forwarding the
slot and generation to worker threads through blas_arg_t) and poll it
at block granularity. openblas_cancel(token, loaded_token) - callable
from any thread - sets the cancel bit (bit 0) iff the slot still holds
loaded_token, so a canceller that loaded the value while an operation
was in flight stops exactly that operation, while stale or racing
requests either miss or dirty an already-dead generation, both
harmless. There is no object lifecycle: nothing to allocate, bind,
reset, or free.
A cancelled operation returns quickly, leaving its output buffer in an
unspecified partially-updated state that the caller must discard; every
synchronization point in the threaded driver is still executed, so
sibling threads never stall and the library remains consistent for
subsequent calls. Coverage: the level-3 gemm/symm/hemm drivers
(level3.c and level3_thread.c).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nCkyKUguncLLJrH9K5o7mKenoAIStaging:kf/cancellation riscv64: make RVV _rvv_v1 TRSM kernels VLEN-agnostic
The trsm_kernel_{LN,LT,RN,RT}_rvv_v1.c kernels tiled packed-A along M by
the runtime VSETVL_MAX, but the GEMM packing routine they interoperate
with packs by the compile-time GEMM_UNROLL_M. When VSETVL_MAX differs
from GEMM_UNROLL_M the diagonal-block stride assumed by solve() no longer
matches the packed layout and the solve reads/writes the wrong blocks.
On x280 the two coincide (both 16) so the existing target is unaffected,
but the kernels are not actually VLEN-agnostic: enabling them on a target
where VSETVL_MAX != GEMM_UNROLL_M (e.g. RISCV64_ZVL128B, unroll 8)
corrupts the result.
Replace the outer control flow so packed-A is tiled by GEMM_UNROLL_M with
a power-of-2 M remainder per N-block, matching the generic
kernel/generic/trsm_kernel_{LN,LT,RN,RT}.c drivers. The RVV-vectorized
solve() is retained unchanged.
Validated on SpaceMiT X60 (VLEN=256): S/D/C/Z TRSM over a full
Side/Uplo/Trans/Diag grid, m,n in {1,2,4,7,8,9,10,12,15,23}.
- ZVL128B (unroll 8): 8000/8000 cases pass; the original kernels
fail 408/1600 DTRSM (worst residual 0.89).hmeiland:fix-rvv-trsm-vlen-agnostic Latest Branches
0%
moluopro:remove-misspelled-bdsdc-sources 0%
KenoAIStaging:kf/cancellation 0%
hmeiland:fix-rvv-trsm-vlen-agnostic © 2026 CodSpeed Technology