Samsung Exynos 5250 - production starting in Q2 2012

[french toast]

It's clearly mentioned in the beginning that the prototype SoC has no GPU acceleration whatsoever.

That sample had 5*Cortex A7 plus 2*Cortex A15. I didn't know they could match an odd number of Cortex A7 to an even number of Cortex A15 in big.LITTLE. The thing is a lot more flexible than I thought.

Its 3 cortex a7s not 5

I agree big little is looking good...it said something about bing able to combine all 5 cores in mp mode...now that sounds awesome...if so..in theory series 5 octa could do the same? ?

 

[Jubei]

Its 3 cortex a7s not 5

I agree big little is looking good...it said something about bing able to combine all 5 cores in mp mode...now that sounds awesome...if so..in theory series 5 octa could do the same? ?

Exynos Octa can do both cluster migration and MP, just needs the right kernel for it

 

[french toast]

Exynos Octa can do both cluster migration and MP, just needs the right kernel for it

Wow! Thats amazing...run as many widget infested homescreens as possible with maximum speed! Lol
(Taking the piss of course....pretty useless feature 8 threads in a smartphone, although smartphones are not really phones at all anymore. ..how many people use their smartphones to actually make a phone call??..more like miniature computers)

 

[Nebuchadnezzar]

It's clearly mentioned in the beginning that the prototype SoC has no GPU acceleration whatsoever.

That sample had 5*Cortex A7 plus 2*Cortex A15. I didn't know they could match an odd number of Cortex A7 to an even number of Cortex A15 in big.LITTLE. The thing is a lot more flexible than I thought.

There is no limitation to the core configurations.

Page 6 describes the hardware in the video: http://www.linaro.org/documents/download/6d58a63e42baca4c49c5840788f004455098e05ba4a37

Wow! Thats amazing...run as many widget infested homescreens as possible with maximum speed! Lol
(Taking the piss of course....pretty useless feature 8 threads in a smartphone, although smartphones are not really phones at all anymore. ..how many people use their smartphones to actually make a phone call??..more like miniature computers)

You''re really starting to bring down the quality of the discussions here on this site with these ramblings, it's getting annoying.

The heterogeneous MP model is good because it has a far greater flexibility (And of course full use of the whole silicon) in towards different load types to achieve better power management. The current scheduler in the Linux kernel isn't near as advanced as it could be, currently it's being transitioned into having per-entity load-tracking so that power management logics can make use of that information for better distribution and power/frequency scaling. You can have load spikes be done on the A15 cores while not having to migrate any of the minor tasks from the A7 cores, so you don't have to scale up the A15 cores as high in frequency, or you have more dedicated resources available for the demanding task on the A15 core.

There's massive gains to be made from the software side to catch up with what the silicon is capable of. Heterogeneous MP helps in moving towards the death of classic CPU hotplugging in the kernel, it's an outdated, crappy method to achieve power management on the cores. With schedulers aware and capable to differentiate between cores like that means we can properly use power-gating on a per-core basis with the granularity that the hardware allows us to.

The video is wildly uninteresting, first of all it's still the TC2 chip which we've had public information of since last November; the Linaro working group are the consortium of companies working on the software side of things for ARM and the ones spear-heading development of big.LITTLE power management on the Linux kernel. They have public releases available for most of the common stuff they are working on and summits a few times a year where they discuss the advancements: http://www.linaro.org/connect/resources

These are probably the more interesting documents regarding TC2 and big.LITTLE:

http://www.linaro.org/documents/download/d364018e38b473315767d5479039751a50925b90d6cc6
http://www.linaro.org/documents/download/4c0f2845bd86ad5710e9a97f78aef039509276da0f31b
http://www.linaro.org/documents/download/a7e92b96e40c1662b34608953ab6e7425098f865bbdca
http://www.linaro.org/documents/download/6d58a63e42baca4c49c5840788f004455098e05ba4a37
http://www.linaro.org/documents/download/8b2310e1b792e5ff63a92c4bcde14806508f9404bf1ce

