Exophase
Nothing good will ever come of Exophase.
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.
SoC: Back and forth!
- Thread starter EvilDragon
- Start date
With the latter there's a benchmark mode that'll let you isolate parts that heavily use NEON.
ShleeDragon
Pro-Catflip
- Joined
- Aug 28, 2010
- Messages
- 1,749
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.
OMAP3 vs OMAP 5 vs SNAPDRAGON.
Repeat with DS/N64/PSP/dongs.
Last edited by a moderator:
comradekingu
Glowing ember
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?
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:
rohezal
Advanced Member
- Joined
- Oct 18, 2009
- Messages
- 1,712
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 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?
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.
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.
fusion_power
Advanced Member
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?
h34r:Exophase
Nothing good will ever come of Exophase.
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:
Hồng Thất Công
Đả Cẩu Bổng Pháp
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.
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.
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.
The OMAP5 power management probably shares some stuff with the OMAP3 one, so hopefully it's not that much work.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?
Aditionally, I don't think the Pyra will be in stores within the next few months
bzar
A Commando
Maybe the used power profile changes somewhere between 1GHz and 1.5GHz, but not between 500MHz and 1GHz?
Exophase
Nothing good will ever come of Exophase.
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.
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.
comradekingu
Glowing ember
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.
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:
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.
comradekingu
Glowing ember
https://lkml.org/lkml/2013/7/30/53 kernel 3.11 or 3.12 seems like a much safer bet with power regulation
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
If voltage for OMAP is configured wrong, setting it to 500MHz might indeed try to set the OMAP to an unsupported power setting
Exophase
Nothing good will ever come of Exophase.
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
ShleeDragon
Pro-Catflip
- Joined
- Aug 28, 2010
- Messages
- 1,749
ED is likely going to choose the safe OMAP5 over anything else because it's not worth the risk... I totally agree it's not worth the risk
