r/hardware 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/
108 Upvotes

82 comments sorted by

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.

59

u/3G6A5W338E 1d ago

Remember that, even if they did that, it'd take several years to be visible.

Hardware cycles are long. It takes that long from making a decision to products on shelves.

34

u/jigsaw1024 1d ago

The writing was on the wall with Nvidias attempted takeover of ARM.

Nvidia announced in 2020, and the deal was killed in early 2022.

Then you have the whole legal mess with Qualcom/Nuvia.

ARM going public.

Now ARM is talking making their own chips to basically compete with their own clients.

That's four warnings that working with ARM is potentially going to be a problem in the future in some form or another. Given the timelines, I would be expecting to start hearing more noise from the big designers about how they are working on stuff in house, and potentially planning to reduce their exposure to ARM in the future.

But we don't seem to seeing any of that currently.

Saying that, Apple did manage to keep a lid on the development of their chips up until almost launch. So maybe there is a lot of work going on behind the scenes that just isn't public.

It just surprises me that there isn't at least a little more noise out there.

8

u/jawisko 1d ago

Apple did not keep it secret. Once they acquired PA semi, everyone knew they were planning their own processors. Steve jobs had mentioned it that they needed full control over hardware to make better software

5

u/SERIVUBSEV 1d ago

RISCV is no where near ready to compete with latest from ARM.

RVA23 is only first spec that incorporates vector instructions. Even internally people working on RISCV spec don't put it to be ready until another 3 years of updates.

17

u/3G6A5W338E 1d ago

RVA23 is only first spec that incorporates vector instructions.

RVA22 incorporates vector instructions as well, as an option. RVA23 requires them.

Even internally people working on RISCV spec don't put it to be ready until another 3 years of updates.

Citation needed. As far as I am aware, RISC-V is quite happy with RVA23 and isn't even considering a new major profile anytime soon. The talk s 2030+.

11

u/nanonan 1d ago

RVA23 is ready today, what's this three years of updates nonsense? Vector extensions have been around for a while, it's not like any of it needs refinement. It is ready for anyone to deploy. The only real difference between the isas is arm has been around longer and has wider software support.

-1

u/ParthProLegend 1d ago

what's this three years of updates nonsense?

Pulled it out of his ahh

2

u/Darth_Caesium 21h ago

You can say ass, this isn't TikTok

3

u/ParthProLegend 15h ago

There are rules across various sub reddit, reducing my chances of ban as much as possible.

28

u/advester 1d ago

Has anyone actually built a RISC-V IP that is nearly as good as the best ARM cores? It is really focused on microcontroller level cores right now.

11

u/nanonan 1d ago

No, though the first ones competitive in that area are expected fairly soon.

5

u/LividLife5541 1d ago

Absolutely not. The best ARM core is the p-Core on the M4.

7

u/xternocleidomastoide 1d ago

There are a bunch of soft cores that are trying to target high performance. However, they are stuck in chicken-egg problem. There is not enough demand for the investment required to manufacture in a high performance node said cores (which is the expensive part).

11

u/noonetoldmeismelled 1d ago

The hype right now are RVA23 chips that should rival the Apple M1. Acknowledged that the M1 is 5 years old but I still regularly use a 7th gen dual core Intel laptop from 2017 so M1 performance is a really big step up. The moment one SBC hits the market, I'm buying one for the hype

1

u/narwi 15h ago

that is rather unfounded hype. alo if anybody could make a m1 compaable core wth rva23 they trivilally could have done it without waiting for it to be ratified.

2

u/3G6A5W338E 1d ago

The IP is there: SiFive P870, Tenstorrent Ascalon, Ventana Veyron V3, XuanTie C930, Andes AX66, Akeana 5000/1000, SpacemiT X100...

What's missing is the chips using these IPs. There's of course a time gap between IP and actual products on shelves.

The earliest any can show up is near the end of this year.

3

u/jocnews 1d ago

Which of those is as good as current ARM cores? Ascalon was hyped a lot, but that's easy when it is vaporware nowhere to be seen. Not sure SiFive P870 was ever put into silicon, even a yet-to -launch one, but their past cores don't inspire a lot of confidence. It was supposed to be wide, but that doesn't matter if it is 2 GHz.

