Talk about Zero2

I would believe you need to talk to your Amlogic contact.

When VIM3 was released A311D was stuck at 1800/2000 MHz but later they got a BLOB from Amlogic allowing to clock the cores higher. With Armbian A311D on VIM3 is at 2400/2000 MHz.

Same story with Hardkernel, they started at 1800/1900 MHz, then got a BLOB to allow for 2000/1900 and are now at 2400/2015. They are talking about using now a S922X-B and at least it’s a C stepping and not A as on the N2.

EDIT: Armbian for whatever reasons seems to switch back with N2 to 1800/1900 MHz with its 22.08 release. Upgrade your distro, get lower performance as every average user expects! In the meantime Debian images (most probably by meveric) are already at 2000/2000 MHz.

Khadas had to do some deal with Amlogic as the MCU blob was licenced and on release the Vim3 it was locked but later releases its unlocked or at least it has predefined OC rates to choose from.
Its in the forum and again with my memory its foggy but a Google ‘VIM3 OC’ should get you there.
It was a bit similar to the NPU as users had to sign a weird licence agreement to get the verisilicon toolkit.

I like too see the following

1.) 8 GB Ram Option
2.) Wifi6 for WPA3 Enterprise Safety maybe white E
3.) An Touchdisplay Case with Battery maked from aluminic

Whats your wishes ?

best regard

Any updates Jack? Clearly the “before September” ship date did not happen.

1 Like

+1 here. Any info? :grinning: If the wifi would be good in the zero, i could be happy, but unfortunately it’s still not working as intended.

Hi Yuntinan!
Do you have anything about release date?

Nothing so far. ZERO 2 is kinda on the back burner right now as we are rushing through ROCK 5B release, and now preparing for Radxa E23/E25 releases.

Is the Zero2 concept close to the chopping block?

No. I think we have a good stock of A311D and were looking for possibly S905D3 swap to further reduce the price. The design is quite good in the first go and we only did minor bug fixes so far (unlike a certain Model B…). It is just not that high of a priority.

Would that not be a very small upgrade over the S905Y2 Radxa Zero? Apart from the NPU and A55 vs A53 there is not an awful lot of difference but I could be wrong but I think the memory bottle neck to the GPU in the S905D3 was fixed and even though the same Mali-G31 MP2 the S905D3 might in operation provide better results but with my memory I would have to check if that is right as a foggy memory now.
I guess if the A311D is not cost effective its not cost effective as the Khadas Vim3 Basic (2gb) is $10 less than a Rock5b (4gb) which is prob a hard sell as when avail I know which one I would prefer.

I agree, this makes for a far less intriguing sbc. Plus the A311D is an hexa-core processor with four Cortex A73 cores and two Cortex A53 cores. Also wouldn’t that be dropping the possibility of having CAM support by using a S905D3? I believe so.

The primary issue with Zero from our users is the lack of CSI and DSI interfaces. S905D3 plugs those 2 holes with a basic NPU, so it could be a mid-step between S905Y2 and A311D. We also did not plan any SKU with less than 4GB memory on Zero 2 since the SoC is so premium, so S905D3 could allow us to fill the price gap in between on a largely similar/exact same design.

I do not believe the intention is to drop A311D altogether. The only thing we did with S905D3 so far is just a simple chip swap and a test boot with A311D image (it didn’t boot). So if we are serious about retire A311D entirely we would surely do more than that.

I actually kindly received a Zero2 pre release board and its a great little board and have been wondering what happened to release as things just seemed to stop.
My main curiosity was price due to the khadas pricing, I quite like the Khadas Vim3 but IMO the Rock5B pricing really kills its attractiveness, as that is a hell of a lot more SBC for $10 more.
From memory I got in my head a max of $75 for the A311d and if its premium is above that then likely its a dead duck.
I am hoping for a Rock5A with the RK3588S onboard that will be less cost than the Rock5B that makes me think the $75 mark is approx right or maybe there are better options of not much different cost to go for.

Premium keeps being stressed and this is making me think otherwise and maybe its just not a wise idea as the Radxa product line maybe already bloated with functionally & performance wise quite similar offerings which must kill economies of scale and partition user and support bases that are a big part of Raspberry success.

