An almost naked Pyra

[Exophase]

From what I remember, one core running at about 400MHz should equal a Pandora running at 1,3GHz in normal use case, but use less power than a Pandora running at 1.3GHz.

I haven't seen any difference nearly so amazing. Maybe it could with some very select benchmarks.

In my experience (with an Exynos 5250 Chromebook), A15 performs about 80% at the same clock speed, so a 400MHz A15 would perform like a 720MHz A8. This is pretty consistent with what other sources have reported on the improvements, including ARM.

 

[Swordfish II]

I haven't seen any difference nearly so amazing. Maybe it could with some very select benchmarks.

In my experience (with an Exynos 5250 Chromebook), A15 performs about 80% at the same clock speed, so a 400MHz A15 would perform like a 720MHz A8. This is pretty consistent with what other sources have reported on the improvements, including ARM.

Still an improvement, I'll take it as long as good battery life, full n64 emu (mm goldeneye), and hopefully 720/1080 h264 codec support

 

[EvilDragon]

I haven't seen any difference nearly so amazing. Maybe it could with some very select benchmarks.

In my experience (with an Exynos 5250 Chromebook), A15 performs about 80% at the same clock speed, so a 400MHz A15 would perform like a 720MHz A8. This is pretty consistent with what other sources have reported on the improvements, including ARM.

Well, I guess it always depends where you look and how they test it.
It might be that the "performance for usual tasks" also took in account the faster RAM speed, GPU speed, other CPU extensions that speed things up, etc. rather than the raw CPU power.

I don't remember exactly where I read that, but it was a while ago.

Here's another estimation: http://www.phonearena.com/news/ARM-Cortex-A15-a-deeper-look_id36225

The relative performance of an A15 is 6.13 times as fast as the the A8 (the one in the Classic and Rebirth Pandora). I don't know exactly what the relative performance is, I guess it's a mixture of the performance combined with the power usage, as the A8 with a smaller node has a higher relative performance (and we know it uses less power for the same tasks).

Does that mean that an A15 core is 6.13 times as fast as an A8 when using the same power?
I can't imagine that as well, as it would mean the Pyra would have a battery time of 60 hours when running at the same performance as the Pandora runs, and I certainly can't imagine that.

So not sure where to find proper informations here.

 

[levi]

6.13x faster sounds way faster that Moore's law even when misappplied to CPU speeds (and not just transistor counts). Even counting the A15 cluster can run at faster clock rates than the A8 core could, if the Pyra can achieve anything like that you can sign me up for a dollar, as the saying goes.

 

[Exophase]

Well, I guess it always depends where you look and how they test it.
It might be that the "performance for usual tasks" also took in account the faster RAM speed, GPU speed, other CPU extensions that speed things up, etc. rather than the raw CPU power.

I don't remember exactly where I read that, but it was a while ago.

Here's another estimation: http://www.phonearena.com/news/ARM-Cortex-A15-a-deeper-look_id36225

The relative performance of an A15 is 6.13 times as fast as the the A8 (the one in the Classic and Rebirth Pandora). I don't know exactly what the relative performance is, I guess it's a mixture of the performance combined with the power usage, as the A8 with a smaller node has a higher relative performance (and we know it uses less power for the same tasks).

Does that mean that an A15 core is 6.13 times as fast as an A8 when using the same power?
I can't imagine that as well, as it would mean the Pyra would have a battery time of 60 hours when running at the same performance as the Pandora runs, and I certainly can't imagine that.

So not sure where to find proper informations here.

The proper information is going to be from benchmarks more than anything, especially stuff like emulator benchmarks. But just going with that page, it's 6.13x faster when including clock speed differences from what they list as 65nm A8s. But they list a perf/MHz difference of 1.75x (granted, with Dhrystone, which isn't very useful, but that's probably where they get the number). So there'd be a clock difference of 3.5x there, and given a 600MHz clock on 65nm that amounts to about a 2.1GHz clock for A15 on 28nm. Kind of on the high side but not that high, there were some 28nm A15 SoCs that could clock up to around 1.9 or 2GHz.

The value you gave originally, 3.25x per perf/MHz, is much more inflated than anything I've seen. I think this would only be true in something like a memory bandwidth limited test or something that really breaks in-order execution.

 

[Bosbeetle]

Reading all this I can't wait until there are prototypes going to developers. Its very nice to hear about ideas, theories and measurements dealing with computing

 

[Luke-Jr]

The ABXY-Buttons need to be a bit higher. Right now, they don't stick out too much and when you press them, they are flat with the surrounding. This makes it hard to navigate from one button to the next one. I've checked different buttons (PlayStation and SNES controllers, Pandora, etc.), and they all stick out more than what we've got right here. This is an easy fix!

Won't they press into the touchscreen if they get much higher? (When it's closed..)

 

[EvilDragon]

Only if you make them too high. It doesn't happenn on the Pandora

 

[pmprog]

The first parts of the case arrived last week (the full basement, so the most complex part).

Are any of them coloured? or all transparent? Will you reveal/show what the colours you selected for the 10 prototypes?

 

[EvilDragon]

Are any of them coloured? or all transparent? Will you reveal/show what the colours you selected for the 10 prototypes?

