Question Anyone using ARM CPUs/SOCs?

[whm1974]

I've been looking at Pine64.org products, mainly the upcoming Pinebook Pro and PineTAB, also about reading the ROXK64 Pro as well. Awhile back I was considering getting Raspberry Pi 3B+ for getting into SBCs, I really not sure what I could use for it for. And yes a low cost notebook, even ARM based ones will be far more useful for.

Other then my cheap smartphone, I have no experience with non-x86 systems. So how much usability with reasonable performance I can expect out ARM SOCs such at the Rockchip RK3399 Hexa-Core such as the Pinebook Pro and ROCK64 Pro uses

While I intend to buy the Pinebook Pro, I am wondering about ARM SOCs and ARM based PCs in general using Linux.

 

[soresu]

Further improvements to the open ARM GPU Panfrost driver have Kodi running and approaching OpenGL ES 2.0 feature completeness.
Link here.

Also on the subject of RPI4, the A65-AE recently announced already has a higher single thread performance than the A55 (1.4x A53, A55 is 1.2x A53 according to ARM press materials), and multi thread performance is even higher still because of the SMT change.
While it is Out of Order by design, its power envelope is still around the same as A53/55, so it could definitely be a viable core for RPI4, details on core size are sketchy tho.
I'd be surprised if a consumer variant of this core isnt announced along with A77 in late May/early June.

 

[Thala]

Also on the subject of RPI4, the A65-AE recently announced already has a higher single thread performance than the A55 (1.4x A53, A55 is 1.2x A53 according to ARM press materials), and multi thread performance is even higher still because of the SMT change.
While it is Out of Order by design, its power envelope is still around the same as A53/55, so it could definitely be a viable core for RPI4, details on core size are sketchy tho.
I'd be surprised if a consumer variant of this core isnt announced along with A77 in late May/early June.

They could easily chose A73 for RPI4 given they go with something below 28nm, RPI3 is on a 40nm process....

 

[soresu]

Good news for ARM SBC's, the Rockchip RK3588 for early 2020 will be quad A76 + quad A55 - no clue yet on GPU for that SOC, but the other SOC announced RK3530 uses Mali G52.
No doubt this will benefit ARM chromebooks, and possibly follow the Google OP1 naming to be called OP2.

Also recent news on the Mali open driver front, plans going forward look very promising from this open GPU meetup...

 

[DrMrLordX]

Good news for ARM SBC's, the Rockchip RK3588 for early 2020 will be quad A76 + quad A55

Nice! I wonder if Pine will offer a board with one of those?

 

[whm1974]

Cool, any info on how much memory it can handle and number of PCIe lanes?

 

[soresu]

Rockchip just announced the RK3588 for early 2020 so I wouldnt expect confirmation on any specific board specs for months yet.

Exact specs for the chip itself are thin on the ground beyond the CPU cores, and 2nd gen variants of various proprietary accelerators (including their AI chip NPU 2.0).

The process used is 8nm, which I presume to be similar to, if not the same as the enhanced 10nm process Samsung is using for their latest Exynos 9820 flagship.

The lack of any announced GPU design for RK3588 makes me think that it may be one of the cores to be announced at the end of May with ARM's usual annual consumer press bonanza - so likely either G77 or G53.

Here is the original Chinese press slide:

 

[soresu]

I just found out about some new ARM A-profile extensions that were announced a couple of weeks ago, Scalable Vector Extension 2 (SVE2) and Transactional Memory Extension (TME).

It seems that SVE2 may be targeted to supersede NEON, as it provides superior 128 bit vector performance, as well as allowing for implementations to scale to HPC level 2048 bit vectors.
SVE2 seems to be made so that vectored code can be written once, and scale to whatever vector length hardware the code is run on.

As for TME, I lack the necessary understanding of computer science to understand transactional memory - but the basic gist seems to be that it allows for greater ease in coding parallel applications.

The link to ARM's blog announcement is here.

