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_012nCkyKUguncLLJrH9K5o7m
The intent is to define this as nop, but previously it was then
immediately overriding it for various architectures, causing a compiler
warning on Windows.
The compinv function is invalid when building for BFLOAT16 and leads to the following warning:
`taking the absolute value of unsigned type 'bfloat16' (aka 'unsigned short') has no effect`.
Update pre-processor conditions to remove its definition when building for BFLOAT16.
Added HFLOAT16 support for RISCV64
Added shgemm_kernel_8x8 for RISCV64_ZVL128B and shgemm_kernel_16x8 for RISCV64_ZVL256B based on HFLOAT16
The instruction sets used are ZVFH and ZFH, which need to be supported by RVV1.0
Related to issue #5279
Co-authored-by Linjin Li <linjin_li@163.com>
1. Added bfloat16 based dot as new API: shdot
2. Implemented generic kernel and cooperlake-specific (AVX512-BF16) kernel for shdot
3. Added 4 conversion APIs for bfloat16 data type <=> single/double: shstobf16 shdtobf16 sbf16tos dbf16tod
shstobf16 -- convert single float array to bfloat16 array
shdtobf16 -- convert double float array to bfloat16 array
sbf16tos -- convert bfloat16 array to single float array
dbf16tod -- convert bfloat16 array to double float array
4. Implemented generic kernels for all 4 conversion APIs, and cooperlake-specific kernel for shstobf16 and shdtobf16
5. Update level1 thread facilitate functions and macros to support multi-threading for these new APIs
6. Fix Cooperlake platform detection/specify issue when under dynamic-arch building
7. Change the typedef of bfloat16 from unsigned short to more strict uint16_t
Signed-off-by: Chen, Guobing <guobing.chen@intel.com>
This patch adds support for bfloat16 data type matrix multiplication kernel.
For architectures that don't support bfloat16, it is defined as unsigned short
(2 bytes). Default unroll sizes can be changed as per architecture as done for
SGEMM and for now 8 and 4 are used for M and N. Size of ncopy/tcopy can be
changed as per architecture requirement and for now, size 2 is used.
Added shgemm in kernel/power/KERNEL.POWER9 and tested in powerpc64le and
powerpc64. For reference, added a small test compare_sgemm_shgemm.c to compare
sgemm and shgemm output.
This patch does not cover OpenBLAS test, benchmark and lapack tests for shgemm.
Complex type implementation can be discussed and added once this is approved.
Martin Kroeker