SoC: Back and forth!


Is there a nice NEON benchmark we could run on a dev board to confirm this junk?
You could benchmark PCSX-reARMed or DraStic, but I'm a little biased about that ;p

With the latter there's a benchmark mode that'll let you isolate parts that heavily use NEON.
 
Just running stock would be interesting too.. Just run a resource heavy PSX intro on all three and monitor the power.

OMAP3 vs OMAP 5 vs SNAPDRAGON.

Repeat with DS/N64/PSP/dongs.
 
Last edited by a moderator:
Unless you throw x86 into the mix the result will for the be better with newer silicon. (with lesser exceptions against than for)  i guess the 3g is the extra burden worth mentioning.

The question becomes, is there a new usecase, beyond pandora powerscope for which 100 cpu and gpu time is needed, on the go, which warrants going to a bigger battery, considering a bigger battery size wise is a drawback for space and charge time? Lessened by the fact that batteryswap can be done online, and that powerpacks can run the system directly. (atleast if you remove internal battery)

If so, id think it would come about at a time in the future when switching battery makes a better prospect technology wise, no?
 
Last edited by a moderator:
How is the power consumption in idle average and peak usecase?

When idle or playing music is the dualcore omap or the 4 core big little snap dragon faster? How is it on web browsing, reading or typing something? How is the poweer consumption at peak usecases like REICAST?
 
Just running stock would be interesting too.. Just run a resource heavy PSX intro on all three and monitor the power.

OMAP3 vs OMAP 5 vs SNAPDRAGON.

Repeat with DS/N64/PSP/dongs.
 Sadly, that's not easily possible.

It would mean we'd have to have all devboards AND have them optimized.

Remember: Complex Power Management and optimization didn't happen on the Pandora before Kernel 3.2

It's not just booting the unit and it will work so you could compare it.

How is the power consumption in idle average and peak usecase?

When idle or playing music is the dualcore omap or the 4 core big little snap dragon faster? How is it on web browsing, reading or typing something? How is the poweer consumption at peak usecases like REICAST?
When idle, nothing will be faster, as you're only idle when the stuff you do doesn't need the CPU ;)

As soon as you do something, it's not idle anymore :)

We don't even have complex Power Management running on the OMAP5 devboard, we're not using NEON for the X-Server (which does the Pandora using an optimized libpixman), we've not even initialised the SGX 3D driver.

We cannot test any Reicast.

That's exactly what I meant is the issue for small companies:

We cannot simply buy a couple of devboards and test them. It took months to get the Pandora optimized for power saving, we can't do that with various SoCs that are available.
 
Sadly, that's not easily possible.


It would mean we'd have to have all devboards AND have them optimized.


Remember: Complex Power Management and optimization didn't happen on the Pandora before Kernel 3.2


It's not just booting the unit and it will work so you could compare it.
So does this can take also so long for the Pyra after release, until all the power management features are working, like it took pretty long for the Pandora? :ph34r:
 
You don't need complex power management to characterize power consumption, just manually set it to some clock speeds and run stuff that uses 100% CPU on a core. That tells you most of what you need to know (also interesting to run stuff that doesn't use 100% CPU and report used CPU percentage, and see how power consumption scales with that)
 
Last edited by a moderator:
I'm drooling for Pyra.  Just roll the dice and pick a SoC.  I can't wait any longer...  I'll buy the an extra external battery and duck tape it if I need to.
 
Sorry i meant power consumption idle mode vs power consumption in reading stuff mode. would be curious if it is better to use big little or dualcore ti
 
You don't need complex power management to characterize power consumption, just manually set it to some clock speeds and run stuff that uses 100% CPU on a core. That tells you most of what you need to know (also interesting to run stuff that doesn't use 100% CPU and report used CPU percentage, and see how power consumption scales with that)
Yes, run something like notaz' NEON stress test at a big range of clock speeds. Repeat with a simple non-NEON CPU stress test and with a GPU stress test. It should be possible to get some kind of bogoMIPS or bogoFPS value out of the stress tests, and thus some kind of (single-core) bogoperf per watt numbers at various clock speeds.
 
