Most people would be better off waiting for the multiple RVA23 boards that are supposed to come out this year, at least if they don't want to be stuck running custom vendor distros. "RVA23 except V" at this price point and at this point in time is a pretty bad value proposition.
It's honestly a bit hard to understand why they bothered with this one. No hate for the Milk-V folks; I have 4 Jupiters sitting next to me running in Zig's CI. But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?).
I feel this is becoming a bit of a tech urban legend such as ZFS requires ECC.
As far as I understand the RVA23 requirement is an ubuntu thing only and only for current non LTS and future releases. Current LTS doesn't have such requirements and neither other distributions such as Fedora and Debian that support riscv64.
So no, you are not stuck running custom vendor distros because of this but more because the other weird device drivers and boot systems that have no mainline support.
I'm fairly sure I recall Fedora folks signaling that they intend to move to RVA23 as soon as hardware becomes generally available.
It is of course possible that Debian sticks with RV64GC for the long term, but I seriously doubt it. It's just too much performance to leave on the table for a relatively new port, especially when RVA23 will (very) soon be the expected baseline for general-purpose RISC-V systems.
I'm not completely sure, but I suspect Fedora will stick to the current baseline for quite some time.
But the baseline is quite minimal. It's biased towards efficient emulation of the instructions in portable C code. I'm not sure why anyone would target an enterprise distribution to that.
On the other hand, even RVA23 is quite poor at signed overflow checking. Like MIPS before it, RISC-V is a bet that we're going to write software in C-like languages for a long time.
I don't think you'll be able to get away from custom distros even with RVA23. It solves the problem of binary compatibility - everything compiled for RVA23 should be pretty portable at the instruction level (won't help with the usual glibc nonsense of course).
But RVA23 doesn't help with the hardware layer - it's going to be exactly the same as ARM SBCs where there's no hardware discovery mechanism and everything has to be hard-coded in the Linux device tree. You still need a custom distro for Raspberry Pi for example.
I believe there has been some progress in getting RISC-V ACPI support, and there's at least the intent of making mconfigptr do something useful - for a while there was a "unified discovery" task group, but it seems like there just wasn't enough manpower behind it and it disbanded.
> You still need a custom distro for Raspberry Pi for example.
Are you sure that's still the case? I just checked the Raspberry Pi Imager and I see several "stock" distro options that aren't Raspbian.
Regardless, I take your point that we're reliant on vendors actually doing the upstreaming work for device trees (and drivers). But so far the recognizable players in the RISC-V space do all(?) seem to be doing that, so for now I remain hopeful that we can avoid the Arm mess.
I've noticed that the sentence “Compliant with RVA23 excluding V extension” has apparently been a bit confusing to some reporters in the tech press lately.
It means that the UR-DP1000 chip would have been RVA23-compliant if only it had supported the V (Vector) extension. The Vector extension is mandatory in the RVA23 profile.
There are other chips out there even closer to being RVA23-compliant, that have V but not a couple of scalar extensions. The latter have been emulated in software using trap handlers, but there was a significant performance penalty.
V is such a big extension, with many instructions and requiring more resources, that I don't think that it would be worth the effort.
> The latter have been emulated in software using trap handlers, but there was a significant performance penalty.
This is a thing SoC vendors have done before without informing their customers until it's way too late. Quite a few players in that industry really do have shockingly poor ethical standards.
I'm not sure if it's intentional. AWS doesn't have CPU features in their EC2 product documentation, either. It doesn't necessarily mean that they can disable CPU features for instances covered by existing customer contracts.
I'm surprised we have not seen more investment into RISC-V from Chinese firms. I would think they want to decouple from ARM and the west in general as a dependency. Maybe they view the coup of ARM China as having secured ARM for the time being and not as much pressure?
Either way, it's currently hard to be excited about RISC-V ITX boards with performance below that of a RPi5. I can go on AliExpress right now and buy a mini itx board with a Ryzen 9 7845HX for the same price.
I'm surprised we haven't seen more investment from Indian firms. India is really trying to raise their game in the tech economy beyond the services industry. You don't need the most cutting-edge chip fabrication equipment to manufacture these processors.
The Indian government was actually a very early adopter, they had one of the first RISC-V processors that wasn't based on the vanilla Rocket designs, starting back in like 2016 or so. Unfortunately they made some other weird decisions, like not supporting compressed instructions so the chip wasn't compatible with any mainstream Linux distros, and I don't think the project really went anywhere. Although looking at Wikipedia the project seems to still exist.
LoongArch is a weird mix of MIPS and RISC-V. There's not much that would be gained by investing a whole bunch into LoongArch that couldn't also be done to RISC-V, if at all.
It's not better architecture so the gain is few pennies more per chip at cost of A LOT of work... work that can't just run Android or much else out of the box.
Isn’t that kind of like saying automated testing (for apps written without testing in mind) isn’t worth it because you have to spend time getting code into a state that is testable?
I do agree that it takes a lot of work to get something usable, and so I think we are a ways off from mainstream risc-v. I do also think there is a lot more value for low power devices like embedded/IoT or instances where you need special hardware. Facebook uses it to make special video transcoding hardware.
> I would think they want to decouple from ARM and the west in general as a dependency.
Why would you think that? ARM is not like x86 CPUs where you get the completed devices as a black box. Chinese silicon customers have access to the full design. I guess it's not completely impossible to hide backdoors at that level but it'd be extremely hard and would be a huge reputational risk if they were found.
They also can't really be locked out of ARM since if push comes to shove, Chinese silicon makers would just keep making chips without a license.
I did catch one vendor using a HAL across a whole SoC product line, a very low-level HAL that sat between SoC hardware registers and kernel drivers. It effectively made the drivers use scrambled register locations on the AHB etc, but if you resolved what the HAL did, the registers matched ARM's UART etc IP. So I figured they were ducking license fees for ARM peripherals.
Everybody sane will want to move away from them, there is nothing chinese specific.
The most performant RISC-V implementations are from the US if I am not too mistaken.
Wonder if that hardware can handle an AMD 9070 XT (resizable bar). If so, we need the steam client to be recompiled for RISC-V and some games... if this RISC-V implementation is performant enough (I wish we would have trashed ELF before...)
Is there an actual U.S. RISC-V CPU that achieves competitive performance? I think the performance leaders are currently based in China.
There's a difference between announcement, offering IP for licensing (so you still have to make your own CPUs), shipping CPUs, and having those CPUs in systems that can actually boot something.
The good: eight cores. The bad: it’s slow and still no V extension. On the bright side, it uses DDR4, so you might be able to find RAM for it. “Titan” feels like some wishful over marketing.
As a point of comparison, the Radxa Orion O6 shipped a year ago as a 12 core ARMv9 board on same form factor and TDP, for $100 less, with 5x the single core performance (and including a competent iGPU, NPU and VPU). These are very much developer/tinkerer only boards as is.
You can still get the 32GB variant direct from Radxa off AliExpress for about $412 USD. Much more than launch costs (probably due to cost of ram), but that's actually still cheaper than the Milk-V Titan. The Titan ships with empty RAM slots, and you'd wind up paying another ~$200 to get 2x16GB of DDR4, which is slower than the soldered on LPDDR5 on the Orion.
If you don't need the full PCIe slot, there's also smaller SBC boards (either exactly micro-ITX or similar footprint) using the same SoC: The OrangePi 6 Plus and Radxa O6N. The OPi is available readily for $260 with 32GB LPDDR5, though admittedly the RAM is lower spec than what ships on the Orion O6.
These are my favorite sub $500 SBCs available today. Great Linux support and you need to move up to something like the LattePanda Sigma at over $600 to get something outclassing them in a similar form-factor, but then there's no option for directly slotting a full-size GPU either.
These are still very early days for RISC-V, but I’m always happy to see things progress in this space. No, this isn’t a viable desktop for the average consumer, but if it makes the architecture more accessible for the types of weirdos who tend to pave the way for the rest of us, it’s good.
I just got a Milkv Mars and it is bit rough around the edges. Discord group helped me to get a Debian running on it but I would not say it was simple or easy to get it working.
For integer workloads it seems closer to 60% of RPi 5 performance. There are some benchmarks that depend on vector support or dedicated CPU instructions for good results, and they skew the results.
A TL;DR doesn't explain everything. The Milk-V Titan doesn't have Vector instructions or crypto, while the Pi 5 does. It's very clearly a broken benchmark.
This is why a bunch of RISC-V people won't buy boards without RV Vector instructions.
riscv is going to start having brand issues with these hardware offerings (if it doesn't already.)
sure, prototypes are good. but maybe it shouldn't be sold as a general product, because it implies that the sellers deem it a good product (when it obviously isn't.)
maybe it should be a closed offering, e.g. we're only making 1000, and we're only sending them to select few specialists/reviewers.
Most people would be better off waiting for the multiple RVA23 boards that are supposed to come out this year, at least if they don't want to be stuck running custom vendor distros. "RVA23 except V" at this price point and at this point in time is a pretty bad value proposition.
It's honestly a bit hard to understand why they bothered with this one. No hate for the Milk-V folks; I have 4 Jupiters sitting next to me running in Zig's CI. But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?).
> But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?).
A handful of developers already have access to SpacemiT K3 hardware, which is indeed RVA23 compliant and already runs Ubuntu 26.04.
geekbench: https://browser.geekbench.com/v6/cpu/16145076
rvv-bench: https://camel-cdr.github.io/rvv-bench-results/spacemit_x100/... (which as instruction throughput measurements and more)
This is around the performance of a Core 2 Duo, if I understand correctly?
7 replies →
I feel this is becoming a bit of a tech urban legend such as ZFS requires ECC.
As far as I understand the RVA23 requirement is an ubuntu thing only and only for current non LTS and future releases. Current LTS doesn't have such requirements and neither other distributions such as Fedora and Debian that support riscv64.
So no, you are not stuck running custom vendor distros because of this but more because the other weird device drivers and boot systems that have no mainline support.
I'm fairly sure I recall Fedora folks signaling that they intend to move to RVA23 as soon as hardware becomes generally available.
It is of course possible that Debian sticks with RV64GC for the long term, but I seriously doubt it. It's just too much performance to leave on the table for a relatively new port, especially when RVA23 will (very) soon be the expected baseline for general-purpose RISC-V systems.
3 replies →
I'm not completely sure, but I suspect Fedora will stick to the current baseline for quite some time.
But the baseline is quite minimal. It's biased towards efficient emulation of the instructions in portable C code. I'm not sure why anyone would target an enterprise distribution to that.
On the other hand, even RVA23 is quite poor at signed overflow checking. Like MIPS before it, RISC-V is a bet that we're going to write software in C-like languages for a long time.
4 replies →
I don't think you'll be able to get away from custom distros even with RVA23. It solves the problem of binary compatibility - everything compiled for RVA23 should be pretty portable at the instruction level (won't help with the usual glibc nonsense of course).
But RVA23 doesn't help with the hardware layer - it's going to be exactly the same as ARM SBCs where there's no hardware discovery mechanism and everything has to be hard-coded in the Linux device tree. You still need a custom distro for Raspberry Pi for example.
I believe there has been some progress in getting RISC-V ACPI support, and there's at least the intent of making mconfigptr do something useful - for a while there was a "unified discovery" task group, but it seems like there just wasn't enough manpower behind it and it disbanded.
https://github.com/riscvarchive/configuration-structure/blob...
https://riscv.atlassian.net/browse/RVG-50
> You still need a custom distro for Raspberry Pi for example.
Are you sure that's still the case? I just checked the Raspberry Pi Imager and I see several "stock" distro options that aren't Raspbian.
Regardless, I take your point that we're reliant on vendors actually doing the upstreaming work for device trees (and drivers). But so far the recognizable players in the RISC-V space do all(?) seem to be doing that, so for now I remain hopeful that we can avoid the Arm mess.
1 reply →
I've noticed that the sentence “Compliant with RVA23 excluding V extension” has apparently been a bit confusing to some reporters in the tech press lately.
It means that the UR-DP1000 chip would have been RVA23-compliant if only it had supported the V (Vector) extension. The Vector extension is mandatory in the RVA23 profile.
There are other chips out there even closer to being RVA23-compliant, that have V but not a couple of scalar extensions. The latter have been emulated in software using trap handlers, but there was a significant performance penalty. V is such a big extension, with many instructions and requiring more resources, that I don't think that it would be worth the effort.
> The latter have been emulated in software using trap handlers, but there was a significant performance penalty.
This is a thing SoC vendors have done before without informing their customers until it's way too late. Quite a few players in that industry really do have shockingly poor ethical standards.
I'm not sure if it's intentional. AWS doesn't have CPU features in their EC2 product documentation, either. It doesn't necessarily mean that they can disable CPU features for instances covered by existing customer contracts.
3 replies →
I'm sure it is in footnote in datasheet
2 replies →
I'm surprised we have not seen more investment into RISC-V from Chinese firms. I would think they want to decouple from ARM and the west in general as a dependency. Maybe they view the coup of ARM China as having secured ARM for the time being and not as much pressure?
Either way, it's currently hard to be excited about RISC-V ITX boards with performance below that of a RPi5. I can go on AliExpress right now and buy a mini itx board with a Ryzen 9 7845HX for the same price.
I'm surprised we haven't seen more investment from Indian firms. India is really trying to raise their game in the tech economy beyond the services industry. You don't need the most cutting-edge chip fabrication equipment to manufacture these processors.
The Indian government was actually a very early adopter, they had one of the first RISC-V processors that wasn't based on the vanilla Rocket designs, starting back in like 2016 or so. Unfortunately they made some other weird decisions, like not supporting compressed instructions so the chip wasn't compatible with any mainstream Linux distros, and I don't think the project really went anywhere. Although looking at Wikipedia the project seems to still exist.
https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)
Services industry is gonna be tough in the age of AI agents.
If by really trying you mean a bunch of PR stunts and diverted funds, sure.
Are you aware of any actual credible attempts?
China also has LoongArch.
LoongArch is a weird mix of MIPS and RISC-V. There's not much that would be gained by investing a whole bunch into LoongArch that couldn't also be done to RISC-V, if at all.
2 replies →
China is vested in Loongson.
https://en.wikipedia.org/wiki/Loongson
It's not better architecture so the gain is few pennies more per chip at cost of A LOT of work... work that can't just run Android or much else out of the box.
Isn’t that kind of like saying automated testing (for apps written without testing in mind) isn’t worth it because you have to spend time getting code into a state that is testable?
I do agree that it takes a lot of work to get something usable, and so I think we are a ways off from mainstream risc-v. I do also think there is a lot more value for low power devices like embedded/IoT or instances where you need special hardware. Facebook uses it to make special video transcoding hardware.
1 reply →
> I would think they want to decouple from ARM and the west in general as a dependency.
Why would you think that? ARM is not like x86 CPUs where you get the completed devices as a black box. Chinese silicon customers have access to the full design. I guess it's not completely impossible to hide backdoors at that level but it'd be extremely hard and would be a huge reputational risk if they were found.
They also can't really be locked out of ARM since if push comes to shove, Chinese silicon makers would just keep making chips without a license.
I did catch one vendor using a HAL across a whole SoC product line, a very low-level HAL that sat between SoC hardware registers and kernel drivers. It effectively made the drivers use scrambled register locations on the AHB etc, but if you resolved what the HAL did, the registers matched ARM's UART etc IP. So I figured they were ducking license fees for ARM peripherals.
arm has toxic IP locks.
Everybody sane will want to move away from them, there is nothing chinese specific.
The most performant RISC-V implementations are from the US if I am not too mistaken.
Wonder if that hardware can handle an AMD 9070 XT (resizable bar). If so, we need the steam client to be recompiled for RISC-V and some games... if this RISC-V implementation is performant enough (I wish we would have trashed ELF before...)
Is there an actual U.S. RISC-V CPU that achieves competitive performance? I think the performance leaders are currently based in China.
There's a difference between announcement, offering IP for licensing (so you still have to make your own CPUs), shipping CPUs, and having those CPUs in systems that can actually boot something.
1 reply →
Box64 already runs Steam (and a good number of games) on RISC-V.
2 replies →
The good: eight cores. The bad: it’s slow and still no V extension. On the bright side, it uses DDR4, so you might be able to find RAM for it. “Titan” feels like some wishful over marketing.
As a point of comparison, the Radxa Orion O6 shipped a year ago as a 12 core ARMv9 board on same form factor and TDP, for $100 less, with 5x the single core performance (and including a competent iGPU, NPU and VPU). These are very much developer/tinkerer only boards as is.
But it's not really a good board, sadly:
https://github.com/geerlingguy/sbc-reviews/issues/62#issueco...
https://github.com/System64fumo/linux/blob/main/hardware/dev...
It is actually a very good board, and now has a fully supported platform on mainline. Those are very out of date. https://github.com/Sky1-Linux/
2 replies →
It appears to cost about twice as much as the Titan these days. Not sure if that's RAM, tariffs, or something else.
You can still get the 32GB variant direct from Radxa off AliExpress for about $412 USD. Much more than launch costs (probably due to cost of ram), but that's actually still cheaper than the Milk-V Titan. The Titan ships with empty RAM slots, and you'd wind up paying another ~$200 to get 2x16GB of DDR4, which is slower than the soldered on LPDDR5 on the Orion.
If you don't need the full PCIe slot, there's also smaller SBC boards (either exactly micro-ITX or similar footprint) using the same SoC: The OrangePi 6 Plus and Radxa O6N. The OPi is available readily for $260 with 32GB LPDDR5, though admittedly the RAM is lower spec than what ships on the Orion O6.
These are my favorite sub $500 SBCs available today. Great Linux support and you need to move up to something like the LattePanda Sigma at over $600 to get something outclassing them in a similar form-factor, but then there's no option for directly slotting a full-size GPU either.
2 replies →
Where are the RVA23 boards that have been hinted at for so long?
These are still very early days for RISC-V, but I’m always happy to see things progress in this space. No, this isn’t a viable desktop for the average consumer, but if it makes the architecture more accessible for the types of weirdos who tend to pave the way for the rest of us, it’s good.
What are the chances this will outperform ARM based computers in the next 15 years? Will we get Macbook airs with this in the fourties?
I just got a Milkv Mars and it is bit rough around the edges. Discord group helped me to get a Debian running on it but I would not say it was simple or easy to get it working.
Is it really this much slower than a Raspberry Pi 5? https://browser.geekbench.com/v5/cpu/compare/23667112?baseli...
tldr; 236 vs 666 single core score
From your link it seems to be 3x slower. It's not clear to me why this comparison is relevant.
I was wondering about the value proposition. But I guess it's a more like a dev / tinkering board then.
1 reply →
For integer workloads it seems closer to 60% of RPi 5 performance. There are some benchmarks that depend on vector support or dedicated CPU instructions for good results, and they skew the results.
A TL;DR doesn't explain everything. The Milk-V Titan doesn't have Vector instructions or crypto, while the Pi 5 does. It's very clearly a broken benchmark.
This is why a bunch of RISC-V people won't buy boards without RV Vector instructions.
Considering you can get a more core dense package on x86 for that price it is better to wait.
2.0ghz isn’t a whole lot of performance for RISC-V system.
Really, I don't get why would anyone buy these priced RISC-V development boards over much cheaper ARM-based variants that are faster.
What is the target audience for these development boards anyway?
People who think "it's open source bro! Boo ARM!" without understanding how peripheral IP works.
Until the risc v ecosystem receives upstreamed and maintained support it's going to be a hard sell vs x86 that 'just works'.
Kinda pricey? You can get an entire M4 Mac Mini for $499
But why are we still slapping on woefully tiny stock coolers that spin so fast your room sounds like an RC racing arena?
So slow.
riscv is going to start having brand issues with these hardware offerings (if it doesn't already.)
sure, prototypes are good. but maybe it shouldn't be sold as a general product, because it implies that the sellers deem it a good product (when it obviously isn't.)
maybe it should be a closed offering, e.g. we're only making 1000, and we're only sending them to select few specialists/reviewers.