If a S905D3 2GB is nearer the RadxaZero price than maybe a A311D is nearer a Rock5b it could be option if the CSI & DSI interfaces are such a big issue. Can it be even nearer Zero price and maybe even provide a 1GB model? Also maybe think of dropping the 40pin GPIO for something of higher density that can use optional breakout board of standard Pi pinout to stop pin mux revision musical chairs ( I like what Khadas did with the edge2 with 2x 30 & pogo pads and been wondering for a while if onboard 40pin is now just a awkward legacy that can be just an optional daughter board).
If a SBC is not 100% pi format to garner drop in place compliance then why try with what is really a peculiar format based on early pi legacy than any real advantage?

Raspberries achilles heel is the VC4/6 GPU as it sucks big style and whatever they may claim its still a pretty mediocre desktop experience / retro gaming experience that maybe if your not a Pi Fan boy DSI is important to garner lower cost hat based displays but CSI likely a lesser need as Raspberry has $15 Zero2 with a CSI-2 that can provide the headless type of apps relatively easy even if it lacks an onboard NPU.

Things have gone bat-shit-crazy as 1st we had the silicon shortage and now we have global inflation and I am wondering if Raspberries current out of stock status is more due to cost than silicon availability.
If your having such reservations maybe it is better to park that bus than implement another SBC competing in the same space as other Radxa products whilst further splitting your own user base.

Stuartiannaylor has some great points. There are plenty of boards with GPIO that I almost never use (except to power fans…) and CSI/DSI which I never use. Unique and space-saving features like pogo-pins and 200-pin SO-DIMM connectors like those used on compute modules would be much more welcome.

The Rock5 model B is incredible but limited pre-orders mean we are already seeing artificial inflation ballooning prices well into the $200+ range. The Zero 2 presents a more affordable option, finally with enough processing power to work as a tiny, low-wattage PC replacement, beating every competitor in that form factor. The A311D is crucial to maintaining that performance advantage, and I’m sure many people would be willing to pay extra for it. (Within reason, of course.)

I understand that there are many different use-cases, but I greatly value the additional CPU cores, 4GB of RAM (the bare minimum for my needs), TF card slot, Wi-Fi, and good USB-C ports. In the future, I dream of M.2 support, MicroSD Express, USB4, 8GB of RAM, etc… But for now, just getting a Zero2 (with the A311D) before the holidays would be wonderful.

PS can someone help with my memory as I can not remember if it was the G31-Mp2 of the Zero or the G52-MP4 of the A311D produced much worse results than expected due to the arrangement Amlogic had chosen for the memory bus which acted a choke point.

I think it might be the g52-MP4 on the A311D but maybe it was the original zero and the S905D3 is very similar to the S905Y2 but received a better GPU/Memory implementation and the 3rd iteration was largely to fix that oversight and a few other additions that the D chips give over the dongle type Y ones.
So even though the GPU looks identical the S905D3 is much faster in operation or its the A311D that still retains a choke point.
I could google it but bet someone on here has read all about it also but doesn’t have my level of amnesia.

With some further thoughts to the Zero2 and the Zero there seems to be a concerted effort to clone raspberry named products but be far off in terms of hardware clone or at least drop in compatible product.
Radxa Zero was a pretty close clone of a much more powerful SoC S905Y2 that they crammed into a zero format sized board that the closest hardware wise it came was approximating a Zero.
The best product by far Radxa does and I am eagerly awaiting its arrival is when finally they stopped trying to make bad clones of the raspberry pi and create from scratch their own killer format and design The Rock5b is absolute amazing and hopefully there will be a Rock5a (not cm module but a cut down basic no frills rk3588s sbc) that likely competes in the same price space as the A311D and makes it a redundant product.

But also the Zero2 needed to be a bigger deeper board with 2x USB C and has absolutely no drop in compatibility and is Zero because its a bigger brother using an Amlogic chip to the Zero and that where it stops.
If you look at the data sheet of the S905Y2 or S905D3 or A311D you will see how feature rich these SoCs are and that most of its been cast off so it can bear some obscure resemblance to a Pi product that range really from not very close to completely not whilst throwing away a huge array of features in the effort.

The A311D is hugely feature rich and so much is cast off to fit into a completely non zero format no wonder its termed as a premium product in comparison to $15 Zero2 because the chosen SoC and destination design is an extremely ill fit.