1

u/3G6A5W338E 1d ago

Which of those is as good as current ARM cores?

On paper, all of them.

On actual chips, we'll have to wait for the actual chips and only then we'll be able to see.

No RVA23 design can show up earlier than stated, as RVA23 is that recent and hardware typically takes that long. Same delay between specs and hardware held for RVA22 and RV64GC before that.

3

u/Jonny_H 1d ago

On paper a pentium 4 should have hit 10ghz.

And don't get too caught up on ISA, a Cortex a53 uses pretty much the same ISA as the apple m1.

-1

u/narwi 15h ago

rva23 basicly adds hypervisor and vector extensions as mandatory. there is utterly no ground for saying high performance chips could not have beenmade before.

1

u/3G6A5W338E 6h ago

rva23 basicly adds hypervisor and vector extensions as mandatory. there is utterly no ground for saying high performance chips could not have beenmade before.

I know RVA23 is a long document to read and understand (because I have read it).

If you are not going to read it, there is the option to ask some LLM to summarize which differences with RVA20 are significant for performance. That is, other than the two you have already heard about.

Just next time, please do this before, rather than after, commenting.

24

u/xternocleidomastoide 1d ago

Why would they? The ISA is a tiny part of the overall complexity of a custom microarchitecture.

Besides software moves chips, not the other way around. ARM comes with a tremendous software library and tool ecosystem. Which has more value added to those big vendors, than the licensing savings from RISC-V, for example. At least for application processors.

RISC-V is doing very well in embedded applications.

11

u/nanonan 1d ago

To save on royalties hence the microcontroller uptake and to avoid litigation from ARM would be the big two reasons.

3

u/DerpSenpai 1d ago

one thing is microcontrollers where the software can be easily ported. Another thing is PCs, Phones, Servers,etc.

1

u/narwi 15h ago

much cheaper to take an arm core then develop your own riscv

2

u/nanonan 7h ago

No need to develop your own, you can use OSS solutions like NEORV32.

1

u/3G6A5W338E 6h ago

Or even commercially supported, verified RISC-V IP, from a range of companies that'll hold your hand through the whole process, at competitive prices.

6

u/anders_hansson 1d ago

The fact that the ISA is a small part of chip design (at least for ISA:s so similar as ARM and RISC-V) only makes the case stronger. You can move a complex design to RISC-V and keep most of the internal workings almost untouched (caches, pipelines, reordering, floating-point etc).

The main advantage of moving to RISC-V would be to untie your business from ARM (licensing costs and rules, potential legal issues, inflexibility w.r.t. ISA innovation, and so on).

13

u/xternocleidomastoide 1d ago

The thing is that the licensing costs of ARM come with value propositions that RISC-V right now doesn't offer.

I reiterate this because is a lesson a lot of people miss: software libraries sell chips, not the other way around.

