SoC Poll - What's most important for you?

[Exophase]

There is an OMAP5 PandaBoard available as well, not just OMAP4:

Nothing about such a thing is mentioned on their website. They announced over a year ago that companies would be making OMAP5 modules, but that was just passing on TI news that had nothing to do with them.

I think based on the reply I got from Allwinner, it would throw us at least 6 months back, which is way too much.

Aditionally, it's only an announcement right now - the SoC isn't even in mass production yet, it was only shown as pre-production model on the CES.

I've seen too many SoCs delayed by months when they should've been released already...

I don't think A80 will take so long to come out because, much unlike TI, Allwinner doesn't have a reputation of taking a long time between announcing a product and releasing it. And they really can't afford to, unless they want to get out of mobile like TI has, in which case they'd may as well just close down entirely. Rockchip, MediaTek, Amlogic, etc will quickly devour anyone who falls behind in that market.

The big difference between a company like TI making OMAP and a company like Allwinner making their SoCs is that the latter is using hard macros supplied by ARM and IMG that are optimized for whatever process they're comfortable using. A lot of the hard work that TI had to do should have already been done by other parties that they're licensing from.

One thing I like about the SoC module concept is that you could make a breakout board module and make cables to connect it to an eval board, assuming that said board brings out the interfaces you need. That'd make it a lot cheaper and easier to try new boards. But I agree that you shouldn't delay Pyra by something like 6 months to go with an SoC like Allwinner A80.

 

[Klumpen]

I hope, that someone is allowed and willing to optimize Binding of Isaac for Pyra.

By now it only seems to serve as a benchmark for CPUs in Linux systems.

Multithreading for Flash would be awesome...

 

[God Ginrai]

I think based on the reply I got from Allwinner, it would throw us at least 6 months back, which is way too much.

Aditionally, it's only an announcement right now - the SoC isn't even in mass production yet, it was only shown as pre-production model on the CES.

I've seen too many SoCs delayed by months when they should've been released already...

I don't think A80 will take so long to come out because, much unlike TI, Allwinner doesn't have a reputation of taking a long time between announcing a product and releasing it. And they really can't afford to, unless they want to get out of mobile like TI has, in which case they'd may as well just close down entirely. Rockchip, MediaTek, Amlogic, etc will quickly devour anyone who falls behind in that market.

This is why I asked what it was they indicated. Because I honestly don't think that AllWinner (or any of the Chinese SoC manufacturers) would take that long to release an SoC.

EDIT:

@Klumpen: Not gonna happen. Adobe abandoned flash on ARM after android 2.3.

-God Ginrai

 

[SNESFAN]

Android 4.0, they say to remove it before upgrading to 4.1 or higher, it still works, but yea same thing

announcement

http://blogs.adobe.com/flashplayer/2012/06/flash-player-and-android-update.html

file archive

http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html

 

[Natsu]

I'm not saying you didn't. I'm simply wondering how far out they seemed to be suggesting. For this chip, depending on other factors, I would be willing to wait a little.

His the one who has to race against the clock, not you. Just saying.

I think based on the reply I got from Allwinner, it would throw us at least 6 months back, which is way too much.

Did you ask/look to see if the past chips can be used for testing in its place?

 

[Klumpen]

I think based on the reply I got from Allwinner, it would throw us at least 6 months back, which is way too much.

Yay, I consider this as a good thing - The choice is shrinking and we can move on sooner towards Pyraland.


OMAP5 and Snapdragon left.

 

[God Ginrai]

I'm not saying you didn't. I'm simply wondering how far out they seemed to be suggesting. For this chip, depending on other factors, I would be willing to wait a little.

His the one who has to racing against the clock, not you. Just saying.

Of course. The reason I am asking is because I don't actually see how AllWinner can compete with Rockchip, etc. if the A80 is far enough out that it would delay us by 6 months.

-God Ginrai

 

[Natsu]

Yay, I consider this as a good thing - The choice is shrinking and we can move on sooner towards Pyraland.

OMAP5 and Snapdragon left.

Yes, missing out on what could be the best chip hardware wise is a good thing.Besides, Idk what the email said, of course, but 6 months may not even be the case.

 

[Grench]

The Intel z3770 has 2W SDP (typical use scenario).

According to Intel, that's running at low speed (1,4GHz) with normal work being done (no games, etc.)