As mentioned on the last newspost, I won't receive any colors before the cases are finished.
These are transparent samples in order to test any issues.

 

[fusion_power]

From what I know throttling is not implemented, only thermal shutdown was recently added. So if nobody steps up to implement it, we'll have abruptly shutting down Pyras, but I guess that's better than damaging the hardware.

Of course this is better than a melted SOC, but you can't sell a device that does such kind of auto-shutdowns regulary. A simple solution could be to lower the max clock speed or something like that. It needs testing of course. First, we need a full assembled Pyra, then ED can do real tests how far the CPU gan be driven without going down.

However, as it is with most smartphones, using them for an extended period of time with stressed CPUs will eventually lead to a lot of heat.

The Pyra has some more room inside than an average Smartpone, I'm sure this could be an advantage in case of heat spreading.

True, but some things need to be good, and the keymat needs a change anyways since I'm not content with the ABXY buttons yet.

As long as the Keyboard does not look as ugly as the Pandora one... ^^"
ABXY could get separate caps like suggested before. These should have a roudned top, at least more than the regular keys. The "sliding" over ABXY has to be as good as possible.

 

[EvilDragon]

ABXY could get separate caps like suggested before. These should have a roudned top, at least more than the regular keys. The "sliding" over ABXY has to be as good as possible.

There is no difference here. The caps are mold injected plastic parts (as all keys are), so any design can be done here. It's the same as on the Pandora, just that the button caps are glued to the keymat (and the Pandora has them inserted manually).

The type of production is exactly the same.

 

[pmprog]

As mentioned on the last newspost, I won't receive any colors before the cases are finished.
These are transparent samples in order to test any issues.

Sorry, must have missed that.

 

[Linux-SWAT]

I exchanged some mails with Tony Lindgren, the OMAP kernel branch maintainer. He's interested in having an unit, so I guess he could be helpful ^^.

 

[fusion_power]

There is no difference here. The caps are mold injected plastic parts (as all keys are), so any design can be done here. It's the same as on the Pandora, just that the button caps are glued to the keymat (and the Pandora has them inserted manually).

The type of production is exactly the same.

I just menat that the ABXY caps could have a different shape than the regular keyboard without any trouble. Keyboard caps can be a little bit rounded (please not to much) and ABXY can be made more rounded. So we basicly meant the same.

However, best solution would be to spare out ABXY from the key caps completely (just keep the rubber mat there) and use separate (transparent) plastic buttons that are already available. Easy replacement without the need to replace the entire keymat if you want other ABXY buttons.

 

[EvilDragon]

They do already. They are round and bumpy and the keys are flat.
Also, where do you plan to get already available transparent buttons...?
Something like that is always custom made.

The additional labor costs in assembly for those four buttons would cost a lot more than the design changes during development.
Besides, the case would need to be changed as well.

 

[Grench]

I just menat that the ABXY caps could have a different shape than the regular keyboard without any trouble. Keyboard caps can be a little bit rounded (please not to much) and ABXY can be made more rounded. So we basicly meant the same.

Frankly, from a functional usage standpoint, the more rounded (convex) the better. Get there by lowering the shoulders down to nearly the keyboard bezel height. The flat key top crowd is after aesthetics, but pretty is only skin deep. Pretty only means anything if the device is first usable.

However, best solution would be to spare out ABXY from the key caps completely (just keep the rubber mat there) and use separate (transparent) plastic buttons that are already available. Easy replacement without the need to replace the entire keymat if you want other ABXY buttons.

Picture assembly differences between what ED is doing and what you're proposing.

Those separate little button caps are each going to take longer to insert and position than it does to slap the entire key mat into the bezel plastic. Assembly time is money. Requiring separate key caps could easily add $5-$10 to every unit. If you absolutely must have different labels, get a ultra fine point Sharpie and write your own labels on your case next to the buttons.

 

[Wally]

@EvilDragon hurry, we don't need another keyboard discussion!

@notaz, i'm pretty sure @aTc has the speed throttling stuff in the kernel already, it'll only give you the cpu speed required for whatever application you're using and bump it up / down as it goes.

 

[rSl]

so i think i would try on my (hopefully soon in my little sweaty hands) pyra:
setting max. cpu-fequency via os to 1ghz and frequency-scale with the ondemand-governour, then maybe undervolt a little
should give an at least about 4x times faster than pandora unit without overheating when maxing out the cpu's for a while.
used together with a lower screen-bightness, it should be quite a cool longtimerunner.
theoretical, of course!

 

[Exophase]

@notaz, i'm pretty sure @aTc has the speed throttling stuff in the kernel already, it'll only give you the cpu speed required for whatever application you're using and bump it up / down as it goes.

That's the usual DVFS governor, but by throttling notaz means that the temperature is monitored and the clocks are lowered (probably aggressively lowered) when the temperature gets too high in an attempt to lower it. There's a standard Linux daemon for this too:

https://aur.archlinux.org/packages/thermald/

Ideally throttling should also be available at the hardware level, although it'll probably be a lot more coarse grained. But if the software method works well enough it's good enough to have the hardware shut down, although that puts the onus on people putting together third party OS distros to include throttling support.