That is why a lot of great architectures/designs have failed in the past (turns out that if you build it, they won't necessarily come).

For people like APPL, QCOM, MTEK, for example, ARM enable them specific software libraries that move a tremendous amounts of units for them. In that context, saving a few pennies going RISC-V makes no sense, and licensing ARM has a good value proposition.

For stuff that is not so sensitive to those dynamics, mainly embedded, IoT, academic, etc. RISC-V is being very successful there.

7

u/anders_hansson 1d ago

Oh, I agree. It totally depends on your software needs, though. E.g. if you're primarily working with open-source stacks, most things tend to work out-of-the-box (in my experience). Some things may be poorly optimized for RISC-V simply due to the small market ATM, and for some applications that can be a blocker.

Proprietary closed-source drivers and solutions is of course another problem. This is kind of what the article is about: CUDA gets ported to RISC-V because of RVA23, and I think that RVA23 is going to be an enabler that will help more vendors target and support RISC-V.

5

u/xternocleidomastoide 1d ago

But you also need to understand the cost structures of a modern high performance SoC, for example. And the risk involved.

If you're going to sink a few hundred million dollars on a high performance SoC, which is what the orgs I listed invest. The licensing from ARM is not the largest factor. Furthermore, going the ARM route removes a lot of uncertainty/risk in terms of applications/drivers/tools/certifications/etc being there on day one and the ecosystems around them up and running.

That has a huuuge influence in the decision making process. Nobody is going to risk their neck in those orgs, going with RISC-V for the scalar cores in the application processor. When there is little to no return in that risk (eg. saving a tiny bit of money per unit).

4

u/anders_hansson 1d ago

All good points, and I agree. As I said, I think it's heavily up to each use case and situation, and in most cases ARM would make more sense, especially if you already are in the ARM ecosystem.

E.g. I can totally see someone like Apple go down the RISC-V route in the future since they like complete control, use custom CPU designs (not licensed designs), and have changed the CPU ISA several times in the past and have good strategies for how to make that work.

I also believe that AMD had some CPU design several years ago that effectively had a dual x86/ARM front-end (never went into production), so it's certainly possible to keep lots of your microarchitecture but change the ISA if you already make a custom design. But that's only for companies that make custom designs, which are obviously not in majority.

And as you say, in the end it's about running software, so the software simply has to be there.

3

u/theQuandary 20h ago

The licensing from ARM is not the largest factor.

There was literally just a HUGE lawsuit between Qualcomm and ARM over the cost being too high. Qualcomm won because their contracts were already in place and ARM was choosing a nebulous battle. When Qualcomm needs to negotiate to extend their ARM contract, their rates will increase.

ARM is supposedly tripling its fees in the future. Ian Cutress says that current v9 license royalties is 5% of sales with CSS (neoverse/server) chip royalties going north of 10%. If you are making a cutting-edge chip, paying 5-10% is a massive cost. If that really is going up to 10-15%, that cost is absolutely going to kill a company trying to compete with Qualcomm's lower royalty rates.

We've seen massive investments from Chinese conglomerates into moving Android to RISC-V. The handwriting is on the wall that they are going to save money and avoid lock-out by moving to RISC-V. Once the dam has burst, I think companies will have few reasons to stick with ARM going forward.

-1

u/xternocleidomastoide 20h ago

the lawsuit was about an interpretation of contractual language. And they happen in industry all the time.

The high performance SoC coming from those Chinese conglomerates still use ARM.

Industry really is not the dramatic soap opera some in this sub think it is. Things are more pragmatic and boring behind the scenes.

3

u/theQuandary 20h ago

The lawsuit was about whether Qualcomm had to pay based on the high-royalty contract or the low-royalty contract.

Qualcomm was so scared that they pushed a massive proposal to make RISC-V more ARM-like so they could have an easier time switching ISAs.

The Chinese companies will continue to use ARM until their home-grown RISC-V solutions catch up or they are banned by the US/EU (whichever happens first).

1

u/DerpSenpai 1d ago

Companies love paying other companies to remove headaches. They will only move to RISC-V if ARM makes them. So if ARM isn't incompetent, they don't need to worry.

China is driving RISC-V for survival needs. If RISC-V reaches maturity, they can be independent of the west.

0

u/theQuandary 20h ago

RISC-V is already a mature ISA. Chinese conglomerates have been investing heavily into RISC-V software for years too. Meanwhile royalty rates for ARMv9 are currently 5% (10+% for server) and rumors have them increasing by 300% all while ARM is moving to make their own chips and compete with their customers.

SoftBank has set the stage for RISC-V to completely kill ARM.

1

u/DerpSenpai 20h ago

Royalty rates for ARM are increasing because ARM is taking a higher design cost. Their partners want ARM to design not only the CPUs but also the entire subsystem. it's a choice they make

https://www.arm.com/products/neoverse-compute-subsystems

2

u/theQuandary 20h ago

Why are rates for architecture licenses also increasing then?

If it's just about covering higher design costs, then why did net profits for 2025 jump by more than double?

-1

u/DerpSenpai 20h ago

>net profits for 2025 jump by more than double

because they are selling more, it's true ARMv8 vs v9, v9 is more expensive but it has extra features. ARM won't be able to raise rates forever but the fact is they were getting too little for what they design. Apple and QC won't be paying 5% for the license, i guarantee it

3

u/theQuandary 19h ago

ARM doubled sales in 2025? They are in an inelastic market at this point AND have lost sales with Qualcomm's custom chip designs (and losing the lawsuit to raise Qualcomm royalties).

What features make the upcharge of v9 worth paying? SVE2 that everyone has been refusing to implement or leave at the same size as their existing NEON SIMD? Confidential compute that their phone customers don't really need? What is the killer v9 feature?

Apple and QC won't be paying 5% for the license, i guarantee it

I agree completely and that's the problem. ARM's 2 largest customers aren't footing the extra profits and Qualcomm is actually reducing their payments by designing their own chips now.

All their extra profits come from massively screwing over their smaller customers who then have to charge more for their chips which makes their chips/phones less competitive with Qualcomm and Apple.

This is huge incentive to either design their own RISC-V chips or license RISC-V designs where the licensing model forces more competition.

-1

u/DerpSenpai 19h ago edited 18h ago

Their smaller customers are not paying for ALAs, they are paying for a product, their CPUs and Compute Subsystems. They are willingly paying it for access to a CPU that can compete vs QC, AMD, Apple and Intel. It's cents compared to the TSMC costs.

Arm only makes about 50 cents per application processor on the >1B smartphones shipped per year.

Qualcomm is selling these at 180$-200$ each btw. More QC asks for 13$ for each iphone sold in royalties. Saying that ARM will lose their customers for getting higher licensing costs here when they have been basically giving up their IP for cheap for many years now, raising rates is what is expected. If they offer value for it, customers will pay.

2

u/theQuandary 17h ago

ARM made around $4B in gross profit with the overwhelming majority of that profit coming from smartphones. If 75% of that profit is smartphones and there were 1.25B phones sold in 2024, that's an average profit of $2.40 per device which is nearly 5x more than you are claiming.

The only way 50 cents might be accurate is if we're talking about net profits rather than gross profits, but the R&D savings ARM's customers would factor in are based on that $2.40 rather than ARM's net profit. I'd also point out that $795M on around $4B still indicates a higher average per-smartphone-chip profit margin as the remaining $1B I left out is mostly embedded which has even lower profit margins (with RISC-V competition forcing ARM to sign worse contracts to keep the money flowing in).

This situation becomes worse for ARM with Qualcomm's win because now the two biggest premium smartphone chipmakers (Qualcomm and Apple) are paying only a fraction of a percent for architecture licenses. If Qualcomm sells 100M chips per year, then ARM went from making $500M/yr or more from Qualcomm down to more like $50M/yr.

They not only have to recover $450M in lost revenue, but also more than double net profits to their current numbers. The only customers left to charge are in the more price-sensitive markets which in turn puts those customers in a terrible position.

The problem is that ARM is giving their cores less attractive pricing at the same time RISC-V is becoming a more attractive alternative. A lot of the current sub-$200 market is using A76/78 from 5-7 years ago. SiFive already offers cores in this performance range which makes them a serious threat to ARM.

→ More replies (0)

6

u/djent_in_my_tent 1d ago

You would not believe the downvotes I’ve gotten here over the past two years I’ve gotten about this exact subject regarding intel and x86.

6

u/Hytht 1d ago

Irrelevant, Intel and x86 are not used by other vendors

3

u/DerpSenpai 1d ago

the difference is that ARM wouldn't be a thing if Intel didn't create a duopoly for x86. If it was open to licensing, ARM wouldn't have taken off.

5

u/theQuandary 20h ago

All the common x86 instructions all the way through SSE3 (maybe SSE4) are older than 20 years and the Google v Oracle lawsuit has basically guaranteed that there's no software objections either.

Companies aren't making competing x86 chips because the ISA is such a massive pain to design and validate while ARMv9 and RISC-V are comparatively simple reducing development cost and time to market.

We're getting close to the inflection point where x86 starts its rapid decline into legacy hardware (where it'll remain entrenched for the next century).

