Merge risc-v branch into develop

[luhenry]

Hello 👋,

With RISC-V gaining in popularity and adoption, it becomes more and more important for OpenBLAS to have support for RISC-V. Luckily, there has been plenty of awesome contributions to make that happen, thanks to all the contributors!!

However, that support is AFAIU still in a dedicated risc-v branch and not merged into the main develop branch. I read over the other RISC-V related issues and I couldn't get a good sense of what was blocking that merge to happen.

That's also important as projects using OpenBLAS (like Numpy for example) don't have per-platform/per-target references to OpenBLAS, meaning it's usually referencing develop and not risc-v. That's important for platforms other than C910V which haven't been merged into develop just yet like CPU_RISCV64_ZVL256B.

Let me know if there is anything I'm clearly misunderstanding, there is very likely something I'm missing.

Thank you!

[martin-frbg]

"Generic" support and C910V (RVV-0.7) have been in the develop branch (and multiple releases) for quite some time. Anything without vector hardware is going to be (a) of limited interest and (b) supported by the "generic" C kernels, anything that has it is stuck in the mess of incompatible and/or unfinished specifications. As far as I know, RVV-1.0 still barely has draft status and it's (naturally) much the same with the C intrinsics. I've asked xianyi (who is involved with riscv system building) for his opinion a couple of days ago but haven't heard back.

[luhenry]

As far as I know, RVV-1.0 still barely has draft status and it's (naturally) much the same with the C intrinsics

RVV 1.0 has been release since September 2021, and is considered stable. Hardware has already been released and more is coming. RVV 1.0 is way further than draft status. See https://github.com/riscv/riscv-v-spec/releases/tag/v1.0

The C intrinsics are being frozen as we speak, are fully supported in Clang 17 and GCC 14 (upcoming version), and are also actively used by existing projects (https://github.com/shibatch/sleef or https://github.com/xtensor-stack/xsimd/ for example). See https://github.com/riscv-non-isa/rvv-intrinsic-doc/releases/tag/v1.0-rc0

[martin-frbg]

apologies for not looking it up - it is the intrinsics api that's still in flux, not rvv per se

[martin-frbg]

are you working with/on something that would make use of ZVL256B kernels (or X280 for that matter) and would be able to test on relevant hardware ?

[luhenry]

are you working with/on something that would make use of ZVL256B kernels (or X280 for that matter) and would be able to test on relevant hardware ?

I've interest in ZVL256B indeed, but no hardware to test it on yet. We have cycle accurate emulators that can help us understand the expected performance of these kernels, but we can't disclose any numbers (welcome to the world of hardware...).

[martin-frbg]

currently blocking on (recent comments to) #3919 - still no response from xianyi but one of the recent issues raised in #3919 is ensuring that the C910 code from the risc-v branch compiles with both "old" and "new" compilers

[sergei-lewis]

PR 4439 resolves these

[sergei-lewis]

I've opened PR 4472 to continue the discussion as much as anything else. It's a huge changeset but the situation will only get worse the longer the forks are allowed to diverge :)

I've tested the x86, RISCV64_GENERIC, RISCV64_ZVL128B and RISCV64_ZVL256B targets. Leaving the PR as draft until CI completes for everything else. I plan to follow up with a separate PR for adding the new targets to docs and CI on the develop branch once they are available there, as well as extending cpuid_riscv64.c to allow them to be detected.

[martin-frbg]

merged now