Based on various numbers and measurements I've seen I'd estimate around 1W for 2.4GHz, which should outperform an OMAP5 A15 core at 1.7GHz while using much less power. Of course you can't run all four cores at 2.4GHz while using <= 2W, much less with the rest of the SoC involved.

2W would mean approx. 3W with all other components needed in a mobile system, and that would mean 5 hours battery life with a Pandora battery.

So approx. 5 hours with 1,4GHz normal usage.

No, not normal usage. 2W for all four cores running at 1.4GHz while the cooling meets some requirement (this isn't just a different way of specifying max performance - higher temperature reduced power efficiency, there's a non-linear feedback effect at play). Normal usage doesn't dictate running all four cores at even 1.4GHz. It can probably run one core at over 2GHz and still stay below 2W for the whole SoC.

Whatever SoC we choose - while they certainly all are better than the current Pandora in terms of Perf/W, they are all able to drain the battery within hours when being run with high-demanding tasks.

Indeed. It's all thanks to the advent of tablets and the increasing size of smartphones and phablets bringing increased battery capacity and thermal mass.

Thank you for correcting that Exophase.

1.4Ghz isn't 'low speed' for the z3770. It's the 'normal speed' for it's thermal design. The SoC opportunistically overclocks one or more cores to up to 2.4 Ghz for brief periods to SAVE power by getting to an idle state faster.

http://www.tomshardware.com/reviews/intel-atom-moorestown-smartphone,2624-6.html (Yes it is an OLD article. Intel has been using this technology for a LONG time - and to find something to describe it means going back in history.)

 

[Exophase]

1.4Ghz isn't 'low speed' for the z3770. It's the 'normal speed' for it's thermal design. The SoC opportunistically overclocks one or more cores to up to 2.4 Ghz for brief periods to SAVE power by getting to an idle state faster.

http://www.tomshardware.com/reviews/intel-atom-moorestown-smartphone,2624-6.html (Yes it is an OLD article. Intel has been using this technology for a LONG time - and to find something to describe it means going back in history.)

But the thing is, running at a higher clock speed that requires a voltage boost uses proportionately more power, it's not a power optimization, it's a user experience one (get it done faster). Race to sleep only makes sense as a power optimization if it means you can turn off other stuff faster. Maybe if you're racing to turn the screen off, but usually if you have other things on they're on for a reason that goes beyond waiting for the CPU to finish what it's doing - they become the bottlenecks, not the other way around.

The difference between what Intel does and what every ARM SoC I know of does is that parts of the DVFS are controlled in hardware. I don't really understand exactly how it works, but I think the idea is that the hardware makes clock speeds available to the software, and then determines what to set the voltage to based both on the frequency and chip activity. It allows more fine grained and dynamic adjustment of frequency and allows dynamic clocking without relying on throttling which can often end up really coarse grained.

 

[CrazyIvan]

I don't see a huge difference between having to somehow bungle in access to Android drivers for a GPU binary blob than using a proper Linux GPU binary blob, as long as they both work the same and there aren't bugs or big performance overheads. It's not aesthetically ideal, but Android drivers are more likely to be updated anyway.

 
We will lose the ability to upgrade kernel beyond what currently android have as evidenced by pretty much all alternative android firmwares as they always use the latest kernel available from phone manufacturer and not more recent ones.

But there are opensource drivers available for every GPU except PowerVR so we might take chances... and they might turn out not that good. But pyra with such GPU will be most certainly bring additional developers into our community. Or maybe not, a lot of uncertainty there

 

[Granitehead]

^ I doubt you are right, but someone else should do the refuting.

@ED, web browsing on multiple cores: When browsing the web, there are peaks in processor activity and idling in between, lots of idling. When you have a lot of cores you can distribute those spikes on. So when using four instead of two cores, you can a) run 4 cores at 50% for 30ms versus B) 2 cores at a 100% 30ms or c) 2 cores at 50% 60ms. a) and c) use the same amount of energy but c) might be too slow. B) uses more energy.

When a core is running at 100% for only some ms you won't see any spike in top or the like, but it still takes more energy.

I made all those numbers up with no real grounds to base them on, but someone who knows more than me could probably confirm that the principle works like I described it.

 

[EvilDragon]

I know how web browsing can share the peaks, but as it's peaking single core at 70% for me right now, it would be maybe 40% on dualcore and 25% on quadcore.

More cores need more battery when they're active, and the loading speed difference would probably be a couple of ms.

So what's the deal here...?

 

[God Ginrai]

I know how web browsing can share the peaks, but as it's peaking single core at 70% for me right now, it would be maybe 40% on dualcore and 25% on quadcore.

