Slashdot Mirror
Qualcomm Announces Next-Gen Snapdragon 808 and 810 SoCs
MojoKid (1002251) writes "Qualcomm has announced two fundamentally new chips today with updated CPU cores as well as Qualcomm's new Adreno 400-class GPU. The Snapdragon 808 and the Snapdragon 810 have been unveiled with a host of new architectural enhancements. The Snapdragon 810 will be the highest-end solution, with a quad-core ARM Cortex-A57 paired alongside four low-power Cortex-A53 cores.
The Snapdragon 808 will also use a big.Little design, but the core layouts will be asymmetric — two Cortex-A57's paired with four Cortex-A53's. The Cortex-A57 is, by all accounts, an extremely capable processor — which means a pair of them in a dual-core configuration should be more than capable of driving a high-end smartphone. Both SoC's will use a 20nm radio and a 28nm RF transceiver. That's a major step forward for Qualcomm (most RF today is built on 40nm). RF circuits typically lag behind digital logic by at least one process node. Given that RF currently accounts for some 15% of the total area and 30-40% of the PCB, the benefits of moving to a smaller manufacturing process for the RF circuit are significant." To clarify, the 810 can use a combination of the Cortex-A57 and Cortex-A53 cores so a single task that needs a lot of power won't cause as large of a power jump. All of the chips are 64-bit ARM too.
The Snapdragon 808 will also use a big.Little design, but the core layouts will be asymmetric — two Cortex-A57's paired with four Cortex-A53's. The Cortex-A57 is, by all accounts, an extremely capable processor — which means a pair of them in a dual-core configuration should be more than capable of driving a high-end smartphone. Both SoC's will use a 20nm radio and a 28nm RF transceiver. That's a major step forward for Qualcomm (most RF today is built on 40nm). RF circuits typically lag behind digital logic by at least one process node. Given that RF currently accounts for some 15% of the total area and 30-40% of the PCB, the benefits of moving to a smaller manufacturing process for the RF circuit are significant." To clarify, the 810 can use a combination of the Cortex-A57 and Cortex-A53 cores so a single task that needs a lot of power won't cause as large of a power jump. All of the chips are 64-bit ARM too.
So does this finally mean we'll get Simultaneous voice and LTE/SVDO back? Because all the current generation Qualcomm processors lack dual radio paths for some reason, this despite the fact that the previous generation had it. I have to assume it's because they used so much power/transistor budget on 'more cores!!!!' that they didn't have room for an RF design to accommodate features that are actually useful.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"I know there's a lot of noise because Apple did [64-bit] on their A7. I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that," -Anand Chandrasekher, former Qualcomm CMO
I can't see how wasting cycles on implanting an x86/x64 instruction set would be of much use commercially. I don't get the impression that many ARM manufacturers have any interest in trying to beat Intel on its own platform.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
There's a lot more reason to go 64 bit than that. The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM. Yeah, there are all sorts of workarounds you can use to access larger amounts of RAM with 32-bit pointers, but it's much nicer to have a flat address space, including plenty of address space for memory-mapped devices. Granted that we're probably a couple of years away from needing 64 bits, but it's coming, fast.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Why are you designing your drone for x86? Are you writing it in assembly code?
He's running Windows on it, duh.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
There's a lot more reason to go 64 bit than that. The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM. Yeah, there are all sorts of workarounds you can use to access larger amounts of RAM with 32-bit pointers, but it's much nicer to have a flat address space, including plenty of address space for memory-mapped devices. Granted that we're probably a couple of years away from needing 64 bits, but it's coming, fast.
32-bit ARM already addresses more than 32 bits: recent 32 bit ARM architectures have a 48 bit address space, and several chips support 36 or 40 bits. The problem of individual applications addressing at most 32 bits is minor, at this stage, but sooner or later we will have big graphics editing applications on Tablets, and larger address spaces help.
The main advantage that Aarch64 has at this very moment is that it offers a more streamlined instruction set (that makes instructions easier to reorder) and more registers. Even just compiling 32 bit code in the new model you can get impressive performance gains.
Roberto
32-bit ARM already addresses more than 32 bits: recent 32 bit ARM architectures have a 48 bit address space, and several chips support 36 or 40 bits. The problem of individual applications addressing at most 32 bits is minor, at this stage, but sooner or later we will have big graphics editing applications on Tablets, and larger address spaces help.
It can, but it's not really fun that way. Realistically, using high memory (that is not within the directly mapped part accessible to the kernel) eventually causes headaches. The default configuration on arm32 (and x86-32, for that matter) is to have only 768MB of lowmem, if you go beyond that you get into trouble because a lot of the kernel's data structures (page tables, inodes, socket buffers, ...) have to be in lowmem. You can push that limit to 2 or 3 GB at the expense of limiting user address space, but the higher you go, the sillier it gets. If you have 4GB or more on any architecture, you definitely want a 64 bit CPU.
Well, since you cannot pick the gpu and since qualcomm couples those CPU with their Adreno (scrambled letters from "Radeon") GPUs I think it is a valid question, because it is possible that a dev-boards might use those cpus/gpus or it will be helpfull for the guys at AOSP to have an oss stack.
they need to build in an x86 emulation layer to make these more attractive to gp programmers ... if they had that I may be able to make them work with the drone I'm designing for i/o and avionics control but I do not feel like rewriting the whole damn code base to run on these frankenchips.
You're programming your drone in assembler language?
The idea of the "little" part of BIG.little is that a device can be much more power efficient. While the big cores (Cortex-A57) can do the heavy processing power, for lower CPU requirements the little cores (Cortex-A53) will suffice and the big cores will be off to save power.
http://www.arm.com/products/processors/technologies/biglittleprocessing.php (It's helpful, but a bit like an advertisement)
"it's not going to be long before smartphones and tablets have > 3 GiB RAM"
You mean like the MS Surface Pro (4 GiB and 8 GiB models?), the Acer Iconias, Fujitsu Stylistic tablets etc.?
even Windows programs (ie created with visual studio) can recompile to ARM instructions. I guess he just can't install Windows itself on it.
Moral: don't lock yourself in to anything!
"I know there's a lot of noise because Apple did [64-bit] on their A7. I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that," -Anand Chandrasekher, former Qualcomm CMO
According to Anandtech ( http://www.anandtech.com/show/... )
"Integer performance: The AES and SHA1 gains are a direct result of the new cryptographic instructions that are a part of ARMv8. The AES test in particular shows nearly an order of magnitude performance improvement. This is similar to what we saw in the PC space with the introduction of Intel's AES-NI support in Westmere. The Dijkstra workload is the only real regression. That test in particular appears to be very pointer heavy, and the increase in pointer size from 32 to 64-bit increases cache pressure and causes the reduction in performance. The rest of the gains are much smaller, but still fairly significant if you take into account the fact that we're just looking at what you get from a recompile. Add these gains to the ones you're about to see over Apple's A6 SoC and A7 is looking really good from a performance standpoint.
If the integer results looked good, the FP results are even better: The DGEMM operations aren't vectorized under ARMv7, but they are under ARMv8 thanks to DP SIMD support so you get huge speedups there from the recompile. The SFFT workload benefits handsomely from the increased register space, significantly reducing the number of loads and stores (there's something like a 30% reduction in instructions for the A64 codepath compared to the A32 codepath here).
The conclusion? There are definitely reasons outside of needing more memory to go 64-bit."