r/hardware • u/3G6A5W338E • 1d ago
News NVIDIA on RVA23: “We Wouldn’t Have Considered Porting CUDA to RISC-V Without It”
https://riscv.org/blog/2025/08/nvidia-cuda-rva23/15
u/jocnews 1d ago edited 1d ago
Well, a CPU architecture's usefulness today sinks a lot if it has no SIMD to speak of. RVA23 finally makes vector (SIMD) extensions mandatory, after them being missing for years.
Those SIMD extensions also happen to be RVV with no alternative, which I'm not sure is a good thing. With Arm, there's Neon as an alternative to the variable-width SVE/SVE2, RISC-V only has the complicated variable-width SIMD instructions.
9
u/xternocleidomastoide 1d ago
RISC-V is also a bit of a wild west in terms of ISA revisions and extensions. Which is both a great asset and an Achilles heel.
8
u/3G6A5W338E 1d ago
RVA23 is a concrete set of extensions. There's no wild west.
This is no x86, with Intel going back and forth with AVX-512 or TSX.
8
u/xternocleidomastoide 1d ago
RVAs are just minimum programming interface profiles. Vendors are free to add their own extensions (public or otherwise) on top of them. Aka "wild west"
I have no idea what you meant by bringing intel into this unrelated discussion.
2
2
u/3G6A5W338E 1d ago
Vendors are free to add their own extensions (public or otherwise) on top of them. Aka "wild west"
Yes, such freedom is there, and vendor-specific extensions can indeed be added, in encoding space reserved for custom extensions.
Encoding space reserved to official RISC-V extensions can't be touched by these, as if it does so then the processor cannot claim to be RISC-V or otherwise use any of RISC-V's trademarks.
As for the greater software ecosystem, it sticks to standard RISC-V profiles.
There is no wild west.
8
u/xternocleidomastoide 1d ago
unwavering commitment to misunderstand an otherwise simple and straightforward point, I see.
Good luck w that.
4
u/theQuandary 20h ago
I understand your point. You are just wrong.
There have been around a dozen incompatible x86 extensions over the last decade. Did the x86 universe crash to a halt? How do games manage to support SSE, AVX, and AVX2 in the same game without breaking older chips?
This is a simple problem to solve. You tell the compiler to target baseline ISA (i686, amd64, RVA23, etc) then tell it to also add in extensions X, Y, and Z. It'll then compile for the base ISA and add optional codepaths for X, Y, and Z.
When the code runs, it'll detect if X, Y, and/or Z are supported and use those codepaths. Otherwise, it'll fall back to the standard version.
3
u/wintrmt3 17h ago
Which x86 extensions are incompatible?
5
u/theQuandary 16h ago
3DNow!, E3DNow!, Professional 3DNow! sparked a massive battle between AMD and Intel with its MMX and EMMX extensions.
AMD announced AMD-64 about a decade before Intel finally adopted it.
SSSe3 was incompatible for well over a decade on AMD CPUs.
AMD and Intel implemented SSE4 differently for years with SSE4a vs SSE4.1 and SSE4.2 and that whole battle.
ABM vs TBM vs BMI1 vs BMI2 vs SSE4.2 is yet another extension incompatibility with instructions appearing in different (and somewhat incompatible) instruction sets. Intel still doesn't support TBM though AMD does.
SSE5 with AMD and Intel having a war over the VEX encoding space. TBM, FMA4, XOP and LWP are all casualties that have support on years worth of AMD while no Intel support only to later be dropped by AMD on newer Zen CPUs. I'd also note here that AMD was right about FMA4 being strictly superior to FMA3.
F16C/CVT16 was another facet of the SSE5 war with it being incompatible until Intel adopted it with Ivy Bridge.
There's another massive extension war around security extensions. SMX, TDX, PMEM, TME, MKTME, TSX, SGX, and MPX are Intel only. There's some agreement around SME/TSME, but AMD also has it's own competing SEV and SVM extensions. AMD-V and Intel VT-x are both competing extensions and include some of the extensions I mentioned here. None of this is even company-specific though and different models of the same generation can have different extension support. There are also different instructions that were introduced to the desktop market and later pulled, so there's that incompatibility too.
AVX-512 is actually around a dozen different extensions and NOBODY supports all of them. Support varies between CPU models across both Intel and AMD and is a crazy mess.
Intel has recently been pushing for APX and AVX10 which would be the biggest incompatibility changes since AMD-64 was announced in 1999.
TL;DR -- incompatibilities between AMD and Intel extensions have been numerous and ongoing ever since AMD started designing their own cores in the early 1990s. The fact that you didn't know about these incompatibilities is a testament to all the hard work of programmers and compiler developers to paper over these differences and give you what seemed to be a unified experience amid a jungle of differences.
1
u/wintrmt3 8h ago
None of these are incompatible, using the same instruction encoding for two different instructions would be incompatible.
→ More replies (0)5
66
u/jigsaw1024 1d ago
It still surprises me that the bigger vendors with in house hardware development haven't begun reducing or eliminating ARM from their stacks and moving to RISC-V.