This is a decent review of VisionFive 2 as it is right now (early days).
I noticed a few mistakes/omissions. From the top of my mind:
- There's mention of bad cryptography performance. But there is a cryptography acceleration engine. This is not enabled in the current test kernels, but yet patch is being reviewed by Linux upstream. In contrast, the Broadcom SoCs in the other boards VF2 was compared against have no such hardware.
- There's mention of unusably slow youtube, but again, there's a hardware video decode block that's still not usable, yet it is considerably more capable than the one in the Broadcom SoCs.
- Related, Firefox is very slow because JS is interpreted. A RISC-V JIT implementation landed recently and will be present in the 111 release due in a few weeks.
- The SoC GPU is glossed over, but it did deserve more attention. Claimed to be 4x the performance of RPi4's SoC, Imagination Technologies is working on an open driver. This is a public effort as of early 2022, with some code already in Mesa3d upstream.
I am happy that the author did stress that this is early days, and that if the review/benchmarks were to be repeated in the future, the results would be very different.
Get this board (I love mine) if you're curious about and want to play with RISC-V. There's currently nothing faster than the VF2 available at any price, and yet VF2 is available at ~$100.
I wouldn't consider these mistakes or omissions. He's reviewing the board as is and not assuming future progress that may or may not take place in some undetermined time. If I'm looking for a relatively cheep single board computer to play with and am not focused on specific RISC-V development I want to buy a board for what it can do now not what it will be able to do with kernel updates that are not guaranteed.
> I want to buy a board for what it can do now not what it will be able to do
Then buy something else.
My VF2 boards (one 8 GB and one 4 GB) were very clearly sold as "Early Bird" and "Super Early Bird", respectively, and Jeff's will have been too.
They are for early adopters and for developers to use to fill in the missing software support. It is not practically possible to do this without a board in your hands.
It is NOT for the average user right now. In 3 or 6 months it will be.
I'm a little surprised that Amazon hasn't made (or commissioned) a small SBC computer to compete directly with the Raspberry Pi but one that is certified for and pre-loaded with software for AWS IoT applications (including Greengrass) and selling for about $99. At that price point you could sell both to AWS customers looking for inexpensive IoT systems for experimentation (or deployment!) as well as the general enthusiast market who could replace the AWS IoT bits (probably based on Fedora?) and put whatever distro they want on it. This would be a win-win for Amazon since the general enthusiast market could enable volume sales to keep the price of entry for AWS IoT experimenters low enough to try out (creating yet another sales funnel for AWS services).
I wonder if Amazon would consider using a RISC-V CPU for such a device?
For that matter a scaled down version of the chipsets their arm cloud servers use. Where you can build/test in-house and deploy to AWS. I know there's the "why not just build/test in AWS?" as a question, and the answer is sometimes you want to self-host or at least start that way. Or you want to do more than just the web side, but still want to be compatible.
They sorta already do, it's called Echo. I'm not convinced there's a market for what you're describing, or at least not one that's necessarily worth the cost. A lot of the cheap Chinese IoT devices generally available already go through AWS. People with the skills and desire to do that type of thing themselves are both a small market, and less likely to use AWS for the types of projects they'd be building with said device.
I wonder how much of the performance will improve when compilers get better at RISC-V.
It's been a long time since I could beat the compiler at optimizing assembly on x86, yet in the end merely unrolling a loop and keeping an eye on write-read stalls I managed to get a simple "multiply array by const" about 56% less time (more than twice as fast):
I really wish someone would make a framework-laptop compatible board layout for a RISC-V chip. Even if it's not high performance it'd let us treat it like a daily-driver and really contribute to getting the desktop linux experience in better shape for RISC-V
Or if not framework, like the Pine 64. I believe Pine64's laptop is pretty much a laptop shell that houses one of their boards. Make a laptop shell that you can drop in any reasonably dimension-ed SBC and hook it up.
>(and it seems the ISA has CPU internal design simplicity in mind, of course there will be trade off)
There's no such trade-off. The ISA is designed to scale from the smallest embedded microcontrollers to the top supercomputers.
It has the advantage of being designed from a clean slate, decades after the incumbent ISAs, with careful consideration put into every decision made and the hindsight of every other ISA to draw from.
The (relatively cheap) book "RISC-V Reader" presents a good introduction to the ISA and its design, with chapters covering each extension and comparing with incumbent ISAs.
The incumbent ISAs end up looking very bad. Note that the book is written by the main architects of the ISA, so it is of course very biased. They do however manage to keep it reasonably objective and to make really good points.
I purchased a DE10-nano last year with the plan to try some FPGA RISC-V based development... but got lost in the number of extensions and versions of RISC-V kicking around. Has anyone tried this? I'd also be interested how it compares performance wise to the above, and Pi4, see if it worth the effort. Anyway at least it got some good use with MiSTer :) I kinda hope Raspberry adopts RISC-V on their next SBC, but hopefully with more open hardware.
The CPU will likely have a clock speed around 100Mhz, far slower than the 1.5Ghz 64bit cores on the VisionFive 2 or Pi4. The FPGA might still be useful if you want to customize the CPU or integrate other custom hardware.
Yeah unfortunately there isn't really a great place that lists all the extensions with links and ratification status.
But anyway there is a sort of standard set of extensions that "application processors" (I guess CPUs that want to run precompiled code) should support:
RV64GC expands into RV64I + M + A + F + D + C. The CPU in this board also has the Zba and Zbb extensions (which together with a couple of others make up what was originally envisioned as the "B" extension, but it was decided to split it up).
I noticed a few mistakes/omissions. From the top of my mind:
- There's mention of bad cryptography performance. But there is a cryptography acceleration engine. This is not enabled in the current test kernels, but yet patch is being reviewed by Linux upstream. In contrast, the Broadcom SoCs in the other boards VF2 was compared against have no such hardware.
- There's mention of unusably slow youtube, but again, there's a hardware video decode block that's still not usable, yet it is considerably more capable than the one in the Broadcom SoCs.
- Related, Firefox is very slow because JS is interpreted. A RISC-V JIT implementation landed recently and will be present in the 111 release due in a few weeks.
- The SoC GPU is glossed over, but it did deserve more attention. Claimed to be 4x the performance of RPi4's SoC, Imagination Technologies is working on an open driver. This is a public effort as of early 2022, with some code already in Mesa3d upstream.
I am happy that the author did stress that this is early days, and that if the review/benchmarks were to be repeated in the future, the results would be very different.
Get this board (I love mine) if you're curious about and want to play with RISC-V. There's currently nothing faster than the VF2 available at any price, and yet VF2 is available at ~$100.