Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Qualcomm Announces Next-Gen Snapdragon 808 and 810 SoCs

Unknown Lamer posted about 4 months ago | from the all-the-better-to-melt-your-pocket dept.

Power 47

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.

cancel ×

47 comments

Qualcomm steps away from their krait (0)

Anonymous Coward | about 4 months ago | (#46690981)

but the modem revelations seem good. Qualcomm seems to be the top soc manufacturer (outside maybe apples a7). 20nm/28nm analog might be what is required to push that envelope :)

Re:Needs x86 emulation. (-1)

Anonymous Coward | about 4 months ago | (#46691115)

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.

Re:Needs x86 emulation. (5, Insightful)

MightyMartian (840721) | about 4 months ago | (#46691245)

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.

Re:Needs x86 emulation. (0)

Anonymous Coward | about 4 months ago | (#46691317)

Why are you designing your drone for x86? Are you writing it in assembly code?

Re:Needs x86 emulation. (2)

swillden (191260) | about 4 months ago | (#46691401)

Why are you designing your drone for x86? Are you writing it in assembly code?

He's running Windows on it, duh.

Re:Needs x86 emulation. (2)

gbjbaanb (229885) | about 4 months ago | (#46692531)

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!

Re:Needs x86 emulation. (2)

Guy Harris (3803) | about 4 months ago | (#46691821)

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?

Gay sex (-1)

Anonymous Coward | about 4 months ago | (#46691003)

Would beta be a top or bottom? Neither as it would be the one t clean up the cum/shit stains afterwards.

SVLTE/SVDO? (4, Interesting)

afidel (530433) | about 4 months ago | (#46691007)

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.

Re:SVLTE/SVDO? (4, Informative)

rmav (1149097) | about 4 months ago | (#46691575)

So does this finally mean we'll get Simultaneous voice and LTE/SVDO back?

64-bit ARM and support for simultaneous voice and LTE/SVDO are completely different things.

The 64-bit ARM cores are application processors (AP). They do not control the modem (that can be part of the SoC together with the AP or an external component): Qualcomm modems have nifty internally developed (and publicly documented) a VLIW CPU called "Hexagon" that offers DSP-like instructions to control the modem. Some modems have two, and another Hexagon is used to process audio and cal also run user provided applications. You can find some information here http://en.wikipedia.org/wiki/Q... [wikipedia.org] and a lot more is linked.

And even this has nothing to do with dual radios. They are independent things.

Roberto

Re:SVLTE/SVDO? (1)

strstr (539330) | about 4 months ago | (#46692837)

Qualcomm's chipsets are all in one with 4G, LTE, 3G, GSM, CDMA, WiFi, and Bluetooth radios together with the CPU. So what the TC is asking if they finally decided to add SVLTE to the package on this generation of Qualcomm's chipsets.

Re:SVLTE/SVDO? (1)

rmav (1149097) | about 4 months ago | (#46693949)

Well, ok, now I see the connection, but, again, these are two independent things. SVLTE can be implemented today already. It was done already with the MSM8960 and MDM9x15 from 2012, using only one baseband (previous solutions used two) but required additional antennas (IIRC three, and two RF chips).

Re:SVLTE/SVDO? (0)

Anonymous Coward | about 4 months ago | (#46693727)

Did you miss the part of the summary that covered the radio and RF transceiver moving to smaller process sizes, which will presumably mean there is more die space with which to implement features.

Can't wait for Apple to crush these again! (0)

mozumder (178398) | about 4 months ago | (#46691121)

Actually, it seems they've already crushed them on specs, since A7 is 6-wide execution pipeline, while this is 3-wide.

We Apple fanboys will forever torment and humiliate the Android poors.

LMFAO you serious bro? (-1)

Anonymous Coward | about 4 months ago | (#46691175)

Take your head out of Steve Jobs' dead corspe's ass for a minute and listen.

Apple is a shitty ass company that makes a few shitty ass closed ass products that only work if you use them in the way Steve BlowJobs wants you to. In other words, maybe your phone is a little bit faster or has better battery life, but good luck doing anything productive with your phone if it would upset Apple's bottom line like a big shit that gives you hemmroids in the morning. You step out of line and the Apple police will come and rape your fat virgin ass like you dropped the soap.

Android, on the other hand, is OPEN SOURCE. Did you hear me? Let me say it again. ANDROID IS OPEN FUCKING SOURCE! That's right niggas, you can do anything you want on an android. Google doesn't approve? Download an alternative program, use another app store, sideload the shit, or FORK that mother fucker. You can do all of this on Android but not Crapple OS.

So basically to sum it up for all you dumbass mother fuckers, maybe Apple has higher profit margins or whatever, but that's only because people have more money than brains or they think being the hipster faggot at Starbucks is cool (word to you losers, it's not). Android is the open source CHAMPION so unless you want to sell your soul and virginity to Apple, buy an ANDROID! DROID!

Peace,
An Enlightened Folk

Re:Can't wait for Apple to crush these again! (1, Flamebait)

RightSaidFred99 (874576) | about 4 months ago | (#46691419)

Aww, you little ARM guys are so cute arguing over which toy-architecture CPU is the latest greatest! Watch what happens over the next 2 years...

Re:Can't wait for Apple to crush these again! (0)

Anonymous Coward | about 4 months ago | (#46691955)

Watch what happens over the next 2 years...

Do you have a prediction that you wish to share with us?

Re:Can't wait for Apple to crush these again! (0)

Anonymous Coward | about 4 months ago | (#46692573)

Dat abacus

"There's zero benefit a consumer gets from that" (4, Informative)

radarskiy (2874255) | about 4 months ago | (#46691173)

"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

Re:"There's zero benefit a consumer gets from that (0)

Anonymous Coward | about 4 months ago | (#46691305)

It's true. I'm a developer, and I was just thinking that to myself. I don't plan on supporting this architecture anytime soon (thankfully it's backward compatible). Hell, I'm still compiling my code as 16-bit thumb code. At some point, I'm going to want 64-bit, sure. But I really doubt that I'm going to need a 64-bit CPU at any point in the near future on a mobile device.

Qualcomm is somewhat forced to go with 64-bit though, because Apple has taken the genie out of the bottle. 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.

Re:"There's zero benefit a consumer gets from that (3, Insightful)

swillden (191260) | about 4 months ago | (#46691395)

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.

Re:"There's zero benefit a consumer gets from that (1)

Zuriel (1760072) | about 4 months ago | (#46691525)

The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM.

That was my thought. Chips that are being announced now are still going to be on the market when 3 or 4 gigs of RAM is normal, so not having 64-bit support is starting to be a problem.

Re:"There's zero benefit a consumer gets from that (4, Informative)

rmav (1149097) | about 4 months ago | (#46691601)

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

Re:"There's zero benefit a consumer gets from that (3, Informative)

Anonymous Coward | about 4 months ago | (#46691705)

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.

Re:"There's zero benefit a consumer gets from that (0)

Anonymous Coward | about 4 months ago | (#46694593)

32-bit ARM already addresses more than 32 bits:[...]

It can, but it's not really fun that way. /p>

It can be outright painful, I agree. A 64-bit address space is better. I think that the point of the poster you are replying to is there are other advantages of Aarch64, and everybody seems to focus on the 64-bit address space, either to praise it or to label is at irrelevant. The situation, as it happens, is a bit more complex than that.

Re:"There's zero benefit a consumer gets from that (0)

Anonymous Coward | about 4 months ago | (#46692139)

Also, just compiling 32 bit code can make it slower due to not fitting in whatever cache, requiring more memory and bandwidth. There are two sides to the coin.

Re:"There's zero benefit a consumer gets from that (1)

Anonymous Coward | about 4 months ago | (#46692587)

I think you meant "compiling 64-bit code." 32-bit code is usually smaller due to smaller pointers.

Re:"There's zero benefit a consumer gets from that (1)

rb12345 (1170423) | about 4 months ago | (#46692639)

There's a reasonable argument for moving to 64-bit on security grounds too. The increase in virtual address space makes ASLR far more effective since there are many more options for positioning compared to 32-bit code. On top of that, any attacks are more likely to hit a unallocated page as opposed to anything useful (with some limitations of course).

Re:"There's zero benefit a consumer gets from that (0)

Anonymous Coward | about 4 months ago | (#46693279)

The increase in virtual address space makes ASLR far more effective since there are many more options for positioning compared to 32-bit code.

Which is a pretty poor argument, IMHO. Beyond other things, (1) ASLR has been repeatedly defeated on 64-bit Windows systems (and presumably could be on Linux systems) because rarely is 100% of the address space random and attacks often can manage to scrape out enough details for relative addressing to make ASLR moot and (2) ASLR is meant to be at best a stopgap for not all (server) applications to be immediately attacked when a vulnerability is discovered by making more attack attempts a DoS rather than a full compromise, except that depending on the circumstance a DoS is more than bad enough to make the difference mostly a moot point (especially if other security practices are in place and said (server) application has no private information to compromise).

I mean, yes, it might be the icing on the cake to have a greater address space for such things. But, it's hard to call it any sort of a driving force.

Re:"There's zero benefit a consumer gets from that (2)

nojayuk (567177) | about 4 months ago | (#46692467)

"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.?

Re:"There's zero benefit a consumer gets from that (0)

Anonymous Coward | about 4 months ago | (#46692557)

which of course have 64-bit x86 CPUs and run a 64-bit Windows.

Re:"There's zero benefit a consumer gets from that (1)

nojayuk (567177) | about 4 months ago | (#46692675)

"which of course have 64-bit x86 CPUs and run a 64-bit Windows."

So, problem solved. Excellent.

Re:"There's zero benefit a consumer gets from that (1)

radarskiy (2874255) | about 4 months ago | (#46706759)

"Qualcomm is somewhat forced to go with 64-bit though, because Apple has taken the genie out of the bottle."

The Qualcomm part was already near completion by the time anyone knew anything about the A7.Going 64-bit as a "response" in ~6 months is not plausible.

My point was to poke fun at Qualcomm naysaying 64-bit at the same time they were developing 64-bit.

Re:"There's zero benefit a consumer gets from that (0)

Anonymous Coward | about 4 months ago | (#46691307)

The A57 has a first generation branch predictor and extremely low IPC. Fully custom is really the only game in town unless you are content to relive the Intel Netburst fiasco yet again with A57.

Re:"There's zero benefit a consumer gets from that (2)

IYagami (136831) | about 4 months ago | (#46693419)

"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/... [anandtech.com] )

"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."

Re:"There's zero benefit a consumer gets from that (1)

Erich (151) | about 4 months ago | (#46693911)

So these cores with the arm V8 architecture add:
  • More registers (16->32)
  • DP SIMD
  • New instructions for crypto

and a handfull of other things. But all of the above aren't really benefits of 64 bitness, just the improvements to the architecture. The real benefit of a 64 bit architecture is the larger virtual address space... processes with >2-3 GB of memory. Every other improvement is usually just improvements that could have been added in 32-bit mode but they threw into 64 bit arch. Similar with x86-64.

Re:"There's zero benefit a consumer gets from that (1)

radarskiy (2874255) | about 4 months ago | (#46706795)

Don't tell it to me, tell it to Anand Chandrasekher.

Binary drivers (1, Flamebait)

bug1 (96678) | about 4 months ago | (#46691443)

Did Qualcom also announce their commitment to binary only drivers and refusal to work with the free and open source software communtiy ?

Qualcom are just another greedy corp trying to take everyones stuff.

Re:Binary drivers (1)

Anonymous Coward | about 4 months ago | (#46691481)

Exactly, these might be intresting processors, but not as long as there's no open specs. Fuck qualcomm

Re:Binary drivers (1)

mwvdlee (775178) | about 4 months ago | (#46691669)

Do you need drivers for a CPU?

Re:Binary drivers (2)

Tsolias (2813011) | about 4 months ago | (#46691719)

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.

Re:Binary drivers (1)

mwvdlee (775178) | about 4 months ago | (#46691781)

Oops. Forgot about the GPU.

Re:Binary drivers (1)

FithisUX (855293) | about 4 months ago | (#46692175)

They could pair the cores with 8-core TI DSP in order to mimize blobs (the a simple framebuffer and an A/D would be enough to have video/audio).

I dont know (1)

Anonymous Coward | about 4 months ago | (#46691743)

I think this may not be enough for a smartphone. After all, it's not for making phone calls. Right? It's for viewing ads. The more the better for all of us.

I don't get it. (1)

serviscope_minor (664417) | about 4 months ago | (#46691873)

I really don't 100% get this big.little architecture.

The idea of having a weak but low power core capable of running all the basic functions and driving the GPU is reasonably obvious. I get that. I get the idea of having it backed by 4 big fast cores which can be switched on when a task overloads the little CPU.

But why have 4 little CPUs?

Re:I don't get it. (2, Informative)

Anonymous Coward | about 4 months ago | (#46692275)

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)

Re:I don't get it. (1)

serviscope_minor (664417) | about 4 months ago | (#46695323)

Sorry, I wasn't clear.

Why have more than 1 little CPU. If you have something intense enough to use 4, why not just fire up one big CPU?

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...