You don't need complex power management to characterize power consumption, just manually set it to some clock speeds and run stuff that uses 100% CPU on a core. That tells you most of what you need to know (also interesting to run stuff that doesn't use 100% CPU and report used CPU percentage, and see how power consumption scales with that)
Yes and no. Right now there seems to be some bug in the OMAP5 code, because power consumption right now is the same when I set it to 1GHz or 500MHz, but it changes when I set it to 1,5GHz.

powertop even tells me the CPUs are running at 1GHz when I set them to 500MHz, and disabling a core doesn't lower power consumption, so it doesn't seem to really switch off the core physically.

We're using Kernel 3.8 for testing right now, maybe 3.12 has these things properly included already.

So right now, I could check maximum power consumption but not minimum on the OMAP5.

Even these basic things are sometimes missing, and I doubt it's that much better with SnapDragon or AllWinner (which is not even available yet) when looking at Linux.

Sadly, that's not easily possible.

It would mean we'd have to have all devboards AND have them optimized.

Remember: Complex Power Management and optimization didn't happen on the Pandora before Kernel 3.2

It's not just booting the unit and it will work so you could compare it.
So does this can take also so long for the Pyra after release, until all the power management features are working, like it took pretty long for the Pandora? :ph34r:
The OMAP5 power management probably shares some stuff with the OMAP3 one, so hopefully it's not that much work.

Aditionally, I don't think the Pyra will be in stores within the next few months ;)
 
Even if the voltage doesn't change between 500MHz and 1GHz it should still use substantially less power, since dynamic power consumption is linearly proportional to switching speed. I doubt it's actually changing the frequency at all, which fits what ED said about the clock speed being reported as 1GHz.

SoCs do have minimum clock frequencies, but 1GHz sounds much too high.

It would still be informative to check if it's correctly reporting clock speeds between 1GHz and 1.5GHz, and if possible check what the core voltage is set to with different steps. And get power consumption figures at these different points.
 
With a little bit lower base clock of 1.4GHz, this is what TI is in the business of doing these days  http://www.ti.com/lsds/ti/arm/keystone/products.page Insane memory speeds, truly a computational powerhorse, which is its market i guess. http://www.ti.com/lit/ds/sprs866e/sprs866e.pdf Support for their DSP isnt going anywhere.

Wonder if its pin compatible, maybe once they keep working at it in the future it could be a viable drop in/upgrade path. Shy on details (TBD) for power, and you have to roll your own graphics over pcie 2x.
 
Last edited by a moderator:
Even if the voltage doesn't change between 500MHz and 1GHz it should still use substantially less power, since dynamic power consumption is linearly proportional to switching speed. I doubt it's actually changing the frequency at all, which fits what ED said about the clock speed being reported as 1GHz.


SoCs do have minimum clock frequencies, but 1GHz sounds much too high.


It would still be informative to check if it's correctly reporting clock speeds between 1GHz and 1.5GHz, and if possible check what the core voltage is set to with different steps. And get power consumption figures at these different points.
Actually, according to the kernel config and cpufrequtils, it should do 500MHz, 1GHz and 1,5GHz right now - but it seems like 500MHz simply doesn't work.


Probably a small bug in the OMAP5 config.
 
Yeah, probably exactly something like that ;)

If voltage for OMAP is configured wrong, setting it to 500MHz might indeed try to set the OMAP to an unsupported power setting ;)
 
With a little bit lower base clock of 1.4GHz, this is what TI is in the business of doing these days  http://www.ti.com/lsds/ti/arm/keystone/products.page Insane memory speeds, truly a computational powerhorse, which is its market i guess. http://www.ti.com/lit/ds/sprs866e/sprs866e.pdf Support for their DSP isnt going anywhere.

Wonder if its pin compatible, maybe once they keep working at it in the future it could be a viable drop in/upgrade path. Shy on details (TBD) for power, and you have to roll your own graphics over pcie 2x.
No it won't be pin compatible, the set of peripherals is totally different, the die size and likely packages are probably also totally different. This isn't a mobile SoC, it's for certain other high performance embedded markets. It doesn't even have a GPU or a display controller. http://www.ti.com/lit/ds/symlink/66ak2h14.pdf
 
Back
Top