Discussion RISC V Latest Developments Discussion [No Politics]

Doug S said:

That's not a problem with the RISC-V ISA, it is a problem of ROI. It costs a lot to design a maxed CPU on a leading edge process able to compete with the latest from Apple, Intel and AMD. If you are investing that type of money there has to be sufficient profit on the backend to justify that investment - and to compensate you for your risk that the demand for your product may not appear.

RISC-V has a lot of advantages on the low end for embedded stuff. Saving a few dimes in ARM licensing cost can make a big difference there. It makes very little difference at the scale of a leading edge smartphone let alone a PC or server. I just don't see any market for a high end RISC-V CPU.

People who read forums like this might want one to exist, might even be willing to buy one if it exists. But it needs a mass market to justify the investment, and that mass market does not exist. It would need something earth shattering to happen in ARM world, like if ARM had won its lawsuit against Qualcomm and Qualcomm's license was canceled and they were forced to pull everything Nuvia related off the market. Since that didn't happen they'll have to hope a startup can con some VCs into believing the high end market for exists and writes them a check for a few hundred million dollars to fund its development, fabrication and sale or that some Qualcomm type comes along and buys them before they reach market (probably for the team if they assemble a really good one, not for the RISC-V core)

Click to expand...

I think there is a lot of interest in RISC-V for the general computing area, maybe even more than ARM itself was considering how long it took for them to take it seriusly.

They are trying, hard, to make RISC-V laptops and ITX boards / SBC so devs can port software. Their PCIE implementation to support dgpus was also better that most ARM socs too.

The intention is there, its the performance and the null iGPU support thats not there, yet.

Shivansps said:

I think there is a lot of interest in RISC-V for the general computing area, maybe even more than ARM itself was considering how long it took for them to take it seriusly.

They are trying, hard, to make RISC-V laptops and ITX boards / SBC so devs can port software. Their PCIE implementation to support dgpus was also better that most ARM socs too.

The intention is there, its the performance and the null iGPU support thats not there, yet.

Click to expand...

What OS are they going to run on those laptops to "port software"? Gonna have to be Linux, because Microsoft is not going to support a third ISA. So they intend to compete for a piece of the 2% or whatever Linux's PC market share is by undercutting low end x86 pricing? Or will they be undercutting ARM Chromebooks?

This is a pipe dream.

It is a pipedream but it's going to happen in the world's largest market even if not where you are.
RISC-V has a trump card we are not allowed to discuss here.

Doug S said:

What OS are they going to run on those laptops to "port software"? Gonna have to be Linux, because Microsoft is not going to support a third ISA. So they intend to compete for a piece of the 2% or whatever Linux's PC market share is by undercutting low end x86 pricing? Or will they be undercutting ARM Chromebooks?

This is a pipe dream.

Click to expand...

Linux. Windows support may come, or not, first you need a soc powerfull enoght to run it. They are moving to support RISC-V in .NET for Linux, so its not outside their radar.

You may think thats a bad thing, but remember there was a time Windows did not run on ARM either or it was completely useless.

Doug S said:

What OS are they going to run on those laptops to "port software"? Gonna have to be Linux, because Microsoft is not going to support a third ISA. So they intend to compete for a piece of the 2% or whatever Linux's PC market share is by undercutting low end x86 pricing? Or will they be undercutting ARM Chromebooks?

This is a pipe dream.

Click to expand...

Microsoft will be supporting RISC-V once the hardware to their quality standards appears. There is also more incentive to have Windows on RISC-V than Windows on ARM. There is more server venders on RISC-V than ARM. Server-side Windows is 1.71x~2.83x as much revenue as Client-side Windows.

Qualcomm
Mediatek
Rockchip
Raspberry (Windows on Raspberry, modified WoA)
Ampere
Nvidia
ARM

vs
~~~~
Tenstorrent (4x Aegis = 128-cores)
Ventana (192-core for V2)
AheadComputing
Rivos
Akeana (432-core Akeana 5200 w/ 4x HBM3, 256GB total @ 1.2TB/s)
SiFive (256-core)
MIPS (an Intel/Centaur group went to MIPS, announced one month ago to already be working on a new MIPS core. P8700v1 = 384-cores, P8700v2 = 512-cores)
Samsung RISC-V (high core count server processor)

