Allwinner A80 is one of the few octa core processors featuring ARM’s big.LITTLE technology currently available on the market. The processor comes with four ARM Cortex A15 (big) cores, and four ARM Cortex A7 (LITTLE) core, and tasks will be scheduled to different processor depending on the load to optimize power consumption on mobile devices. However, earlier big.LITTLE processors like Samsung Exynos 5410 has some serious limitations, as they only supported “cluster migration” meaning you could only use the Cortex A7 cluster or Cortex A15 cluster at any given time, so Exynos 5410 could only make use of four cores at most due to hardware limitations. They also used to be two software implementations: In-kernel Switching (IKS) and Global Task Scheduling (GTS). The former could only handle one type of core at the same, and the latter, which I believe is now used in all new devices, can handle any combination of cores, so an octa core big.LITTLE SoC can indeed make use of all its eight cores.
To make sure it was the case with Allwinner A80 SoC, I did a little test using PVRMonitor app on Tronsmart Draco AW80 mini PC. I did this test to check all eight cores can be used, and to see which cores and how many cores are used for various loads such as multi-tab web browsing and gaming. The scheduler was set to Performance with No-frills CPU Control app.
I’ve run Antutu, the Android stock Browser with multiple tabs open, and Beach Buggy Blitz 3D racing games in the video above. The takeaway for this short test is that Allwinner A80 can run its eight cores simultaneously, but in typical use, it’s rare to see more than four cores used simultaneously. I forgot to include video playback in the video, so I tried to play 4K videos and H.265 videos with Kodi 14, and normally (hardware video decoding) only two Cortex A15 are used (around 30% per core), and when software video decoding is needed (H.265), at most four cores are used, so it looks like Kodi has not been optimized yet to make full use of octa systems, at least on Allwinner A80.
So in Android mini PCs, there’s usually very little gain from an octa core processor instead of a quad core processor, unless you run apps that can make use of all cores such as video transcoding apps, or you want it convert it into a Linux mini PC to compile software or run a server.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Hi,
How was the software playback of h265 files (1080p or 4k)? Was it smooth, and how was the cpu usage?
I’m considering buying this box, however rk3288 ones have better hardware decoding capabilities, but if A80 manages software decoding well, this should not be a big deal for me.
Thanks!
@ntux
If buying a new ARM system at this point in time, why would you not get a system with a hardware H.265 decoder?
And the only SoC that seems to have real support for both H.265 and 2160p/4k/UHD is the Amlogic S812… Every other lacks proper support for either one.
How much can do A80 when all the cores are tuned and the CPU and GPU with software optimization.
For this type of SoC,all the app they must be optimized too,I believed so,even games.
For the GPU power vr I think at this stage hasn,’t been yet optimized,still in works
For the 8 cores, same CPU or different it shows in reality that they are powerful
Lollipop has been optimized for this matters, even kit kat.
@ntux
In theory 1080p30 decode should work, but 4K won’t work. In practise non of the video I tried could play, except 360p/720p videos in MX Player. See review: http://www.cnx-software.com/2014/11/09/tronsmart-draco-aw80-meta-review/
So yes, better look into RK3288 or S812.
RK3288 will decode H.265 up to 4K60 and output up to 4K 60Hz (HDMI 2.0), but unfortunately on a 1080p framebuffer.
S812 will decode H.265 at 2160p too, but output up to 4K 30 Hz only (HDMI 1.4). However, it seems the video is properly drawn on a 3840×2160 framebuffer, but it’s not something I’ve been able to verify yet.