Its unlikely, but not impossible that one or both of these extensions are due to be in the next big core likely to announced at the end of the month, though strangely they are not directly associated with a particular version of the v8-A ISA in the announcement (the current revision is v8.5-A, while Cortex-A76 is v8.2-A).

 

[Thala]

It seems that SVE2 may be targeted to supersede NEON, as it provides superior 128 bit vector performance, as well as allowing for implementations to scale to HPC level 2048 bit vectors.
SVE2 seems to be made so that vectored code can be written once, and scale to whatever vector length hardware the code is run on.

This already applies to SVE. With SVE2 they just added more instructions/data-types from what i can tell from the documentation.

As for TME, I lack the necessary understanding of computer science to understand transactional memory - but the basic gist seems to be that it allows for greater ease in coding parallel applications.

It allows contending threads to enter a critical region speculatively. This in particular helps for large numbers of cores/threads, where the likelihood of contention is high.

 

[soresu]

Yes, they specifically mentioned media instructions. Likely as the original SVE was designed just for HPC, and they want SVE2 to be able to replace NEON - backwards compatibility with NEON going forward with any new CPU cores that have SVE2 is mentioned in the announcement.

The sheer amount of apps out there likely to be using NEON will mean that it can't be deprecated anytime soon of course, though I wouldnt put it past Apple to come up with some arbitrary date to stop using it in any future App store submissions, like with the A64 transition.

 

[Thala]

Yes, they specifically mentioned media instructions. Likely as the original SVE was designed just for HPC, and they want SVE2 to be able to replace NEON - backwards compatibility with NEON going forward with any new CPU cores that have SVE2 is mentioned in the announcement.
.

SVE is very different to NEON - there will be no backwards compatibility in SVE such it can replace NEON. NEON is mandatory in ARMv8.x and you can optionally add SVE/2.
The key quote is: "For backwards compatibility, the Neon instruction set remains fully supported."
Which essentially means, that the NEON instruction set cannot be remove due to backwards compatibility reasons.

 

[soresu]

I mentioned backwards compatibility in my post in the context of keeping NEON support available for the forseeable future - "The sheer amount of apps out there likely to be using NEON will mean that it can't be deprecated anytime soon of course".

You are correct that SVE is different from NEON, but the ARM article specifically mentions DSP and multimedia instructions being added to SVE2 - "SVE2 builds on the foundations of SVE to bring the benefits of scalable SIMD vector performance and advanced auto-vectorization capabilities to a wider range of software, including DSP and multimedia SIMD codes that currently use Neon." - if this was not to telegraph a future introduction in their own uArch CPU cores, it seems a strange point to underline otherwise.

As you say SVE2 is currently optional for custom uArch cores, the article is basically a 'heads up we made these new extensions, please support them' announcement for compiler coders and other such infrastructure, though I doubt a current optional status prevents them making it mandatory in a future v8.6-A or something.

Also found an interesting quote at the end of the article - "These new architecture technologies, SVE2 and TME, have been in development for several years, along with the associated tools and models, and will provide improved, scalable performance across a range of future A-Profile Arm-based devices."
It doesn't necessarily mean Cortex-A or Neoverse devices, but it's certainly food for thought.

 

[soresu]

There is a link to the PDF detailing the new instructions on the article, which I will also leave here.

One of the slides in the PDF is used in the article, albeit a bit less clear, so I will post it here as it underscores a point in my last post:

 

[Thala]

As you say SVE2 is currently optional for custom uArch cores, the article is basically a 'heads up we made these new extensions, please support them' announcement for compiler coders and other such infrastructure, though I doubt a current optional status prevents them making it mandatory in a future v8.6-A or something.

Deimos and Hercules (2019 and 2020 High perf A-cores) are both v8.2-A and then we have Matterhorn in 2021, which is v9.0A. I can imagine that for v9.0a SVE will be mandatory.

 

[DrMrLordX]

SVE2 has 512-bit SIMD? Wow. I'm curious if they'll need clockspeed regressions for VL512b workloads.

 

[Nothingness]

SVE2 has 512-bit SIMD? Wow. I'm curious if they'll need clockspeed regressions for VL512b workloads.