Pace of advancement of domestic providers...
United States/Canada -> China -> South Korea -> Europe

Windows can get away with proprietary drivers. So, the iGPU problem on Linux will not be as significant on Windows.

Windows on RVA23 and all the above CPUs to ~~~~ are supported.

gdansk said:

It is a pipedream but it's going to happen in the world's largest market even if not where you are.
RISC-V has a trump card we are not allowed to discuss here.

Click to expand...

It remains to be seen if they go with RISC-V or Loongarch.

Doug S said:

It remains to be seen if they go with RISC-V or Loongarch.

Click to expand...

CAS/ICT has moved from Loong to RISC-V. XiangShan+others is better positioned to spread than the spin-off attempt from 2001. So, the crown will be given to RISC-V.

Risc-V is going to be fragmented unless/until someone comes along with a common specification that an industry can form around.
If not, every RV is going to have a lot of the same IP, and a lot of different/bespoke-ness that will be like going back to the late 80's/90's vis-a-vis comparability headaches.

From what I know of the founding principles and ideals, the wide-open-ness of the ISA and ability to alter it are going to make it similar to herding cats.
The technical advances are great and should continue, but it'll remain in a niche until either its formalized or an 800# gorilla sets a marker.

For opensource, it's not a problem. #ifdef the source code to support varying ISA peculiarities of the different vendors. But yes, outside of BSD and Linux, RISC-V can't thrive much unless the company creates tightly knit hw/sw like Apple.

igor_kavinski said:

For opensource, it's not a problem. #ifdef the source code to support varying ISA peculiarities of the different vendors. But yes, outside of BSD and Linux, RISC-V can't thrive much unless the company creates tightly knit hw/sw like Apple.

Click to expand...

Unless you're dealing with an interpreted language, that just produces different binaries (unless you're a power user or institutional user compiling from source). Maintaining all those different code versions would also be a headache. Not every application can be maintained like y-cruncher.

DrMrLordX said:

Unless you're dealing with an interpreted language, that just produces different binaries (unless you're a power user or institutional user compiling from source). Maintaining all those different code versions would also be a headache. Not every application can be maintained like y-cruncher.

Click to expand...

Every vendor will have to maintain their own branch of the basic stuff and essential apps/utilities. I don't see how they can't automate the process by injecting the necessary changes into source code meant to be compiled with basic RISC-V support. After that, it will be up to the market and the vendor's team to decide who wins in the end. Kinda like the OS wars of the 80s/90s out of which the current three emerged (Windows, Linux, BSD).

igor_kavinski said:

Every vendor will have to maintain their own branch of the basic stuff and essential apps/utilities. I don't see how they can't automate the process by injecting the necessary changes into source code meant to be compiled with basic RISC-V support. After that, it will be up to the market and the vendor's team to decide who wins in the end. Kinda like the OS wars of the 80s/90s out of which the current three emerged (Windows, Linux, BSD).

Click to expand...

That's suitable for applications where you're only using software supplied by the vendor (rather than loading or rolling your own). For general compute, it's a non-starter. I was hoping someone like SiFive would jump out in front with SBCs and/or SFF PC products that would support as many desktop/server/workstation-relevant instruction sets as possible so developers would want SiFive devices as dev machines. Now I'm not sure what's going on.

DrMrLordX said:

I was hoping someone like SiFive would jump out in front with SBCs and/or SFF PC products that would support as many desktop/server/workstation-relevant instruction sets as possible so developers would want SiFive devices as dev machines. Now I'm not sure what's going on.

Click to expand...

Best hope seems to be Tenstorrent.

igor_kavinski said:

Every vendor will have to maintain their own branch of the basic stuff and essential apps/utilities. I don't see how they can't automate the process by injecting the necessary changes into source code meant to be compiled with basic RISC-V support. After that, it will be up to the market and the vendor's team to decide who wins in the end. Kinda like the OS wars of the 80s/90s out of which the current three emerged (Windows, Linux, BSD).

Click to expand...

That looks easy on the surface until you take validation into account. And even compilation is a pain: some of the useful proprietary extensions used are only supported by a compiler provided by the vendor.

ISA fragmentation is a killer from the SW point of view. The only sane thing to do is to only support the approved common set of architectural features (and R-V has defined that set IIRC) and simply ignore vendor specific ones.