More cores need more battery when they're active, and the loading speed difference would probably be a couple of ms.

I know how web browsing can share the peaks, but as it's peaking single core at 70% for me right now, it would be maybe 40% on dualcore and 25% on quadcore.

But if you used more cores and ran them at lower clocks, couldn't they in theory use less battery?

So what's the deal here...?

No idea. _wb_ was simply trying to point out that more cores could have advantages in a number of places, and all of us have somehow turned it into a dead end argument about whether more cores can load web pages faster or not.

-God Ginrai

 

[comradekingu]

TI support by TI over is better than chinese vendor and indie community support imo. I think if you buy a solution, as a oem, you should have to toy around with android drivers. 

However what is actually most important to me, seeing as computing power meeds my need across the board, is audio quality. TI has the best solutions to pick from there.

 

[EvilDragon]

Yes, if you had a steady to high CPU usage, multiple cores would probably be more efficient. The problem is with webbrowsing that you have high peaks for a couple of seconds at a max, then it idles again.

When idling, four CPUs need more power than two or one.

So with everything that only has short peaks, less CPUs should be better.

You'd need to actively disable to cores dynamically when they are not needed, but I don't think Linux does that.

 

[Granitehead]

I know how web browsing can share the peaks, but as it's peaking single core at 70% for me right now, it would be maybe 40% on dualcore and 25% on quadcore.

More cores need more battery when they're active, and the loading speed difference would probably be a couple of ms.

So what's the deal here...?

I assumed you checked those peaks with something like top. But top won't display brief peaks. Say you have a refresh rate of 0.5s. Screen is refreshed, 1%. Then there are two peaks to 100% which take 30ms each. When the screen is refreshed again it will display something like 13%.If you are absolutely sure you use a tool (or parameters for top other than the standard ones, I don't know) which displays true maximum peak load of a single core in the last x seconds, then I'm willing to believe more cores won't have much of an impact for that use case.

But there will always be cases where there are peaks to a 100% with two cores and where there would be no such peaks with 4 cores.

Furthermore when the additional cores aren't active, they can be turned off and certainly don't lower usage time/per charge. If one is really worried about the battery then one could (I'm pretty sure) even disable two cores completely until energy usage isn't that important anymore.

But when you only have two cores, there is no way two get 4 for a short period of time because you absolutely want to play this and this game in full speed or compile something while plugged in or edit photographs with an external battery pack or whatever.

So if it's possible to get four cores, they certainly don't hurt but could have benefits.

I think A80 would probably be best both at power saving and at high load speed. But I guess if it's really released too late... :-(

But from what you wrote I assume they didn't actually tell you a date which is too late, but that only what you assumed. Someone (Exophase? Someone who tends to be smart, I think) wrote that the company behind the A80 probably develops very fast, so maybe it will be available sooner than you think if they didn't mention a date. Just make sure the release is really too late before moving to something else, though I guess that's what you would do anyway.

You'd need to actively disable to cores dynamically when they are not needed, but I don't think Linux does that.

Are you sure it doesn't? I think it does, maybe someone can confirm/deny?

 

[God Ginrai]

Yes, if you had a steady to high CPU usage, multiple cores would probably be more efficient. The problem is with webbrowsing that you have high peaks for a couple of seconds at a max, then it idles again.

When idling, four CPUs need more power than two or one.

So with everything that only has short peaks, less CPUs should be better.

You'd need to actively disable to cores dynamically when they are not needed, but I don't think Linux does that.

Well, when idling, power usage should be pretty negligent anyway, so I wouldn't mind the hit. As for if Linux can actively disable the cores dynamically, while that would be optimal, if you know that you aren't going to be doing anything intensive, you as the user could easily turn off cores if we made a simple enough script or GUI toggle the number of cores, which would still give you longer battery life.

-God Ginrai

 

[EvilDragon]

I know you can disable the cores manually, but no powersaving tool for Linux does that automatically, AFAIK.

 

[God Ginrai]

I know you can disable the cores manually, but no powersaving tool for Linux does that automatically, AFAIK.

I can not confirm or deny that such a powersaving tool exists. I am only saying that we can always manually turn off the cores to save power if no such powersaving tool exists that does it automatically.

as T4b said: "But when you only have two cores, there is no way two get 4 for a short period of time because you absolutely want to play this and this game in full speed or compile something while plugged in or edit photographs with an external battery pack or whatever."

-God Ginrai