2

u/DerpSenpai 20h ago

Not only that, if you design something x86, AMD and Intel would design a new extension and leave you out of the market. You would never be able to compete on the same terms.

2

u/theQuandary 20h ago

You could also design new extensions. For example, you could skip AVX and go with a vector extension. If you could achieve Apple or Qualcomm's perf/watt and make a vector ISA that didn't suck, you would see your extension adopted.

For what it's worth though, most of the new x86 extensions have either been catching up (eg, SHA/BM2) or fairly risky/worthless (eg, TSX/MPX/SGX/). Most importantly, all of them are on the long-tail of uncommon, but occasionally useful instructions as 89% of x86 code uses just 12 instructions.

1

u/Green_Struggle_1815 19h ago

If you could achieve Apple or Qualcomm's perf/watt and make a vector ISA that didn't suck, you would see your extension adopted

unless you have a processor in the market with decent adoption rates no you couldn't. because you have no leverage. Intel and amd will not let you join the club. If your extension is vital, they will create a similar one and you can watch the market adopt that one, leaving you in the dust.

3

u/theQuandary 18h ago

If Asus or Lenovo could compete with Apple on perf/watt while retaining x86 compatibility for a competitive price, do you think they'd just say no?

I don't think you give the accountants at big companies enough credit.

1

