RISC V making its way into proper server platforms is a huge milestone. The open architecture could eventually disrupt the current vendor lock in we see in cloud data centers.
I don't doubt RISC-V can be used to make powerful cores but adoption as a general purpose CPU (rather than MCU) will need more than good numbers.
There's still a missing piece in the RISC-V ecosystem: a coordination body of platform-level standards. Debian took a stand with RVA23 support but then there's a ton of little things that are taken for granted on the PC platform such as UEFI and ACPI (as horrible as they may be).
Which axis of vendor lock in are you seeing possibly being disrupted by this? x86 is rather dominant, though ARM is making a play. RISC V just means AWS offers a different ISA on compute, you'd still be vendor lock-in'd to AWS/whomever. Or I'm totally not getting it.
Lock-in to x86 or ARM is painful from an operator like AWSs perspective. With x86 you end up with two vendors to play off against each other, which isn't great. ARM gives you the ability to design your own silicon, but you're still beholden to a single licensor -- arguably worse. On top of that, some customers mandate a specific ISA or even a specific vendor, so none of it is truly fungible outside vertically integrated workloads like S3.
The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
> The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
This is what Arm actually is. Arm primarily functions as a talking shop for random insights to get back from integrators into the ISA and architecture, then cleared and released for everyone to use. The reason there are so few novel implementations of it is it just isn’t worth the trouble unless you are pushing mobile levels of units.
I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.
…and when it comes to the most common use of big-iron GPUs right now, neural network engines, they're all so poorly put together that a papercut is often fatal. If every dependency isn't the exact needed version, the whole thing will collapse, and using all but the most common hardware is sure to be unsupported in some deprecated library version that is absolutely required to get everything running.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, but then LLMs and stable diffusion came along.
> I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, …
These tools were the reason why I gave up on FPGAs years ago and chose to spend my time on GPUs instead. And to this day, I still don't understand why they worked so differently from what I had expected in so many ways.
You haven’t lived until you have done a model training run where different stages require mutually incompatible nvidia driver revisions and everything on top.
AMD GPUs have worked on RISC-V for a couple years at this point. I have a Milk-V Titan that's paired with an AMD GPU running well: https://milkv.io/titan
RISC V making its way into proper server platforms is a huge milestone. The open architecture could eventually disrupt the current vendor lock in we see in cloud data centers.
I don't doubt RISC-V can be used to make powerful cores but adoption as a general purpose CPU (rather than MCU) will need more than good numbers.
There's still a missing piece in the RISC-V ecosystem: a coordination body of platform-level standards. Debian took a stand with RVA23 support but then there's a ton of little things that are taken for granted on the PC platform such as UEFI and ACPI (as horrible as they may be).
Which axis of vendor lock in are you seeing possibly being disrupted by this? x86 is rather dominant, though ARM is making a play. RISC V just means AWS offers a different ISA on compute, you'd still be vendor lock-in'd to AWS/whomever. Or I'm totally not getting it.
Obviously not OP, but:
Lock-in to x86 or ARM is painful from an operator like AWSs perspective. With x86 you end up with two vendors to play off against each other, which isn't great. ARM gives you the ability to design your own silicon, but you're still beholden to a single licensor -- arguably worse. On top of that, some customers mandate a specific ISA or even a specific vendor, so none of it is truly fungible outside vertically integrated workloads like S3.
The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
> The ideal scenario for a hyperscaler is an open architecture at the core with 10+ competing implementations -- including potentially their own.
This is what Arm actually is. Arm primarily functions as a talking shop for random insights to get back from integrators into the ISA and architecture, then cleared and released for everyone to use. The reason there are so few novel implementations of it is it just isn’t worth the trouble unless you are pushing mobile levels of units.
> Support for double-wide GPUs (Up to 450W)
I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.
…and when it comes to the most common use of big-iron GPUs right now, neural network engines, they're all so poorly put together that a papercut is often fatal. If every dependency isn't the exact needed version, the whole thing will collapse, and using all but the most common hardware is sure to be unsupported in some deprecated library version that is absolutely required to get everything running.
I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, but then LLMs and stable diffusion came along.
> I had thought Xilinx ISE and Altera Quartus had the market cornered on the most difficult environments to get running, …
These tools were the reason why I gave up on FPGAs years ago and chose to spend my time on GPUs instead. And to this day, I still don't understand why they worked so differently from what I had expected in so many ways.
You haven’t lived until you have done a model training run where different stages require mutually incompatible nvidia driver revisions and everything on top.
That's why _LEAN_ open source is really required, and that includes the SDK.
AMD GPUs have worked on RISC-V for a couple years at this point. I have a Milk-V Titan that's paired with an AMD GPU running well: https://milkv.io/titan
Maybe a Zen microarchitecture with a RISC-V/RVA front-end?
While thinking about it, if NVIDIA or SAMSUNG go performant RISC-V CPU micro-architecture, will "probably" change the world.
> Support for double-wide GPUs (Up to 450W)
oh a double wide surprise for the AI industry? just what we needed.
https://camel-cdr.github.io/rvv-bench-results/sifive_p870/in...
what is the boot environment like for these type of platforms?
is it opensource or megs of blob?
It varies a lot by vendor. The older SiFive P550 is pretty good, see these forum threads: https://forums.sifive.com/t/where-is-the-source-code-of-the-... https://forums.sifive.com/t/building-opensbi-and-uboot/7681/...
256gb ddr5, so this is going to cost north of 100k? Damn.
No way, it's only like 4x64 GB of ECC DDR5 5600 RDIMMs. Who's paying $100k for that? I'll gladly sell them this at a 10% discount.
Can’t see myself buying my this but glad riscv is making progress.
Missing the silicon process.