You need to to design around a SoC not have a design format that you try and find a SoC to squeeze into that resembles another product.
You need to maximise its feature list but make options modular via daughter boards likely on short FFC high density ribbon cables / pogo pads to stackable shims such as GPIO, ethernet, 8 channel audio and the vast array of interfaces a modern SoC embeds and maybe combinations.
This means product with much better GPU’s than raspberries Achilles heel of VC4/6 can have cost effective base units focusing on what beats Raspberry that has a series of shims that stack because of the ease of FCC ribbons that are high density and low cost.

“But for now, just getting a Zero2 (with the A311D) before the holidays would be wonderful” is a really bad idea to rush out what is an extremely bad fitting product that likely could end up with so many revisions it could end up in a similar cul-de-sac that happened to the rock-pi-s where the soc is great but maybe the board implementation not so, that went through revision musical chairs so often, its a product I have lost interest in.
This we are struggling with the premium price of the A311D where likely the zero premise was wrong for that premium soc anyways and furthering that by we will keep the ill fitting premise but now force the round peg of a S905D3 into the square peg of a completely non standard “zero” format board with a 40 pin GPIO that still jetsons the majority of the SoCs interfaces and rush to get one produced because of slight embarrassment to jettison the initial idea as bad, because it’s very far from being cost effective…

If your going to employ a S905D3 then go back to the design board cast off any raspberry zero aspirations and create a Radxa design that is best for that SoC with a sensible release schedule as that from what I have seen is when Radxa are at their best.

I think Radxa Zero 2 is much more interesting, also the range of sales is wider, in my opinion, so it seems to be a strange choice.

PS it was the G52-MP4 of the A311D that is choked by its memory arrangement where the Mali-T860 MP4 of the ROCK 4 SE is supposedly faster.

Some of the GLmark2 benchmarks on the RadxaZero2 where good but not that great and I think that added to the problem of its ‘premium’ price.

Sure? The 4 SE is based on RK3399T and there according to datasheet max GPU frequency is 600 MHz and not 800 MHz as with RK3399.

And since mbw numbers were referenced (‘S922x: 4.8 GiB/s RK3399: 6.6 GiB/S’). What do these mbw numbers represent? -t0: memcpy() test, -t1: dumb (b[i]=a[i] style) test, -t2: memcpy() with arbitrary block size

This is a quick search through my sbc-bench results collection. Not generated by mbw but tinymembench:

VIM3/A311D:

Kernel Clockspeeds memcpy memset
4.9 2208/1800 MHz 4600 MB/sec 8990 MB/sec
4.9 2208/1800 MHz 4660 MB/sec 9230 MB/sec
4.9 2208/1800 MHz 4660 MB/sec 9280 MB/sec
4.9 2208/1800 MHz 4690 MB/sec 9280 MB/sec
4.9 2400/2100 MHz 5080 MB/sec 9350 MB/sec
5.10 2400/2016 MHz 4370 MB/sec 6720 MB/sec
5.10 2400/2016 MHz 4420 MB/sec 6640 MB/sec
5.10 2400/2016 MHz 4770 MB/sec 6580 MB/sec
5.10 2400/2016 MHz 4770 MB/sec 6580 MB/sec
5.10 2400/2016 MHz 4840 MB/sec 8260 MB/sec
5.10 2400/2016 MHz 4850 MB/sec 7370 MB/sec
5.10 2400/2016 MHz 4850 MB/sec 7380 MB/sec
5.10 2400/2016 MHz 4850 MB/sec 8100 MB/sec
5.16 2208/1800 MHz 5000 MB/sec 9560 MB/sec
5.17 2208/1800 MHz 4800 MB/sec 9330 MB/sec
5.17 2208/1800 MHz 4860 MB/sec 9150 MB/sec
5.18 2208/1800 MHz 5000 MB/sec 9840 MB/sec
5.18 2208/1800 MHz 5020 MB/sec 9650 MB/sec
5.18 2208/1800 MHz 5070 MB/sec 9460 MB/sec

ODROID-N2/S922:

Kernel Clockspeeds memcpy memset
5.10 1992/1908 MHz 3740 MB/sec 7500 MB/sec
5.10 1992/1908 MHz 4250 MB/sec 9090 MB/sec
5.10 1992/1908 MHz 4260 MB/sec 9080 MB/sec
5.10 1992/1908 MHz 4260 MB/sec 9080 MB/sec
5.10 1992/1908 MHz 4270 MB/sec 7670 MB/sec
5.15 1908/1800 MHz 3900 MB/sec 7440 MB/sec
5.15 1992/1908 MHz 3910 MB/sec 7700 MB/sec
5.15 1992/1908 MHz 3990 MB/sec 7970 MB/sec
5.15 2004/1992 MHz 3820 MB/sec 7790 MB/sec
5.15 2004/1992 MHz 3850 MB/sec 7630 MB/sec
5.15 2004/1992 MHz 3850 MB/sec 7710 MB/sec
5.17 1992/1908 MHz 4190 MB/sec 8690 MB/sec

