SoC Poll - What's most important for you?

Power or Battery - what's more important for you?

  • Power - I don't care about battery, as long as it's the FASTEST!

    Votes: 38 11.0%
  • Balanced - I don't mind a little shorter battery life if it has more power

    Votes: 199 57.5%
  • Battery - I'm pretty sure every current SoC is fast enough for my needs, but I want a long battery l

    Votes: 109 31.5%

  • Total voters
    346

Quad cores capped to a low frequency should have a better perf/W than dual or single core capped to a high frequency. Of course the application has to be multi-threaded with little parallelization overhead, e.g. parallel compilation.

Many applications (e.g. web browsers, office stuff etc) need CPU power in bursts. They will be idle most of the time, and the reactiveness of their interface (loading/rendering time etc) depends mostly on the peak cpu performance, while their overall power consumption mostly depends on the idle cpu consumption.
 
Actually they scale them up and down dynamically, my phone for example goes from 125Mhz to 1400Mhz, so not even a 40% overclock doesnt kill battery faster, same on the pandora, just because it potentially could, the governor preference for how this is done is often "ondemand" on battery and "performance" when on AC.
 
Last edited by a moderator:
A turbo mode when plugged in is a given then? ^^

I'd deactivate cores and underclock mine for battery use to a point where Dreamcast, PSP or N64 is running at 100% speed,

if even more demanding tasks are possible when plugged in, I wouldn't say no to that, as long as it runs without inserted battery at all.
 
Last edited by a moderator:
Quad cores capped to a low frequency should have a better perf/W than dual or single core capped to a high frequency. Of course the application has to be multi-threaded with little parallelization overhead, e.g. parallel compilation.


