Quartz64 Model A & B benchmarks vs. RK3399 sbc's

[Silver]

Am I correct in my perception that SBC's built upon either of the RK3566 and RK3568 CPU's will not yield speed benchmarks quite as fast as the RK3399 CPU or the OP1 CPU, and that it will only be with the release of SBC's built upon the delayed RK3588 CPU that the benchmarks set by the RK3399/OP1 CPU based SBC's will be exceeded (and hopefully well exceeded)?

[evilbunny]

Am I correct in my perception that SBC's built upon either of the RK3566 and RK3568 CPU's will not yield speed benchmarks quite as fast as the RK3399 CPU or the OP1 CPU, and that it will only be with the release of SBC's built upon the delayed RK3588 CPU that the benchmarks set by the RK3399/OP1 CPU based SBC's will be exceeded (and hopefully well exceeded)?

I think the Quartz is more for people interested in doing things with AI

[lot378]

Benchmarks are pretty meaningless since they isolate and measure only one attribute i.e. speed. Also, if you want to use this metric at least try to compare like-for-like the RK356x are successors to the RK3288 and RK3588 is what you ought to compare with RK3399. As far as AI goes, there are better RockChip CPUs available with NPUs for AI than either RK356x with triple the TOPs. Even the RK3399 has an NPU but nobody really talks about that being as "more for people interested in doing things with AI" kind of context.

The RK356x are like a Jack-of-all-Trades and do a little of everything but more refined than RK3288.

[zer0sig]

Depends on the task. For general purpose computing like microservers running established mature code, I'm going to say slower than the RP64 but faster than the R64. Throw AI/NPU type tasks at it and it should thump anything else PINE has released (the SOEDGE is the only other released device with an NPU and it has considerably less CPU power). So figure out what you want to do, if you want a machine that can be a light server similar to a rock64 but dabble in some AI (maybe visual processing for output from a pinecube), this is the thing you want. if you're looking for benchmarks and more classic linux apps, the RP64 is probably a better bet, and if you want really low power usage the PINE64s are probably a better choice.

[CounterPillow]

Due to the current clock layout (as of time of writing, July 2021), performance on Linux (both mainline and AFAIK bsp) is quite poor, and not reflective of what the hardware is capable of. Because of this, any benchmarks you see are likely from some Android image, which is going to be of questionable applicability.

The RK3566 comes with four Cortex-A55 cores. These are in-order cores, meaning they do not issue instructions out-of-order like modern desktop CPUs or the ROCKPro64's two "big" A73 cores. However, they use a more recent microarchitecture. So expect performance to be worse than the ROCKPro64 as you're comparing "little" cores to "big" cores. It'll however be much improved over the more directly comparable ROCK64, which uses four Cortex-A53 cores (which are the preceding cores in that line of in-order ARM "little" cores).

As for GPU, the RK3566 will be very interesting; unlike the ROCK64, it uses a newer version of the Mali IP, which means it is supported by the FOSS panfrost driver (and not the lima one). This already gets us up to OpenGL 3.1 with many extensions of more recent OpenGL versions supported. See mesamatrix for details. (In case you don't know, OpenGL versions past 3.0 are mostly collections of ratified extensions, so a GPU can support OpenGL 4.x level features in an OpenGL 3.1 context.) Of course, the newer GPU IP comes with generally improved performance across the board, though the RK3566's GPU is not a "full" Mali G52 implementation, but a cut down one with one shader core and two execution engines. It should still perform admirably and run circles around the ROCK64.

As an aside note, panfrost support means we might also eventually get Vulkan API support through the (currently very experimental and self-proclaimedly "broken") panfrost Vulkan implementation.

The NPU is a topic I won't go into as I'm not experienced in it, but as some have mentioned, it can hardware accelerate tensor operations.

From what I know, PCIe performance should be improved compared to the ROCKPro64. The RK3566 uses a licensed PCIe implementation instead of the in-house one that Rockchip used previously, which is likely going to eliminate some issues the ROCKPro64 had with stability that will allow the link to run at actual PCIe 2 speeds.

What you should be doing is comparing the Quartz64 to the ROCK64 or the PineA64, not the ROCKPro64. I suspect the comparison to the ROCKPro64 is due to the current pricing, and some of the "pro"-level features like PCIe.

The Quartz64 is most interesting as a test bed for the RK3566 SoC. The SoC's in-order cores are aimed at power efficiency, and brings with it many features aimed at mobile applications, such as a wealth of PWM pins, which I've been told are often used in mobile applications to manage power consumption of peripherals. The 22nm node it is manufactured on, while not cutting-edge, is still a denser node than what the previous Rockchip SoCs used, and therefore will also have significant power (and heat dissipation) advantages.

[stuartiannaylor]

I have been puzzled by the offerings with the rk356x as the SoC has some killer features but as a general purpose SBC its not.

Could of been the lowest cost 3 sata board with 1gbe nic going and a amazing board for that.

0.8Tops NPU is OK for some AI likely vision that CSI gives and the cut down Mali G52 2EE can also be used as a co-processor with arm-nn but it is a cut down G52 and think single core as 2EE does not mean MP2.


It seemed to get offered as a general purpose SBC because we make GP SBC but when you look at the end product of format given it does little more than what was already avail.

The mux for the RK356x looked initially quite exciting for some specific purpose boards filling some niches that do have a market where less is likely more.

  

I think Rockchip created a very flexible SoC but don't think they intended for every interface to be populated for a single application, so likely ended up less cost effective than intended.