ODROID-N2/S922-X:

Kernel Clockspeeds memcpy memset
4.9 2400/2016 MHz 3850 MB/sec 5970 MB/sec
5.10 2400/2016 MHz 3770 MB/sec 7610 MB/sec
5.10 2400/2016 MHz 3770 MB/sec 7620 MB/sec
5.10 2400/2016 MHz 3910 MB/sec 7220 MB/sec
5.10 2400/2016 MHz 3980 MB/sec 7670 MB/sec
5.10 2400/2016 MHz 3990 MB/sec 7460 MB/sec
5.10 2400/2016 MHz 4000 MB/sec 6980 MB/sec
5.10 2400/2016 MHz 4000 MB/sec 7030 MB/sec
5.10 2400/2016 MHz 4020 MB/sec 7140 MB/sec
5.10 2400/2016 MHz 4020 MB/sec 7320 MB/sec
5.10 2400/2016 MHz 4030 MB/sec 7120 MB/sec
5.10 2400/2016 MHz 4030 MB/sec 7690 MB/sec
5.10 2400/2016 MHz 4030 MB/sec 7690 MB/sec
5.10 2400/2016 MHz 4070 MB/sec 7220 MB/sec
5.10 2400/2016 MHz 4090 MB/sec 7170 MB/sec
5.10 2400/2016 MHz 4140 MB/sec 7410 MB/sec
5.10 2400/2016 MHz 4140 MB/sec 7710 MB/sec
5.10 2400/2016 MHz 4160 MB/sec 7680 MB/sec
5.10 2400/2016 MHz 4180 MB/sec 7700 MB/sec
5.10 2400/2016 MHz 4190 MB/sec 7690 MB/sec
5.10 2400/2016 MHz 4200 MB/sec 7680 MB/sec
5.10 2400/2016 MHz 4210 MB/sec 7730 MB/sec
5.10 2400/2016 MHz 4220 MB/sec 7730 MB/sec
5.10 2400/2016 MHz 4220 MB/sec 7730 MB/sec
5.10 2400/2016 MHz 4240 MB/sec 7740 MB/sec
5.10 2400/2016 MHz 4290 MB/sec 7730 MB/sec
5.14 2400/2016 MHz 4030 MB/sec 7120 MB/sec
5.15 2400/2016 MHz 4000 MB/sec 7660 MB/sec
5.15 2400/2016 MHz 4010 MB/sec 7680 MB/sec
5.15 2400/2016 MHz 4030 MB/sec 7700 MB/sec
5.15 2400/2016 MHz 4040 MB/sec 7680 MB/sec
5.15 2400/2016 MHz 4100 MB/sec 7730 MB/sec
5.15 2400/2016 MHz 4140 MB/sec 7720 MB/sec
5.16 2400/2016 MHz 3960 MB/sec 7610 MB/sec
5.16 2400/2016 MHz 4160 MB/sec 7460 MB/sec
5.16 2400/2016 MHz 4190 MB/sec 7470 MB/sec
5.16 2400/2016 MHz 4200 MB/sec 7470 MB/sec
5.16 2400/2016 MHz 4200 MB/sec 7470 MB/sec
5.16 2400/2016 MHz 4200 MB/sec 7480 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7410 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7420 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7460 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7470 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7480 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7480 MB/sec
5.16 2400/2016 MHz 4210 MB/sec 7480 MB/sec
5.16 2400/2016 MHz 4220 MB/sec 7450 MB/sec
5.16 2400/2016 MHz 4220 MB/sec 7460 MB/sec
5.16 2400/2016 MHz 4220 MB/sec 7460 MB/sec
5.17 2400/2016 MHz 4020 MB/sec 7690 MB/sec

You can read about what Collabora found and what is in the Khadas forums.

I ran GLmark2 on the Radxa Zero2 and it was good but not great as some might expect.

radxa@radxa:~/mesa$ glmark2
=======================================================
    glmark2 2021.12
