SiFive HiFive Unmatched Hands-On, Initial RISC-V Performance Benchmarks

[rene]

I actually debugged, and developed a Linux kernel patch to have modern, even RDNA2 amdgpu work with RISCV on this board: https://www.youtube.com/watch?v=Sv4-_a_3BKg I burned a whole weekend on this, and neither AMD nor SiFive responded to my inquires if they want to pay even just a few hours of my time to finish the modifications to up-streamble code quality :-/ Maybe I do it soon anyway, for the YT views and https://patreon.com/renerebe

[agd5f]

I actually debugged, and developed a Linux kernel patch to have modern, even RDNA2 amdgpu work with RISCV on this board: https://www.youtube.com/watch?v=Sv4-_a_3BKg I burned a whole weekend on this, and neither AMD nor SiFive responded to my inquires if they want to pay even just a few hours of my time to finish the modifications to up-streamble code quality :-/ Maybe I do it soon anyway, for the YT views and https://patreon.com/renerebe

I'm not sure who you contacted, but I was not aware of any of the work you did. Ideally you'd contact the development mailing lists or driver maintainers.

[rene]

I'm not sure who you contacted, but I was not aware of any of the work you did. Ideally you'd contact the development mailing lists or driver maintainers.

I did not consider it polite to ask on mailing lists for funding. From all LinkedIn contacts I found only Bridgman responded. From SiFive nobody reacted. If there are means within AMD to sponsor some hours of developers time I'd love to finish this patchwork sooner than later ;-)

[brad0]

Unfortunately the Raspberry Pi 400 is a far more powerful, fully functional, all in one computer. And it's only $100. And you can do all kinds of cool things with it, including using it as an ARM development system.

So the very expensive, low powered, SiFive HiFive Unmatched board is only going to be purchased by those who have an immediate need to develop for RISC-V, and that's not very many people.

It's a shame, because unless SiFive and other RISC-V companies can compete in price and performance with ARM and x86 they are not going to succeed. I mean really, just looking at the dismal performance of this board is heartbreaking.

How can you say you're a moron without saying it.

[agd5f]

I did not consider it polite to ask on mailing lists for funding. From all LinkedIn contacts I found only Bridgman responded. From SiFive nobody reacted. If there are means within AMD to sponsor some hours of developers time I'd love to finish this patchwork sooner than later ;-)

I doubt there is an easy path to funding this sort of work from the corporate side unfortunately. AMD would probably prefer that you purchase an AMD (rather than a SiFive) CPU

[rene]

I doubt there is an easy path to funding this sort of work from the corporate side unfortunately. AMD would probably prefer that you purchase an AMD CPU

but I have plenty https://www.youtube.com/watch?v=tFNKXSZGyEo of https://www.youtube.com/watch?v=RXXBFcQ0I-M AMD https://www.youtube.com/watch?v=pC4JCPb4v1Q CPUs! ;-) (and obviously more)

It's a bit ironic to start with "not aware, where did you ask", just to follow up with "doubt there is an easy path to funding this sort of work" though :-/ If it helps, I was eying an TR 5990x next, maybe AMD has one to spare?

PS: This is exactly why I started the YT channel, to have means to finance independent OpenSource work without begging for money for each change and month.

[jrtc27]

I actually debugged, and developed a Linux kernel patch to have modern, even RDNA2 amdgpu work with RISCV on this board: https://www.youtube.com/watch?v=Sv4-_a_3BKg I burned a whole weekend on this, and neither AMD nor SiFive responded to my inquires if they want to pay even just a few hours of my time to finish the modifications to up-streamble code quality :-/ Maybe I do it soon anyway, for the YT views and https://patreon.com/renerebe

I assume the only major thing blocking it is the same as I found trying to use the AMDGPU driver on FreeBSD: that DCN (as used by VEGA and above; the older DCE doesn't) uses floating point and so you need to (a) modify the build system to add fd to -march for the DCN files (b) implement kernel_fpu_begin/end or equivalent for RISC-V like x86, AArch64 and PowerPC all do (c) call it from dc_fpu_begin/end. The existing driver already works fine for RISC-V on FreeBSD if you forego the display controller (which is generally something people want, especially as you're not going to be doing AI/ML/HPC/mining on the Unmatched), at least it attached to the GPU, initialised it, uploaded firmware blobs etc without issue. But maybe Linux is missing something else on RISC-V compared with FreeBSD.

[jrtc27]

RISC-V = Linux

Other operating systems are in the early stages (startup only)

In addition, the Linux kernel has recently added many features to RISC-V

That's not true. Upstream FreeBSD actually supported RISC-V before Linux did (landed at the start of 2016 and tracked the privileged specification as it saw major changes over the coming years on the path to ratification, whereas Linux wasn't until late 2017). Same goes for transparent superpage support (Linux calls it "transparent hugepages"), support for that landed in FreeBSD back in 2019 but it was in the news just earlier this year in June that Linux was adding support for it on RISC-V. Or UEFI, our bootloader "just works" whereas upstream GRUB (unless it's changed very recently) still doesn't support RISC-V. FreeBSD has also had installer images you can download and use as you would on other architectures. So FreeBSD and Linux trade punches for RISC-V (some things FreeBSD supports better, some things Linux supports better, in part because most of the people working on RISC-V specifications only really care about Linux so in-development specifications will see the spec authors writing their proofs of concept for Linux/glibc rather than FreeBSD, and similarly current hardware vendors only write drivers for Linux so as a FreeBSD developer my first week with the Unmatched was spent bringing up kernel support for the various devices whereas Linux had patches submitted before the boards even shipped).

I imagine OpenBSD is still pretty shaky though (but they in theory support the Unmatched), NetBSD has some code but I don't know how much is working yet (for a long time they had old bit-rotted code for an earlier draft of the ISA), let alone how stable it is, and Haiku only recently gained a port, so I think it's fair to say none of those are ready for serious use.

[Dawn]

What in the world. I hope you are kidding, because these look like scam prices.

It's as if I were to sell water, but I call it enterprise-class water and sell one small bottle for $1000.

Low volume test chips and low volume boards. There's a lot of NRE being amortized there. Four digits is totally normal for full-featured reference boards for embedded processors.

[davidhendricks]

a boot firmware (UEFI) takes care of initializing the CPU, all the stuff on the motherboard, then hands over everything to a generic OS that finishes off the boot process. That means no hardware or device-specific kernels or OSes

Feast your eyes on https://uefi.org/sites/default/files...I_Spec_2_7.pdf and then tell us if you still think that:
a) UEFI is not an OS
b) That it's preferable to embedded Linux

And if you still want UEFI on RISC-V after digesting that, head here: https://github.com/riscv-admin/riscv-uefi-edk2-docs