BUT the GPU is apparently better which would make this THE SBC.
I will test my 3D MMO engine and give exactly what is what once I receive mine, should be a couple of days.
The Raspberry GPU has a serious cache problem, it can't render a triangle at 60FPS in 1080p!!!
But 100 non-instanced animated characters (each with a unique weapon in hand) at 60FPS and low res (800x600).
Jetson (1/2 Nintendo Switch GPU) does 300 at 60 FPS in 1080p.
If the Visionfive 2 is either:
- 100+ at 60 FPS and 1080p
- 200+ at 60 FPS and 800x600
I'm going ALL IN on Risc-V (my own VM for scripting the engine) and StarFive (buy a few to use as demo for the MMO instead of Raspberry 4/Jetson Nano).More like bad than mad.
This SoC is far more efficient, using just 4.4w on full load and achieving some 80% of rpi4's cpu performance at a much lower power, with no need for a heatsink.
Not going to debate the gflops/w yet, but Raspberry 4 cores are also around 1W each and they kick ass compared to even M1 (much worse OFC, but per $/openess they still win imo)
The reality is that it draws around 10w more often than not.
You will need a heatsink on the Visionfive if the GPU does what I hope it does.
The Raspberry 4 GPU is only 1W vs. 5W on the Jetson Nano!
I'm hoping for a 2-3W GPU on the Visionfive and then you'll need a heatsink for MMO gameplay no question about it.
Longevity is now crucial as hardware peaks, heat kills electronics slowly but oh so surely!
Edit: Do you have a URL for those 3.xW and 4.4W claims... Then I think we wont see 100+ but cache can still be larger so you can have 100 at 1080p and that is enough for mainsteam adoption and replacing all other computers (Switch, PS4, XBOX, phones and pads etc.)!
The future belong to those that compile!
They also give a lower figure that's 3.x W for full load with the GPU off.
It won't need a heatsink, because with its power draw it won't get above 70C even on full load, while the chip is built for industrial temperature range in operation.
For longevity 60C is better. I'm talking multiple decades at constant permanent full blast here.
The interesting part goes:
>As for power consumption, JH7110 is separated into 8 independent power domains. CPU frequency can be configured through software. To achieve a balanced PPA, customers can set the most optimum SoC frequency based on their application scenarios and performance requirements. In sleep mode, the static power consumption of JH7110 is 120 mW. When working on an SBC, with all the main modules under full load, the dynamic power consumption of JH7110 is 4,100 mW. In the application scenarios of soft routers and NAS, where you don’t need GPU and video processing, but only require the dual Ethernet port operation, you can configure the modules on/off through software. And the actual power consumption decreases to 3,300 mW.
So, to summarize:
* 120mW when completely idle.
* 4100mW on full load.
* 3300mW on full load w/o GPU or video processing modules.
This is, I have to say, crazy good relative to rpi4.
>For longevity 60C is better. I'm talking multiple decades at constant permanent full blast here.
Yes, I will at least put a stick-on passive heatsink on mine.
I hope not, and then if I'm right and the GPU is more powerful than the Raspberry 4 one this board will run at 6W or something and then a stick-on heatsink wont do it...
Look at my link to the full copper one if I'm right:
http://www.enzotech.com/cnb_s1l.htm
I received it now and it's great (if it fits) well worth the expensive price!
What I gather from the text is that it's a calculated (from design libraries), rather than measured, full load power draw. Which would make these numbers the upper bound, and thus very good.
I might be wrong.
Either way, as these boards are reaching people, it shouldn't take long until we see measured power draw and temperatures.
https://browser.geekbench.com/v5/cpu/compare/17159543?baseli...
if so, i wonder how much that contributes to the difference...?
Unfortunately, there's no drivers in the current images, and it'll take time to have proper open drivers and integration with common APIs such as vdpau.
Of course, there's a lot of software factors holding it back, such as quality or lack of drivers.
Benchmarks will be worth re-running in a few months, once some level of ecosystem is in place.