Digital and software freedom/rights advocate from Slovenia, Europe. Also a member of the Pirate party. You can find me on Mastodon: @JRepin@mstdn.io
RISC-V @lemmy.ml RISC-V Market Analysis Report 2026 - Market Adoption Accelerates
RISC-V @lemmy.ml felix86 x86 and x86-64 emulator for RISC-V — Finally, some gaming!
RISC-V @lemmy.ml Initial Benchmarks Of The SpacemiT K3 RVA23 RISC-V CPU With The K3 Pico-ITX
RISC-V @lemmy.ml Baylibre Partners with SpacemiT to Bring Android 16 to RISC-V
Technology @lemmy.world Big AI's Regulatory Capture: Mapping Industry Interference and Government Complicity
Programming @programming.dev OpenCL 3.1 is here
RISC-V @lemmy.ml openRuyi — A Linux Distribution for RISC-V
RISC-V @lemmy.ml Sail RISC-V Golden Model v0.11
RISC-V @lemmy.ml RISC-V Ratified Specifications Library (now all available in HTML)
Linux @programming.dev Kubuntu 26.04 LTS (Resolute Raccoon) Released
RISC-V @lemmy.ml RVA23 Ends Speculation’s Monopoly in RISC-V CPUs
RISC-V @lemmy.ml SpacemiT K3 – World's First RVA23 Standard AI CPU
RISC-V @lemmy.ml SpacemiT K3 16-core RISC-V SoC system information and (early) benchmarks
Europe @feddit.org Digital Omnibus: EU Commission wants to wreck core GDPR principles
Europe @feddit.org EU Commission about to wreck core principles of the GDPR
Open Source @lemmy.ml Qt Creator 18 released
Technology @lemmy.world International Criminal Court to ditch Microsoft Office for European open source alternative
Technology @lemmy.ml International Criminal Court to ditch Microsoft Office for European open source alternative
Technology @lemmy.ml RISC-V takes first step toward international standardization as ISO/IEC JTC1 grants PAS Submitter status
RISC-V @lemmy.ml RISC-V takes first step toward international standardization as ISO/IEC JTC1 grants PAS Submitter status
- JumpDeleted
Permanently Deleted
- JumpDeleted
Permanently Deleted










As far as I found out about this until now is that the X100 (normal cores) and A100 (AI core) are almost the same RISC-V cores, mainly only different in th RVV vector registers length spec VLEN (256 vs. 1024). The RISC-V Unprivileged specification in chapter 31.1.2. Implementation-defined Constant Parameters says this about cores with different VLENs:
So regarding this there may not be so much of a problem.
Another probably bigger problem is that the A100 cores are not really RVA23 compliant, since they do not support Hypervisor Extension: RVH 1.0 which is required by RVA23 and is only supported on normal X100 cores. But then again usual user-level code does not use the H extension instructions. So maybe even this might not be such a problem for most user-space code.
Anyways as things currently stand : the code only gets executed automaticaly and scheduled onto 8 X100 cores, A100 cores are ignored, even if it could also run on A100. If you are sure the code can run on A100, you must manualy move/execute them on A100 (and again they are confined to only the A100 cores).
Probably the Linux kernel and scheduling needs to get some upgraded logic to make it able to freeely move code among X100 and A100 in the future. And again it depends on how VLEN is treated, is it fixed in the code or can it dynamically acommodate depending on the core it is currently on.
Oh and A100 cores have support for vendor-specific SpacemiT IME (Integrated Matrix Extension) , which is based on some proposals for future RISC-V extension, but yeah nothing official yet. And looks like these are not supported on X100.
As for SIMD. RISC-V does not have anything official yet, since the normal and more general V vector extension should be used in most (if not all common) cases to replace the SIMD instructions. There are some good cases for SIMD way of ding things but yeah RISC-V has nothing official yet, they are working on a P Packed-SIMD extension that may be available sometime in the future. As far as I could see neither X100 nor A100 support any of these P instructions.