SVE2 can be 128-bit or 2048-bit or whatever multiple of 128-bit in the middle, it's up to the CPU implementor to decide. That's one of the great advantages of SVE over Intel AVX.

 

[Thala]

SVE2 can be 128-bit or 2048-bit or whatever multiple of 128-bit in the middle, it's up to the CPU implementor to decide. That's one of the great advantages of SVE over Intel AVX.

Indeed the big thing is, that you can write code vector-length agnostic using predicate registers and the vector-length as variable. As example the svcntd() intrinsic returns the number of doubles in the vector.

 

[DrMrLordX]

SVE2 can be 128-bit or 2048-bit or whatever multiple of 128-bit in the middle, it's up to the CPU implementor to decide. That's one of the great advantages of SVE over Intel AVX.

Hmm, interesting. Does that mean SVE code can be recycled in future chip generations that have wider registers?

 

[Thala]

Hmm, interesting. Does that mean SVE code can be recycled in future chip generations that have wider registers?

Precisely thats the idea behind SVE - Code will just run faster on wider units in the future. You dont have to re-compile - just the binary will do.

 

[soresu]

Thala, where did this info come from? - "and then we have Matterhorn in 2021, which is v9.0A" - I assume this to be the name of the rumored new Sophia-Antipolis designed uArch after Hercules, but I hadn't heard any name attached to it until now, nor any mention of v9.0-A for years.

I certainly agree, given the "multi year development" emphasis ARM put on SVE2 and TME in their technical PDF release that it definitely fits a major ISA change, rather than a v8-A increment.

It also gives ARM an ideal opportunity to enforce the security changes in the main ISA for Spectre and Meltdown mitigation, rather than relying on custom vendors to implement v8.5-A for otherwise minimal returns beyond security.

 

[Thala]

Thala, where did this info come from? - "and then we have Matterhorn in 2021, which is v9.0A" - I assume this to be the name of the rumored new Sophia-Antipolis designed uArch after Hercules, but I hadn't heard any name attached to it until now, nor any mention of v9.0-A for years.

Thats from the roadmap.

 

[soresu]

The last roadmap I've seen was the official one from ARM that ends with Hercules next year.

Has there been another leaked roadmap as happened in 2015?

 

[amd6502]

It's a lot less popular than I thought.

http://compgroups.net/comp.sys.acorn.misc/

Surprisingly Xilinix had billions in revenue, and a good fraction of that from acorn servers.

 

[abufrejoval]

If you want something that quite simply works as Linux system on ARM, that won't cost an arm and a leg, but offers reasonable utility, I'd recommend getting a Jetson Nano.

Around 100 $ or €, a high quality (A2 rating) µSD card with 64GB or so and you're set.

Been tinkering around with mine, does offer reasonable 2D and media performance even at 4K, you can play some 3D games at 1080 etc. and it has 4 USB3 ports for anything from storage, cameras, WLAN etc. and even a somewhat less usable type E PCIe slot.

Four GB of RAM will support quite a bit of desktop applications, but you need to add swap, because this is (Ubuntu) Linux not Android.

Very affordable, 100% silent actually useful and with a full modern and rather well maintained Linux stack.

And if you've stopped playing with it, it can still act as a home server appliance for backup storage, NextCloud etc. for 24/7 operation with a maximum of 10Watt power consumption, much less on idle.

 

[DrMrLordX]

@soresu

Any updates on the Rockchip 3588? I didn't notice any major ARM events in May 2019. Looks like they have a con in October.

Still looking for SBCs/cheap consumer devices featuring A76-based SoCs that are not phones. Thus far all I've found is a Snapdragon 855 development kit for around $1200 (or more if you want the touch input device). Bleh.

 

[soresu]

The original announcement on the RK3588 was somewhat light on the details, little more than 8nm, A76, and early 2020 as the timeframe - unless someone else has further information, that may be it until closer to its mass production, which I would peg at Q4 this year.

At this point we don't even know what GPU it has, though I'm holding out hope for Mali-G77.