=======================================================
    OpenGL Information
    GL_VENDOR:      Panfrost
    GL_RENDERER:    Mali-G52 (Panfrost)
    GL_VERSION:     3.1 Mesa 21.3.8 (git-813ee839be)
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0
    Surface Size:   800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 772 FrameTime: 1.295 ms
[build] use-vbo=true: FPS: 847 FrameTime: 1.181 ms
[texture] texture-filter=nearest: FPS: 895 FrameTime: 1.117 ms
[texture] texture-filter=linear: FPS: 895 FrameTime: 1.117 ms
[texture] texture-filter=mipmap: FPS: 905 FrameTime: 1.105 ms
[shading] shading=gouraud: FPS: 686 FrameTime: 1.458 ms
[shading] shading=blinn-phong-inf: FPS: 701 FrameTime: 1.427 ms
[shading] shading=phong: FPS: 601 FrameTime: 1.664 ms
[shading] shading=cel: FPS: 623 FrameTime: 1.605 ms
[bump] bump-render=high-poly: FPS: 367 FrameTime: 2.725 ms
[bump] bump-render=normals: FPS: 1044 FrameTime: 0.958 ms
[bump] bump-render=height: FPS: 1021 FrameTime: 0.979 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 768 FrameTime: 1.302 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 345 FrameTime: 2.899 ms
[pulsar] light=false:quads=5:texture=false: FPS: 857 FrameTime: 1.167 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 308 FrameTime: 3.247 ms
[desktop] effect=shadow:windows=4: FPS: 812 FrameTime: 1.232 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 95 FrameTime: 10.526 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 87 FrameTime: 11.494 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 228 FrameTime: 4.386 ms
[ideas] speed=duration: FPS: 445 FrameTime: 2.247 ms
[jellyfish] <default>: FPS: 583 FrameTime: 1.715 ms
[terrain] <default>: FPS: 39 FrameTime: 25.641 ms
[shadow] <default>: FPS: 439 FrameTime: 2.278 ms
[refract] <default>: FPS: 79 FrameTime: 12.658 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 796 FrameTime: 1.256 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 795 FrameTime: 1.258 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 796 FrameTime: 1.256 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 798 FrameTime: 1.253 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 793 FrameTime: 1.261 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 793 FrameTime: 1.261 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 791 FrameTime: 1.264 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 789 FrameTime: 1.267 ms
=======================================================
                                  glmark2 Score: 630 
=======================================================

radxa@radxa:~/mesa$ glmark2-es2
=======================================================
    glmark2 2021.12
=======================================================
    OpenGL Information
    GL_VENDOR:      Panfrost
    GL_RENDERER:    Mali-G52 (Panfrost)
    GL_VERSION:     OpenGL ES 3.1 Mesa 21.3.8 (git-813ee839be)
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0
    Surface Size:   800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 816 FrameTime: 1.225 ms
[build] use-vbo=true: FPS: 1019 FrameTime: 0.981 ms
[texture] texture-filter=nearest: FPS: 1061 FrameTime: 0.943 ms
[texture] texture-filter=linear: FPS: 1060 FrameTime: 0.943 ms
[texture] texture-filter=mipmap: FPS: 1077 FrameTime: 0.929 ms
[shading] shading=gouraud: FPS: 818 FrameTime: 1.222 ms
[shading] shading=blinn-phong-inf: FPS: 826 FrameTime: 1.211 ms
[shading] shading=phong: FPS: 711 FrameTime: 1.406 ms
[shading] shading=cel: FPS: 728 FrameTime: 1.374 ms
[bump] bump-render=high-poly: FPS: 409 FrameTime: 2.445 ms
[bump] bump-render=normals: FPS: 1283 FrameTime: 0.779 ms
[bump] bump-render=height: FPS: 1237 FrameTime: 0.808 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 777 FrameTime: 1.287 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 346 FrameTime: 2.890 ms
[pulsar] light=false:quads=5:texture=false: FPS: 984 FrameTime: 1.016 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 305 FrameTime: 3.279 ms
[desktop] effect=shadow:windows=4: FPS: 817 FrameTime: 1.224 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 90 FrameTime: 11.111 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 89 FrameTime: 11.236 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 224 FrameTime: 4.464 ms
[ideas] speed=duration: FPS: 473 FrameTime: 2.114 ms
[jellyfish] <default>: FPS: 630 FrameTime: 1.587 ms
[terrain] <default>: FPS: 41 FrameTime: 24.390 ms
[shadow] <default>: FPS: 477 FrameTime: 2.096 ms
[refract] <default>: FPS: 86 FrameTime: 11.628 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 906 FrameTime: 1.104 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 909 FrameTime: 1.100 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 907 FrameTime: 1.103 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 909 FrameTime: 1.100 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 862 FrameTime: 1.160 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 901 FrameTime: 1.110 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 903 FrameTime: 1.107 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 862 FrameTime: 1.160 ms
=======================================================
                                  glmark2 Score: 713 