They obviously advanced have since, as those are from ~4 months ago and while the video doesn't show any proof of it, they seem to have advanced to the point to be confident show a PR video of the MP model working.

 

[french toast]

You''re really starting to bring down the quality of the discussions here on this site with these ramblings, it's getting annoying.

Ay?? Where the hell did that come from? Im sure im not everyones cup of tea but I cant be all that bad, thats getting a tad personal for my liking.

Cheers.

 

[rpg.314]

There is no limitation to the core configurations.

Page 6 describes the hardware in the video: http://www.linaro.org/documents/download/6d58a63e42baca4c49c5840788f004455098e05ba4a37
You''re really starting to bring down the quality of the discussions here on this site with these ramblings, it's getting annoying.

The heterogeneous MP model is good because it has a far greater flexibility (And of course full use of the whole silicon) in towards different load types to achieve better power management. The current scheduler in the Linux kernel isn't near as advanced as it could be, currently it's being transitioned into having per-entity load-tracking so that power management logics can make use of that information for better distribution and power/frequency scaling. You can have load spikes be done on the A15 cores while not having to migrate any of the minor tasks from the A7 cores, so you don't have to scale up the A15 cores as high in frequency, or you have more dedicated resources available for the demanding task on the A15 core.

There's massive gains to be made from the software side to catch up with what the silicon is capable of. Heterogeneous MP helps in moving towards the death of classic CPU hotplugging in the kernel, it's an outdated, crappy method to achieve power management on the cores. With schedulers aware and capable to differentiate between cores like that means we can properly use power-gating on a per-core basis with the granularity that the hardware allows us to.

The video is wildly uninteresting, first of all it's still the TC2 chip which we've had public information of since last November; the Linaro working group are the consortium of companies working on the software side of things for ARM and the ones spear-heading development of big.LITTLE power management on the Linux kernel. They have public releases available for most of the common stuff they are working on and summits a few times a year where they discuss the advancements: http://www.linaro.org/connect/resources

These are probably the more interesting documents regarding TC2 and big.LITTLE:

http://www.linaro.org/documents/download/d364018e38b473315767d5479039751a50925b90d6cc6
http://www.linaro.org/documents/download/4c0f2845bd86ad5710e9a97f78aef039509276da0f31b
http://www.linaro.org/documents/download/a7e92b96e40c1662b34608953ab6e7425098f865bbdca
http://www.linaro.org/documents/download/6d58a63e42baca4c49c5840788f004455098e05ba4a37
http://www.linaro.org/documents/download/8b2310e1b792e5ff63a92c4bcde14806508f9404bf1ce

They obviously advanced have since, as those are from ~4 months ago and while the video doesn't show any proof of it, they seem to have advanced to the point to be confident show a PR video of the MP model working.

IMHO, a far better way to deal with it would be to take the kernel out of the loop and let the hw bounce threads b/w A7 and A15 transparently to sw. Kernel can step in to tweak the parameters of switching somewhat, but it's best to let the hw manage this transition.

 

[Nebuchadnezzar]

IMHO, a far better way to deal with it would be to take the kernel out of the loop and let the hw bounce threads b/w A7 and A15 transparently to sw. Kernel can step in to tweak the parameters of switching somewhat, but it's best to let the hw manage this transition.

That... doesn't make sense. Hardware isn't aware of "load" to even begin in doing such a task. All power management, scheduling, idle state entry, basically everything is done by the kernel. Heck that goes even against preemption of an operating system.

 

[Ailuros]

Sorry to interrupt your interesting debate here guys, but it's time for a commercial:

http://www.xbitlabs.com/news/mobile...Sell_100_Million_Galaxy_S_IV_Smartphones.html

In a note to clients on Thursday, Jefferies & Company analyst Peter Misek reported that Samsung intends to build 100 million units of its upcoming flagship Google Android-based smartphone, citing usual sources among components suppliers, reports BGR web-site. The analyst believes that the tremendous volume of the handset will affect the whole market and that component manufacturers will have to reallocate their resources from their large customer, Apple.

 

[Nebuchadnezzar]

Sorry to interrupt your interesting debate here guys, but it's time for a commercial:

