Not my area of expertise but what exactly is the difference between RISC-V and Power PC? Didn't Power-PC get a good run in the 90s and 2000s? Just wondering why there's renewed interest in RISC-like architectures when industry already had a good exploration of that area.
Your submission was sent successfully! Close
Thank you for contacting us. A member of our team will be in touch shortly. Close
You have successfully unsubscribed! Close
Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu
and upcoming events where you can meet our team. Close
Your preferences have been successfully updated. Close notification
Please try again or file a bug report. Close
This is true, but only for the bigger players. The nature of hardware still fundamentally favors scale and centralization. Every hyper-scalar eventually gets to a size that developing in-house CPU talent is just straight up better (Qcom and Ventana + Nuvia, Meta and Rivos, Google's been building their own team, Nvidia and Vera-Rubin, God help Microsoft though). This does not bode well for RISC-V companies, who are just being used as a stepping stone. See Anthropic, who does currently license but is rumored to develop their own in-house talent [1].
> Extensibility powers technology innovation
>> While this flexibility could cause problems for the software ecosystem...
"While" is doing some incredible heavy lifting. It is not enough to be able to run Ubuntu, as may be sufficient for embedded applications, but to also be fast. Thusly, there are many hardcoded software optimizations just for a CPU, let alone ARM or x86. For RISC-V? Good luck coding up every permutation of an extension that exists, and even if it's lumped as RVA23, good luck parsing through 100 different "performance optimization manuals" from 100 different companies.
> How mature is the software ecosystem?
10 years ago, when RISC-V was invented, the founders said 20 years. 10 years later, I say 30 years.
The nature of hardware as well, is that the competition (ARM) is not stationary as well. The reason for ARM's dominance now is the failure of Intel, and the strong-arming of Apple.
I have worked in and on RISC-V chips for a number of years, and while I am still a believer that it is the theoretical end state, my estimates just feel like they're getting longer and longer.
I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole.
Unity, Bazaar, Mir, Upstart, Snap, etc.
All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.
Will RISC-V end up with the same (or even worse) platform fragmentation as ARM? Because of absence of any common platform standard we have phones that are only good for landfill once their support lifetime is up, drivers never getting upstreamed to Linux kernel (or upstreaming not even possible due to completely quixotic platforms and boot protocols each manufacturer creates). RISC-V allows even higher fragmentation in the portions of instruction sets each CPU supports, e.g. one manufacturer might decide MUL/DIV are not needed for their CPU etc. ("M" extension).
RISC-V is addressing this issue quite directly. For things like desktops, laptops, SBCs and servers we have the RVA23 profile which defines quite specifically what features a chip must support to ensure code portability.
On top of this, there are platform specifications. For example, the server spec is about to finalize next month. It extends RVA23 which things like UEFI, SBI, and ACPI to ensure that your can take something like a Linux distro and easily install it on any RISC-V server, like you can in the world of x86-64.
> we have phones that are only good for landfill once their support lifetime is up
RISC-V will probably not solve that problem in general.
First, the ISA cannot really demand that your phone avoid a Broadcom wireless chip that requires proprietary firmware for example.
Also, the phone vendor can still lock down the devices to prevent running arbitrary code.
Thankfully, the RISC-V world is developing a culture of openness. If a company wants to create a fully “open” phone, they are quite likely to adopt RISC-V. And, because of RISC-V, even the SoC itself could be fully Open Source.
But your typical Android phone is not going to get more Open just because they contain a RISC-V CPU.
I've played with a bunch of RISC-V platforms, mostly SBCs in the raspi class
Beyond the potential platform fragmentation due to the variability of the ISA (a very unfortunate design choice IMO), mentioned elsewhere in this thread, what I find most frustrating is the boot process / equivalent of BIOS in that world.
My impression: complete lack of standardization, a ton of ad-hoc tools native to each vendor, a complete mess, especially when it comes to get the board to boot from devices the vendor didn't target (eg SSDs).
Until two things happen:
1. a CPU with a somewhat competitive compute power appears (so far, all the SBC's I've tried are way behind ARM and x86)
2. a unified BOOT environment which supports a broad standard of devices to boot from (SSD, network, SD-Card, hard-drives, etc...)
the whole RISC-V thing will remain a tiny niche thing, especially because when a vendor loses interest in the platform, all of the SW that is native to the platform goes to rot immediately (not that it was particularly good quality in the first place).
> 2. a unified BOOT environment which supports a broad standard of devices to boot from (SSD, network, SD-Card, hard-drives, etc...)
I got the same experience tinkering with ARM devices. It soured me so much that I have decided that until ARM offers a unified boot mechanism like x86 PCs do, I will ignore it, no matter the supposed benefits.
I have touched some PC-98 and FM Towns, which are x86 but not IBM PC compatible.
But I understand your point, ARM has its roots in embedded systems and it shows. I really hope that RISC-V learns from that mistake and focuses on standardization, the board you linked looks very promising.
There are several RISC-V Linux distros where essentially all the software available for the x86-64 platform is also available on the RISC-V edition. Let’s use Ubuntu as an example.
> when a vendor loses interest in the platform
> the platform goes to rot immediately
Ubuntu will provide updates for 15 years. That does not seem very immediate.
For RVA23 hardware, I expect even new Ubuntu releases to support it up to around 2030 at least. 15 years from then will be 2045. I cannot say that I am picking up what you are laying down here.
15 comments
[ 3.0 ms ] story [ 33.0 ms ] threadI may be using this one soon:
https://store.deepcomputing.io/products/dc-roma-risc-v-mainb...
Pretty much every new ISA introduced since the 80’s has been RISC.
PowerPC was adopted by Apple (RISC), they went back to Intel (CISC), and then they went back to RISC (Apple Silicon).
ARM, pretty much all phones, tablets, and Chromebooks is RISC.
Windows runs on ARM now as well (Qualcomm X Elite).
The interest around RISC-V is that anybody can use it in their chips without having to ask permission.
This is true, but only for the bigger players. The nature of hardware still fundamentally favors scale and centralization. Every hyper-scalar eventually gets to a size that developing in-house CPU talent is just straight up better (Qcom and Ventana + Nuvia, Meta and Rivos, Google's been building their own team, Nvidia and Vera-Rubin, God help Microsoft though). This does not bode well for RISC-V companies, who are just being used as a stepping stone. See Anthropic, who does currently license but is rumored to develop their own in-house talent [1].
> Extensibility powers technology innovation
>> While this flexibility could cause problems for the software ecosystem...
"While" is doing some incredible heavy lifting. It is not enough to be able to run Ubuntu, as may be sufficient for embedded applications, but to also be fast. Thusly, there are many hardcoded software optimizations just for a CPU, let alone ARM or x86. For RISC-V? Good luck coding up every permutation of an extension that exists, and even if it's lumped as RVA23, good luck parsing through 100 different "performance optimization manuals" from 100 different companies.
> How mature is the software ecosystem?
10 years ago, when RISC-V was invented, the founders said 20 years. 10 years later, I say 30 years.
The nature of hardware as well, is that the competition (ARM) is not stationary as well. The reason for ARM's dominance now is the failure of Intel, and the strong-arming of Apple.
I have worked in and on RISC-V chips for a number of years, and while I am still a believer that it is the theoretical end state, my estimates just feel like they're getting longer and longer.
[1]: https://www.reuters.com/business/anthropic-weighs-building-i...
Unity, Bazaar, Mir, Upstart, Snap, etc.
All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.
RISC-V is addressing this issue quite directly. For things like desktops, laptops, SBCs and servers we have the RVA23 profile which defines quite specifically what features a chip must support to ensure code portability.
On top of this, there are platform specifications. For example, the server spec is about to finalize next month. It extends RVA23 which things like UEFI, SBI, and ACPI to ensure that your can take something like a Linux distro and easily install it on any RISC-V server, like you can in the world of x86-64.
> we have phones that are only good for landfill once their support lifetime is up
RISC-V will probably not solve that problem in general.
First, the ISA cannot really demand that your phone avoid a Broadcom wireless chip that requires proprietary firmware for example.
Also, the phone vendor can still lock down the devices to prevent running arbitrary code.
Thankfully, the RISC-V world is developing a culture of openness. If a company wants to create a fully “open” phone, they are quite likely to adopt RISC-V. And, because of RISC-V, even the SoC itself could be fully Open Source.
But your typical Android phone is not going to get more Open just because they contain a RISC-V CPU.
Beyond the potential platform fragmentation due to the variability of the ISA (a very unfortunate design choice IMO), mentioned elsewhere in this thread, what I find most frustrating is the boot process / equivalent of BIOS in that world.
My impression: complete lack of standardization, a ton of ad-hoc tools native to each vendor, a complete mess, especially when it comes to get the board to boot from devices the vendor didn't target (eg SSDs).
Until two things happen:
1. a CPU with a somewhat competitive compute power appears (so far, all the SBC's I've tried are way behind ARM and x86)
2. a unified BOOT environment which supports a broad standard of devices to boot from (SSD, network, SD-Card, hard-drives, etc...)
the whole RISC-V thing will remain a tiny niche thing, especially because when a vendor loses interest in the platform, all of the SW that is native to the platform goes to rot immediately (not that it was particularly good quality in the first place).
I got the same experience tinkering with ARM devices. It soured me so much that I have decided that until ARM offers a unified boot mechanism like x86 PCs do, I will ignore it, no matter the supposed benefits.
The RISC-V server spec mandates UEFI, ACPI, and SBI. Here is a RISC-V “desktop” motherboard that has the same:
https://milkv.io/titan
But I understand your point, ARM has its roots in embedded systems and it shows. I really hope that RISC-V learns from that mistake and focuses on standardization, the board you linked looks very promising.
I think this is going to embarrassingly wrong.
> all of the SW that is native to the platform
There are several RISC-V Linux distros where essentially all the software available for the x86-64 platform is also available on the RISC-V edition. Let’s use Ubuntu as an example.
> when a vendor loses interest in the platform > the platform goes to rot immediately
Ubuntu will provide updates for 15 years. That does not seem very immediate.
For RVA23 hardware, I expect even new Ubuntu releases to support it up to around 2030 at least. 15 years from then will be 2045. I cannot say that I am picking up what you are laying down here.