RISC-V was the only major architecture without a get_L2_size() /
blas_set_parameter() implementation, so the GEMM cache-blocking parameters
(P/Q/R) were fixed at compile time regardless of the actual L2 cache size.
Because the blocking is now derived from the L2 cache detected at runtime
rather than a fixed compile-time constant, future RISC-V cores - which are
arriving with progressively larger and more varied L2 caches - get more
optimal blocking automatically, and the port gains the same runtime-tuning
hook x86 and LoongArch already use.
This adds, under ARCH_RISCV64:
- get_L2_size(): reads the level-2 (unified) cache size from Linux sysfs
(/sys/devices/system/cpu/cpu0/cache/index*/{level,size}); RISC-V has no
architectural cache-size query like x86 CPUID or LoongArch CPUCFG. Falls
back to 512 KB when sysfs is unavailable.
- blas_set_parameter(): scales each precision's packed-A dimension P from the
detected L2. The base blocking and the reference cache size come from the
active core's own param.h block (*_DEFAULT_P_BASE, RISCV_L2_REFERENCE_KB),
so the function carries no core-specific constants and is a no-op for cores
that do not opt in. Q and R keep their param.h defaults.
- driver/others/memory.c and common_macro.h: add ARCH_RISCV64 to the existing
architecture lists that call blas_set_parameter() and declare the runtime
parameter variables (sgemm_p, dgemm_p, ...).
- param.h RISCV64_ZVL256B: declares the per-core base blocking + reference and
maps SGEMM/DGEMM/CGEMM/ZGEMM DEFAULT_P to the runtime variables for static
builds; DYNAMIC_ARCH keeps the literals, since kernel/setparam-ref.c
init_parameter() initialises the gotoblas table from these macros and
blas_set_parameter() is not called on the dynamic path.
Only RISCV64_ZVL256B opts in so far; its base + reference are tuned on the
SpaceMiT X60, where a 512 KB L2 reproduces the stock blocking, so this is
performance-neutral on current hardware. Verified: a static RISCV64_ZVL256B
build reproduces the stock 128/128/16384 (SGEMM) and 64/128/8192 (DGEMM)
blocking; a DYNAMIC_ARCH build compiles cleanly (per-core setparam-ref objects
build without error); and get_L2_size() reads the correct size on both a
SpaceMiT X60 (512 KB L2) and a SiFive U74 / VisionFive 2 (2 MB L2).
A same-board controlled HPL A/B (VisionFive 2, TARGET=U74, N=10000,
NB=192, 2x2 grid, both libraries clean-built, residual PASSED) measures
4.97 vs 4.86 GFLOPS (+2.25%) for DGEMM_Q=256 over the inherited 128; at
a memory-filling N=27456 the tuned build sustains 5.41 vs 5.24 GFLOPS
(+3.24%). With HPL's NB=192, KC=256>=192 lets each trailing-update K
panel run in a single KC block, halving the C read-modify-write traffic
versus KC=128 (which splits K=192 into 128+64). A single-core P/Q sweep
over the real packing + micro-kernel objects confirms the GEMM is
compute-bound (whole grid within 3%), so P and R are left unchanged;
SGEMM_Q was already 240.
The SiFive U74 (RV64GC; e.g. StarFive JH7110 / VisionFive 2) is a scalar,
in-order core with no RVV, so today it falls back to RISCV64_GENERIC whose
S/D GEMM uses the generic 2x2 C micro-kernel.
Per the U74 Core Complex Manual (Table 169) fmadd.d has a 7-cycle latency
at repeat rate 1 (fully pipelined). A 2x2 tile exposes only 4 independent
accumulator chains -- fewer than the FMA latency -- so the FP pipe stalls
on the accumulator dependency, and the 1:1 load:FMA ratio saturates the
single load/store pipe ("only one outstanding line fill", manual 8.2).
This adds a portable 4x4 GEMM micro-kernel and a dedicated U74 target:
- kernel/generic/gemmkernel_4x4.c: 16-accumulator 4x4 register tile. 16
independent chains exceed the 7-cycle latency, and the load:FMA ratio
drops to 1:2. 16 acc + 4 A + 4 B fit RV64G's 32 FP registers without
spilling. Full 4/2/1 edge handling in both M and N.
- U74 target wiring: getarch.c (FORCE_U74, 32 KiB/64 B L1D, 2 MiB L2),
param.h (S/D UNROLL 4/4; complex stays 2/2), kernel/riscv64/KERNEL.U74
(S/D GEMM -> gemmkernel_4x4 + gemm_[nt]copy_4; S/D TRMM -> existing
trmmkernel_4x4), Makefile.prebuild + Makefile.riscv64 (-mtune=sifive-u74),
TargetList.txt, cpuid_riscv64.c.
The 4x4 kernel was verified numerically against a naive reference GEMM,
driven through the real gemm_tcopy_4 / gemm_ncopy_4 packing routines,
across 27,436 M/N/K x alpha combinations covering every 4/2/1 tail case:
worst absolute error 0.
Build with: make TARGET=U74
This accelerates SBGEMM/BGEMM by extending the existing 8x4 kernel to 8x8 (unrolling N by 8)
Not sure if it's a good idea to delete the previous 8x4 kernel?
Here are the speedups on single core Neoverse-V2 (SVE128) compared to prev state:
Per-shape speedup
M=N=K=64: SBGEMM 1.164x (16.42%), BGEMM 1.133x (13.30%)
M=N=K=128: SBGEMM 1.220x (22.02%), BGEMM 1.186x (18.56%)
M=N=K=256: SBGEMM 1.241x (24.08%), BGEMM 1.235x (23.54%)
M=N=K=512: SBGEMM 1.240x (23.95%), BGEMM 1.227x (22.75%)
M=N=K=1024: SBGEMM 1.251x (25.11%), BGEMM 1.232x (23.23%)
M=N=K=2048: SBGEMM 1.235x (23.47%), BGEMM 1.246x (24.64%)
Signed-off-by: Fadi Arafeh <fadi.arafeh@arm.com>
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>
Martin Kroeker