As an example, even Arm NEON support is still lagging behind even though it was defined more than 10 years ago and implemented in all CPUs.

igor_kavinski said:

Best hope seems to be Tenstorrent.

Click to expand...

Maybe? They're pretty specialized. They don't seem interested in rolling out commodity dev kits.

DrMrLordX said:

Maybe? They're pretty specialized. They don't seem interested in rolling out commodity dev kits.

Click to expand...

It's unsurprising given their target market.

$12k is not a lot for a company evaluating wide deployment: https://tenstorrent.com/hardware/tt-loudbox

It took many years to get acceptable dev kits for Arm (and even now I'd argue most of them are useless and underperforming). I don't see why it'd be different for RISC-V.

Nothingness said:

It's unsurprising given their target market.

$12k is not a lot for a company evaluating wide deployment: https://tenstorrent.com/hardware/tt-loudbox

It took many years to get acceptable dev kits for Arm (and even now I'd argue most of them are useless and underperforming). I don't see why it'd be different for RISC-V.

Click to expand...

Yeah I'm aware of stuff like the Loudbox, but I'm more thinking small 8-12 core SBC-like devices. Remember one of Linus Torvald's comments about why x86 took over in the server room:


If you (as a developer/admin) can't profile code at home/in the home office on anything cheaper than a $12k machine then the odds of that ISA taking over in the workplace is probably not great. Never mind that the Loudbox is pretty application-specific to ML tasks rather than general compute. It's a 2P Xeon 4309Y at heart, with ML accelerators from Tenstorrent inside it. What it is not is a single socket desktop computer or SBC featuring a RISC-V SoC as its primary processing unit. And that's why we shouldn't expect Tenstorrent to be the industry-defining vendor for RISC-V instruction sets. For their clients, selling a Xeon Silver with dedicated ML accelerators in it is much more useful than an SBC devkit for general compute.

25.10 = October 2025 (est.) and 26.04 = April 2026 (est.)


For Android probably have to wait for the RVA23 SiFive(Dual-cluster 4x P870 mobile customer) core, I believe Ventana (Android/Mobile client customer), Tenstorrent (Has big.Little customer), Akeana(also, big.Little customer) are also in Android(RVA23 Group);

OpenHarmony CN is suppose to announce something at the end of the year. For RVA23 development phones preorders for 2026.

Once the hardware appears. Then, the software is soon to follow. Specifically, the higher performance cores are preferred for quickly compiling and testing stuff. Very time consuming to use a kendryte k230 (c908 core) and Pi F3 (x60 core) for development.

NostaSeronx said:

Once the hardware appears. Then, the software is soon to follow. Specifically, the higher performance cores are preferred for quickly compiling and testing stuff. Very time consuming to use a kendryte k230 (c908 core) and Pi F3 (x60 core) for development.

Click to expand...

Yes, good HW is a prerequisite as you and @DrMrLordX rightly wrote. But that doesn't imply software follows quickly. As I wrote above, even after more than 10 years of NEON and HW being available, many SW still lack proper use of it.

Nothingness said:

Yes, good HW is a prerequisite as you and @DrMrLordX rightly wrote. But that doesn't imply software follows quickly. As I wrote above, even after more than 10 years of NEON and HW being available, many SW still lack proper use of it.

Click to expand...

Good hardware and good supply. Don't want to be the SG2380 and never launch, because other SKUs went somewhere they shouldn't. Given RISC-V Software Ecosystem (RISE): Accelerating the RISC-V Software Ecosystem. Open-source projects should expect to get RVV/RVA23 pretty quickly.

Given the single-die chiplets with IODs;
32-core Tenstorrent Ascalons
32-core Ventana Veyron V2s
32-core SiFive P870s (know it says -AS, but should also be p870-base: "P870 is a six-wide, out-of-order core, meeting RVA 23, with a shared cluster cache enabling up to a 32-core cluster.")

32-core Akeana 5200s (unknown if someone is doing a chiplet for them)
etc.
[[SiFive/Ventana appear to be both Intel Foundry Services and TSMC. Tenstorrent is Samsung and Rapidus. Akeana is likely to be TSMC only.]]

The clock should start for development after the above appear for sale. I think the FOSS-side went from ARMv8+NEON in 2011 to ARMv8+NEON in libs by 2017. RVV = 2021 to RVV in hardware = 2023, RVV being put in libs = 2024.

The FOSS-side will be relatively fast once these beefcake CPUs come out. As most of the maintainers have multi-workload workflows. Which are currently forced in into a single-workload workflow because hardware is slow.

If we get big CPUs(server-side) and small CPUs w/ PCIe, RADV(AMD dGPU)(client-side) at the "same" time. We can watch Godot/Redot engine/games speed of adoption as a rate test.
1. RVA23/RV64 binary for engine
2. RVA23/RV64 executable for game
3. Full RVA23/RV64 native workflow

Ideally watching out for Lispy Snake but for RISC-V hardware and games. But, copying Playdate's GaaS model (Software+Hardware in same purchase)... https://web.archive.org/web/20200917024652/https://lispysnake.com/the-game-raiser and https://en.wikipedia.org/wiki/Playdate_(console)

Raymarching a rig of homogenous ISA, host OoO cores and several PCIe/CXL or whatever with phat vectors.

hyperscalers/hyperbuyers will probably go for the most absurd config.
2x 432-core Akeana 5200 (~Apple M3 p-core) (Dual CPU Mobo)
4x 864-core Akeana 1200-AI ["221184" 32-bit ALU lanes] (Quad CPU-card)
Where RISC-V is more likely to scale-up+scale-out way faster and cheaper than x86-64/ARM.

The above is important for Visual Effects/Animation/Production workflows. Without losing quality/robustness from GPU-based renderers. CPU is still king in those fields. zstd multi-threaded+zram smaller HBM3 256 GB can become around ~716 GB compressed memory.

Quadruple-A games should come with Quadruple-A non-in-engine cinematics. The sheer revenue generated across every gaming platform. Actually implies Pentuple-A games/cinematics are possible. Basically, the era of truely-crazy spending is only with RISC-V getting large fast. Since, ARM+x86-64 is too slow on innovation, cost-reduction, power-reduction.

Marvel/Disney movies (before the crash) => CPU Rendered
Marvel/Disney movies (during the crash) => GPU Rendered
While GPUs are faster the quality clearly dropped. At the end, it is actually better to scale CPU workflows than GPU workflows.

Same for Alibaba and Youku (Donghua Umbrella studios-specifically)....
Where the ideal solution for them is to quickly move umbrella studios to T-Head C930 renderfarms and Blender/Openmoonray. Once you see Unity/Unreal GPU-renderers watermark in animation design it can't be unseen.

RVA23 -> RVA23.3+ (Matrix) -> RVA23.6+ (Graphics) who knows if they will be mandatory or optional.

Rocky Linux 10 should have RISC-V support. Likely to be RVA23.
V100 Server/X100 Cores from Spacemit are already sampling?
Veyron V2 should be sampling 2025(anytime).
T-head's C930 is anytime, as well as Kunminghu 7nm Server SoC(partner not CAS) is anytime.
Ascalon D8 customers haven't been announced but should be shipping somewhere.
Akeana 5000s/1000s have customers but no clue when or who.
The AndesCore™ AX66 is to be available for lead customers in Q4 2024 through the early access program and for general customers in 2025. Lead customers list: MediaTek, Renesas, Kneron, Picocom, MegaChips, Socionext
SiFive P870 should be 2025 as well.
Zhihe Computing should be releasing a core at >25(20+ in slide, but >25 in speech) specint06/GHz at 2.5 GHz, 2H25. (employee list: Alibaba, AMD, Intel, Mediatek, Broadcom, Zheku (Oppo's custom chip division))

"Unfortunately, due to some unfixed bugs in box64, RVV1.0 had to be disabled, so the FPS are not great yet."

RISC-V laptops with Ascalon

RTX said:

View attachment 115006
RISC-V laptops with Ascalon

Click to expand...

Since when?

Chips & Cheese analysis of SiFive P550: https://chipsandcheese.com/p/inside-sifives-p550-microarchitecture

Chips & Cheese benchmarked SiFive P550 and T-HEAD C910: https://chipsandcheese.com/p/a-risc-v-progress-check-benchmarking

Due to low clocks (1.4GHz and 1.85GHz) these 2 OoO cores have roughly the same performance as a well implemented IoO Cortex-A55 at 2GHz.
Also to note is the lack of support for x264.

Wow, both RISC-V CPUs got wrecked by Goldmont Plus. Unfortunate.