http://www.xbitlabs.com/news/mobile...Sell_100_Million_Galaxy_S_IV_Smartphones.html

...The analyst believes that the tremendous volume of the handset will affect the whole market and that component manufacturers will have to reallocate their resources from their large customer, Apple.

Interesting claim. Samsung already manufactures their own NAND, SoC, DRAM, and display. That leaves out the modem (Qualcomm) (TSMC), Wifi (Murata/Broadcomm) (TSMC), PMIC (?) and camera modules (Although Samsung sources those partly from themselves and partly from Sony, I don't know the situation on the new Exmor R that this is supposed to use), and then what's left are some smaller sensor IC's.

 

[ltcommander.data]

Sorry to interrupt your interesting debate here guys, but it's time for a commercial:

http://www.xbitlabs.com/news/mobile...Sell_100_Million_Galaxy_S_IV_Smartphones.html

http://crave.cnet.co.uk/mobiles/samsung-galaxy-s3-breezes-past-40-million-sales-mark-50010165/

I thought the Galaxy S3 sold about 40 million units up to January? Did they really add another 20 million in the last month? Based on 40 million, expecting a 2.5 times increase in sales for a high-end device seems fairly aggressive although doable.

 

[Ailuros]

No idea; a fellow user at 3DC just told me that Misek is not necessarily the most reliable analyst when it comes to things like that. I can't judge or comment on stuff like that and I don't care much about analysts reliability either. I always take any sort of exaggerated newsblurb with a grain of salt until further notice.

That said if Apple truly has moved at least some portion of its manufacturing to TSMC for its upcoming SoC, then Samsung should have enough capacities left open for more aggressive strategies. Other projections from analysts I had read in the past were expectations that Samsung might sell over 300Mio phones for 2013 and that if true is quite a huge increase compared to what they sold the past year. We'll see.

 

[wco81]

At that scale, they may be able to hit lower prices?

Or they may have to, in order to move that volume.

I remember seeing the S3 discounted back in August to 80 Euros upfront at some chain store in France. I don't believe that was far after it launched, probably at 200 Euros upfront for a contract?

 

[rpg.314]

That... doesn't make sense. Hardware isn't aware of "load" to even begin in doing such a task. All power management, scheduling, idle state entry, basically everything is done by the kernel. Heck that goes even against preemption of an operating system.

HW can be made aware of load. It already is to a certain extent in the turbo implementations. Haswell and friends will start lying to the OS about their operating state to switch to low power modes with low latency. When you have a PMIC on die running @100MHz, there's no way kernel is going to manage that.

AFAICS premeption should be compatible with it.

 

[Nebuchadnezzar]

HW can be made aware of load. It already is to a certain extent in the turbo implementations. Haswell and friends will start lying to the OS about their operating state to switch to low power modes with low latency. When you have a PMIC on die running @100MHz, there's no way kernel is going to manage that.

AFAICS premeption should be compatible with it.

But that's plain DVFS you're describing on Haswell, sure you can measure load through PPMU's and such methods but you cannot differentiate between loads because that's simply on a higher level the hardware cannot be aware of, and that's what would be needed in a heterogeneous architecture system. Otherwise you'd just have the IKS scheme just on a much finer granularity and back to just using either the big or the LITTLE CPU.

Can you explain what you're referring to with the 100MHz? The PWM cycle or the DVFS granularity (The former is irrelevant and I REALLY doubt the later)? PMIC's are a bunch of buck converters so I don't know what's supposed to run at that frequency and I can't find anything on Google to what you might be pointing at. For that matter I can't find much at all technical details on Haswell's on-chip regulators, only substantial thing I know of is this research paper which isn't related to Intel.

 

[rpg.314]

But that's plain DVFS you're describing on Haswell, sure you can measure load through PPMU's and such methods but you cannot differentiate between loads because that's simply on a higher level the hardware cannot be aware of, and that's what would be needed in a heterogeneous architecture system. Otherwise you'd just have the IKS scheme just on a much finer granularity and back to just using either the big or the LITTLE CPU.

I am not sure I follow. What information does kernel have that hw does not have? Why would a variant of the existing hw perf counters not be a suitable proxy for the load.

AFAICS, the transition into and out of the SOix states is hw manged, not kernel managed. Is that incorrect? If not, how exactly does it play out?

Can you explain what you're referring to with the 100MHz? The PWM cycle or the DVFS granularity (The former is irrelevant and I REALLY doubt the later)? PMIC's are a bunch of buck converters so I don't know what's supposed to run at that frequency and I can't find anything on Google to what you might be pointing at. For that matter I can't find much at all technical details on Haswell's on-chip regulators, only substantial thing I know of is this research paper which isn't related to Intel.

It's the latter. See here.

EDIT: Reading that paper shows quite clearly that DVFS on <100ns timescale is just a matter of time. The power savings as too substantial to ignore.

 

[Nebuchadnezzar]

I am not sure I follow. What information does kernel have that hw does not have? Why would a variant of the existing hw perf counters not be a suitable proxy for the load.

AFAICS, the transition into and out of the SOix states is hw manged, not kernel managed. Is that incorrect? If not, how exactly does it play out?

The kernel is the only one aware of the total entities/threads running on the system and is the one who schedules them on the different cores. Your hypothetical hardware thread bouncing between different cores on load would wreak havok on caching for one, secondly it would make the kernel scheduler obsolete, and because it obsoletes the scheduler, how complex would the hardware logic need to be? It needs to be at least RT capable and have priorities on threads, and who knows what else. That's also why I mentioned preemption because it's screwing with it. The whole thing is on several levels beyond what's currently possible not only from a hardware standpoint but also software.

Thanks for the link, it seems Intel not only caught up with ARM on DVFS (Multiple frequency voltage planes, SOix states are basically what ARM had for years) but they also plainly trumped in a single generation with Haswell.

I don't know about SOix states specifically and what exactly that PCU on Haswell controls, but in the ARM world idle states are partly controlled by the kernel. In deeper states there need to be cleanup work done like reprogramming the interrupt controller before and after entering the states on ARM.

I need to brush up on what Intel is doing in the desktop space; I found this: https://patchwork.kernel.org/patch/1934441/ That applies on the newest processors including IVB. The documentation file is informative.

Funnily enough the most informative summation I found are from the overclocking community: http://www.overclock.net/t/1058894/intel-acpi-guide-c-g-s-p-states-and-ocs Clearly the C-states at least at least are purely software controlled.

 

[Jubei]

leaked roadmap from korean analyst firm (could be false/fake so not to be taken as fact) shows Galaxy S4 having an Exynos 5440 and not Exynos Octa (i believe it has version number 5410)

http://1.androidauthority.com/wp-content/uploads/2013/02/galaxy-s4-march-launch-analyst-leak.jpg

 

[french toast]

leaked roadmap from korean analyst firm (could be false/fake so not to be taken as fact) shows Galaxy S4 having an Exynos 5440 and not Exynos Octa (i believe it has version number 5410)

http://1.androidauthority.com/wp-content/uploads/2013/02/galaxy-s4-march-launch-analyst-leak.jpg

Mmm I doubt that somehow. ..high numbers usually indicate higher performance. .I cant see something more powerfull being fitted into a smartphone.

 

[Jubei]

And now another korean media site Digital Times is claiming Snapdragon S600 will power all of the Galaxy S4s because Samsung is having problems with Exynos heat distribution

Similar to last year, the rumors are almost Apple-esque regarding Samsungs flagship

But if this is true, it might explain Tegra4i

 

[french toast]

And now another korean media site Digital Times is claiming Snapdragon S600 will power all of the Galaxy S4s because Samsung is having problems with Exynos heat distribution

Similar to last year, the rumors are almost Apple-esque regarding Samsungs flagship

But if this is true, it might explain Tegra4i

To be honest mate that may not be a bad thing..just watched a video on my tv youtube app showing htc one...with only lpddr2 and running at 1080p (obviously)..and getting a whopping 12,000+ on quadrant! !!! WTF!....

obviously there has been some kind of mistake...ill be back with some solid links.