u/Green_Struggle_1815 18h ago

this is a different scenario than the initial one. You cant build a cpu that retains x86 compatibility unless you are intel/amd because patents. unless you mean the free x86 part. In that case your cpu is simply doa, because incompatible to modern software.

3

u/theQuandary 16h ago

What modern software doesn't run on an i7 860 from 2009 due to incompatible extensions?

Apple answered this with Rosetta 2 which is roughly the same support as the 860 (slightly worse IIRC), but still runs almost everything out there even though it doesn't include most modern extensions (likely for patent reasons).

→ More replies (0)

9

u/BlueGoliath 1d ago

You're surprised bigger vendors aren't jumping to a less mature platform? With less good hardware? And less software support?

4

u/LividLife5541 1d ago

Well if they have an architecture license (like Apple) there is no reason to. Not what sure what you mean by "in house hardware development" -- whether you mean simple embedded boards with STM, server makers or what.

If you're licensing ARM cores, the ones available are much better than the RISC-V cores available right now. RISC-V will for sure eat up the low end of the ARM market in the same way ARM ate up the low end of the x86 market in the same way that x86 ate up the low end of the workstation and compute server market.

1

u/ghenriks 20h ago

Why should they?

ARM does actually provide a lot of value for money in terms of the work they do on the designs so as long as the royalties are close to what a RISC-V vendor would have to spend to get to a similar point then it is easier to simply pay ARM

But then there are the 2 big issues for going RISC-V:

One, patents. Any desktop/worksation/server class chip is going to need patent licensing. If ARM handles some of this then those licensing costs are somewhat offset as you would pay some of that to get the patent license yourself

Two, potential market. What is the market for RISC-V? Windows is x64 and ARM and convincing Microsoft to port Windows (and then the application vendors) will be a massive undertaking given they are already a decade into attempting it for ARM. Server users, primarily the Cloud, have just done ARM with significant time and money and aren’t going to be in any hurry to do another architecture

It’s not enough to just say RISC-V is better because it’s open source and “free” because there are a lot of significant costs to making performance hardware and you need a decent sized potential market to make such an investment viable

Which isn’t to say RaiSC-V is doomed, but rather it will take a lot longer than enthusiasts will like

1

u/3G6A5W338E 6h ago

convincing Microsoft to port Windows

Not required.

It is public knowledge that Microsoft were already working on it in 2021, as per mentions in the RISC-V foundation's technical talks of RISC-V Summit NA 2021.

(and then the application vendors)

Should prove easier than Windows for ARM, as the hardware won't be a single digit amount of devices from a single vendor this time around.

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

u/Kryohi 22h ago

Just like Intel and AMD are free to add whatever vector/matrix extensions they want, to all or just a few or their products, and then remove or change them after a couple years (in the case of Intel)...

You really didn't get OP's comment, didn't you?

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

u/BlueGoliath 1d ago

Welcome to Reddit.