=======================================================

I got rid of my RockPi4 a long time ago so can no longer post GLmark2 or ES on that but I think generally people where expecting it to come some where in the middle between of the Rock4 & Rock5 but as you will see in the above with the images current falls a long way short.

It was Alyssa Rosenweig who was working on the Mesa drivers at the time mentioned about the memory architecture was a choke point for the GPU as that is why figures are lower than what they expected for a G52MP4 you can not seem to get the full tweet anymore and as per usual with my memory I have forgot the full details, but didn’t matter as the glmarks where much less than expected.

As you can see above though the GPU aint that great and many where expecting more from the G52 and maybe someone will post current RK3399 glmark2 / es scores to compare to the above so we have a like for like as its the gpu/memory architecture I am talking about not just a series of mem speed tests.

The G32-mp2 on the Radxa Zero was posting Glmark2 scores of approx 385 and many expected with a G52 MP4 much more than a bit less than double and it was slightly disappointing with the Rock5b managing approx x10 the Radxa Zero and x5 the Zero 2, so yeah it was a long way from being between the 2.

No I can’t since there are just some numbers posted and we neither know what these numbers mean nor how they were generated. I understand the claim (you constantly repeat) but I don’t see numbers really backing this.

On modern SoCs there’s devfreq support for all sorts of cores (CPU, GPU, NPU) and memory. On my Rock 5B with performance dmc governor I get 10830 MB/s memcpy reported by tinymembench/sbc-bench. Now to mbw:

root@rock-5b:/home/tk# taskset -c 5 mbw -t0 256 | grep ^AVG
AVG	Method: MEMCPY	Elapsed: 0.07990	MiB: 256.00000	Copy: 3203.905 MiB/s
root@rock-5b:/home/tk# taskset -c 5 mbw -t0 4096 | grep ^AVG
AVG	Method: MEMCPY	Elapsed: 0.56973	MiB: 4096.00000	Copy: 7189.415 MiB/s

One time 3.2 GB/sec, one time +7 GB/sec. What’s the difference? The arraysize_in_MiB parameter one time being small and the other larger? Only indirectly since what we really see is dmc governor at work. Above this was with dmc_ondemand switching somewhat dynamically between between 528 MHz and 2112 MHz with LPDDR4 RAM.

With powersave (528 MHz) it looks like this:

root@rock-5b:/home/tk# taskset -c 5 mbw -t0 256 | grep ^AVG
AVG	Method: MEMCPY	Elapsed: 0.07938	MiB: 256.00000	Copy: 3224.982 MiB/s
root@rock-5b:/home/tk# taskset -c 5 mbw -t0 4096 | grep ^AVG
AVG	Method: MEMCPY	Elapsed: 1.28748	MiB: 4096.00000	Copy: 3181.400 MiB/s

And with performance (2112 MHz) like this:

root@rock-5b:/home/tk# taskset -c 5 mbw -t0 256 | grep ^AVG
AVG	Method: MEMCPY	Elapsed: 0.03323	MiB: 256.00000	Copy: 7703.511 MiB/s
root@rock-5b:/home/tk# taskset -c 5 mbw -t0 4096 | grep ^AVG
AVG	Method: MEMCPY	Elapsed: 0.54355	MiB: 4096.00000	Copy: 7535.656 MiB/s

Also measured memory bandwidth is massively influenced by CONFIG_HZ kernel config. You can get numbers differing factor 2 depending between CONFIG_HZ=100 and CONFIG_HZ=1000.

And as we’ve seen above with dynamic memory clocking mbw behaves somewhat like a RNG depending on arraysize_in_MiB sizes. This is CPU. What about similar mechanisms with GPU?

Point is: you can generate with a CPU bound memory bandwidth tester numbers that might be completely irrelevant for what the GPU cores do.

As for your glmark numbers with A311D should glmark2-es2-wayland report same numbers as glmark2-es2?