Many applications (e.g. web browsers, office stuff etc) need CPU power in bursts. They will be idle most of the time, and the reactiveness of their interface (loading/rendering time etc) depends mostly on the peak cpu performance, while their overall power consumption mostly depends on the idle cpu consumption.
Well, I know that each core needs power when enabled, even when being idle (even if it's just a tiny amount).


So four cores use more power than two cores when basically doing nothing.


Sure, under full load it might be that more cores are more power efficient (haven't tested that, but I believe you here), but when the system is idle most of the time with a few bursts (web browser), a single core should be best here.


We'd need to find out at what speed an additional core becomes more efficient and then modify the firmware to enable / disable the cores at that speed.
 
Quad cores capped to a low frequency should have a better perf/W than dual or single core capped to a high frequency. Of course the application has to be multi-threaded with little parallelization overhead, e.g. parallel compilation.


Many applications (e.g. web browsers, office stuff etc) need CPU power in bursts. They will be idle most of the time, and the reactiveness of their interface (loading/rendering time etc) depends mostly on the peak cpu performance, while their overall power consumption mostly depends on the idle cpu consumption.
Well, I know that each core needs power when enabled, even when being idle (even if it's just a tiny amount).


So four cores use more power than two cores when basically doing nothing.


Sure, under full load it might be that more cores are more power efficient (haven't tested that, but I believe you here), but when the system is idle most of the time with a few bursts (web browser), a single core should be best here.


We'd need to find out at what speed an additional core becomes more efficient and then modify the firmware to enable / disable the cores at that speed.
Even for web browsing multiple cores can be useful, e.g. loading images and movies can be done in separate processes, keeping the interface reactive while rendering a page, etc.

For our purposes, single-core performance and the single-core perf/W curve is probably the most important. More cores never hurt though (when they're really doing nothing, they will be powered down completely and use no power at all).

I think A80 may be technically the best SoC, but I don't really trust the company. Snapdragon 80x is probably the second best SoC, and I think the company can be trusted but I'm not sure if they will give a small project like this decent support. OMAP5 is a decent SoC and you know what to expect from the company.

In my (relatively uninformed) opinion, OMAP5 is the safe choice, A80 is the risky choice, x86 is the very risky choice, and Snapdragon is the best choice. They would all be acceptable choices to me, and significant upgrades compared to the Pandora.
 
I'd like to stick with ARM, because ( a ) Intel doesn't need any help from us to stay in business ( b ) I would like devs like Notaz, Exophase, bsp, DrkRaziel and Wizard/BardStan to stick around and see how far they can push the Pyra.

Snapdragon would be cool, but if it has to be OMAP, then so be it.
 
Last edited by a moderator:
Now some on-topic questions/suggestions:

Is it possible to switch cores completly off in software

Don't the companion cores (M4) ment to take over tasks "automated" when the task dosen't require the high power of the a15th?

As to the mobile/home use:

When in battery mode I'd like to have the choice to have a "low power" mode somewhat adjutable (means a slower system for longer battery is fine)

But when I but the Pyra in a dock for Desktop use, I'd like to have a high power mode.

With this in mind I just got an argument for the board design having a CPUcore board and a interface board (the disgn even gta04 prefers):

If you do this, wouldn't it be possible to have one CPU core board in the Pyra and one in the dock? (or even as much boards as you like?)

This way you would have a mobile device which last very long and a "high performance cluster" for Desktop use.

(Please forgive me if this is full blown rubbish from harware/software side, but I somhow HAD to ask this...)
 
So four cores use more power than two cores when basically doing nothing
I seem to recall reading that the AllWinner could disable individual cores, turn them off completely, but I can't remember where I read that. It may actually have been for a different CPU and I'm misremembering, but I definitely remember reading it somewhere. If whatever is chosen can also do this then there's no power efficiency downside: if you only need 2 cores and the other 2 (or 6) would just be waste while walking around, turn them completely off!
 
Well, I know that each core needs power when enabled, even when being idle (even if it's just a tiny amount). So four cores use more power than two cores when basically doing nothing.
it may or may not matter depending on exact amount compared to idle power consumption of the rest of the device.

Intel processors can completely turn off cores or put them in low power state unattainable on a running machine (it's impossible to run any code in this power state but it could retain registers and cache similar to 'suspend to ram' mode). Since intel was late in this power consumption game I assume that all ARM SoCs should have such option(s)

If you do this, wouldn't it be possible to have one CPU core board in the Pyra and one in the dock? (or even as much boards as you like?)
And how do you communicate between the boards?
easy, USB+DisplayPort would do the trick although this is a crazy idea that will bring additional complexities without a lot of additional benefit except the ability to use pyra as a gamepad and/or a monitor
 
Last edited by a moderator:
easy, USB+DisplayPort would do the trick although this is a crazy idea that will bring additional complexities without a lot of additional benefit except the ability to use pyra as a gamepad and/or a monitor
None of these ports are sufficiently fast to communicate efficiently between boards. BUt i guess it depends what kind of "collaboration" you expect between the boards.
 
Last edited by a moderator:
Now some on-topic questions/suggestions:


Is it possible to switch cores completly off in software
Yes. Well, I guess it depends on your definition of "completely off", but for all practical purposes I would say yes.

Don't the companion cores (M4) ment to take over tasks "automated" when the task dosen't require the high power of the a15th?
No, the M4 cannot just take over. You can seamlessly switch between A15 and A7 (that's the point of big.LITTLE), but not between A15 and M4. I think the M4s would probably be not used at all if we pick OMAP5.

As to the mobile/home use:


When in battery mode I'd like to have the choice to have a "low power" mode somewhat adjutable (means a slower system for longer battery is fine)


But when I but the Pyra in a dock for Desktop use, I'd like to have a high power mode.
That makes sense, but the big problem is thermal design. You don't want things too get too hot. When plugged in, it will typically be charging the battery, which already in itself causes temperatures to go up. If you add an unthrottled high-clocked quadcore A15 to that in full use, you may need active cooling or at least a relatively big heatsink. That would in turn make the device larger and heavier than what it needs to be.

Draining the battery in half an hour is not a problem of battery life. It is a problem of overheating. A bigger battery or plugging in AC power is not going to solve that.
 
But it doesn't really make much sense having even more A15 cores then, as they will give you more power but even less battery...


That's exactly what I think.

Well, except for when you're using it at home with an AC.
My thoughts about this is:


Can it hurt, if we have more performance reserves than we use when on battery? If I plug the Pandora/Pyra into my dock at home, it would be great to have even more power than when I'm on the road, in order to do real desktop PC work with it (office software, web browsing etc.)

So even if that power is only unleashed when AC is plugged in, it would be a great benefit.

Would bring the device much more into the direction I like it to be: a universal computer, not only suitable for gaming and slight working on the road, but also for working at home.

And to have the possibility to unleash that power even on the road by activating a dedicated setting (maybe labeled "overclock" to make people careful with this and to make it easier again to advertise very long battery life under standard conditions), would also be possible and - in my opinion - a good idea.
 
Is there any way a bigger battery could be optionally supported with an alternate battery cover?
+1 for this. I'd love to see the option of an extended battery for people (like me) who would value battery life above portability. From my experience of using a Nexus 5, the screen as well as the SOC will have a big impact on battery life. Guess what we really need is to test a prototype for battery life when attached to a pyra screen + running under load.
 
By the ED, as comradekingu mentioned, since the Battery is replacable, anyway there's always the option of carrying a second battery around even when doing intensive tasks. 

This brings me to another thought (that should not be discussed in detail in this thread, I only throw it in here, because I hope it need not be discussed :-D):

Spare batteries for extending battery life make only half the sense, if the computer needs to be rebooted on battery change. A buffer capacitor / battery would be important, that buffers at least a few seconds while the user changes batteries.

Me too.

That's it folks, good bye!
Could you please stop such statements?

I'm old enough to die from shock, when reading this ;-)
:-D For a second after reading it I thought exactly the same. But just for a second. However, even a second may be too long for this kind of death.
 
If you do this, wouldn't it be possible to have one CPU core board in the Pyra and one in the dock? (or even as much boards as you like?)
And how do you communicate between the boards?
I was more thinking of REAL clustering, so ethernet, I'd say (not knowing if you'll need Ghz ethernet for that and if any of the networking is available on the cpu core board. Or perhaps it's just a choice to put it there?

And yes, I have no experience or knowledge about clustering, except it exists to compine power of many computers...
 
easy, USB+DisplayPort would do the trick although this is a crazy idea that will bring additional complexities without a lot of additional benefit except the ability to use pyra as a gamepad and/or a monitor
None of these ports are sufficiently fast to communicate efficiently between boards. BUt i guess it depends what kind of "collaboration" you expect between the boards.
board as a computer and pyra as a gamepad,screen and card reader with internal nand included.

USB host, ethernet and whatever is better implemented on external board.

You don't expect RAM sharing, do you?

In my (relatively uninformed) opinion, OMAP5 is the safe choice, A80 is the risky choice, x86 is the very risky choice, and Snapdragon is the best choice. They would all be acceptable choices to me, and significant upgrades compared to the Pandora.
 
If you consider software support then atom and snapdragon will swap their places. Allwinner vs Quallcom is a very interesing story. Both have mer derived devices available (Improv and Jolla respectively), both companies don't actively prevent linux to be used on their SoCs but only support android and both have alternative free video drivers developed by a single man with various degrees of success (I didn't see a lot of progress information on mali driver recently).

Basically we're stuck with libhybris+android video drivers on both A80 and Snapdragon vs Opensource drivers on intel processors or closed source but usable on linux without any additional sorcery OMAP PowerVR drivers

On another hand big enough hacker community porting mer to these devices may provide better long term support than Imagination Tech, who knows

The more I think about software support and hardware production and development issues the more I support "OMAP now, intel sometime later if pyra is successful enough" variant as going intel may be the best idea for long term support but it may be harder and more expensive from hardware design perspective (I don't imply that end product will be more expensive but getting hardware to boot OS may be harder as there is no ready-to-use development board).

OMAP is at least well supported for now at least and it's easier to design hardware because there is a development board with permission to use its schematics for hardware development
 
Last edited by a moderator:
As additional cores can be disabled when not needed and thus only need power while you are using them, I think more cores would certainly better. Someones else before me essentially wrote that technically, A80 is better than Snapdragon 80x is better than OMAP5. But on the other hand, OMAP5 is no risk and available now, Snapdragon could be possibly available soon and A80 we don't know much about. {is this sentence correct English?}

So I guess ED (or gta04? What's his actual name again? I guess he isn't actually a gta04 which has become sentient) should look into all of them and then choose the best one which meets the requirements (chip plus dev board available really soon, good English manual, etc.).
 
Back
Top