Question Anyone using ARM CPUs/SOCs?

Page 5 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Dec 19, 2014
58
5
71
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

Senior member
Nov 12, 2014
660
22
116
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....
 
Dec 19, 2014
58
5
71
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...
panfrost_01.jpg
 

whm1974

Diamond Member
Jul 24, 2016
7,449
483
96
Cool, any info on how much memory it can handle and number of PCIe lanes?
 
Dec 19, 2014
58
5
71
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:
rk3588.jpg
 
Last edited:
Dec 19, 2014
58
5
71
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

Senior member
Nov 12, 2014
660
22
116
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.
 
Dec 19, 2014
58
5
71
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

Senior member
Nov 12, 2014
660
22
116
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.
 
Dec 19, 2014
58
5
71
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.
 
Dec 19, 2014
58
5
71
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:

SVE2_01.jpg
 

Thala

Senior member
Nov 12, 2014
660
22
116
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.
 
Apr 27, 2000
11,512
843
126
SVE2 has 512-bit SIMD? Wow. I'm curious if they'll need clockspeed regressions for VL512b workloads.
 

Nothingness

Golden Member
Jul 3, 2013
1,884
32
106
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

Senior member
Nov 12, 2014
660
22
116
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.
 
Apr 27, 2000
11,512
843
126
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

Senior member
Nov 12, 2014
660
22
116
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.
 
Dec 19, 2014
58
5
71
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

Senior member
Nov 12, 2014
660
22
116
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.
 
Dec 19, 2014
58
5
71
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?
 


ASK THE COMMUNITY