SoC: Back and forth!

[Grench]

You should know by now that the current decision was to go with ARM, right?

Yes, however I feel it was made for the wrong reasons.  If we're going to consider SoC alternatives, those reasons should be evaluated.

The primary reasons that were given for ARM were:

1.  Backwards compatibility with existing PNDs, which it appears is going to get semi-scrapped.

2.  Because of a supposed instability in Intel in the mobile market - which is hillarious on it's own.  Doubly so since they're also using the Bay Trail series in embedded and automotive.

Some first (very rough) benchmark using some self-compiled floating point code (n times doing a 2D coordinate transform):

9.5s    armhf OMAP3 @ 1 GHz (GTA04)

4.5s    i386 Celeron @ 900 MHz (eeePC 701)

1.2s    armhf OMAP5 @ ? (Evaluation Board)

0.6s    i386 Core2Duo @ 2.8 GHz (some desktop)

So the OMAP5 has 8 times FPU performance as the OMAP3 (using exactly the same binary code, which means no better compiler optimization). And 0.5 of a fast Core2Duo.

There are of course better (standardized) benchmarks that also separately test integer and float performance.

If someone has a recommendation for a test (ideally available in Debian Wheezy) I can run it on all machines.

But running GPU tests is very different.

Since we're using X86 as a basis of comparrison for 'speed', it should be considered that the z3770 is -as fast as- a Core2Duo 2.1 Ghz in a 2W envelope.

http://www.cpubenchmark.net/midlow_range_cpus.html

The z3770 has open source drivers.  It is supported  in the Linux kernel.  It meets 100% of the other requirements for an SoC for this system, but it is X86 not ARM. 

If we have to be ARM - fine.  But if we're truly going to claim to be architecture agnostic, then it needs to be given serious consideration.

 

[Linux-SWAT]

Ahem.

 

[TrashyMG]

Yes, however I feel it was made for the wrong reasons.  If we're going to consider SoC alternatives, those reasons should be evaluated.

 
It seems Grench needs to go through Notaz's brainwashing regiments again.. 

 

[Natsu]

Maybe Snapdragon 805 could even target Gamecube or PS2 emulation.

Gamecube is already "running" on the Snapdragon 800.

 

[SNESFAN]

Using the obscure omap in it's self will remove some comparison or at least silence those who don't really look hard into it or have intimate knowledge in the subject. If you have no intentions of running a straight android (seems to be my impression) then there won't be very many apples to apples comparisons out there because not many other devices out there run a straight linux. No consumer electronics run the omap either so that creates a veil of mystery as well. It will reduce somewhat the naysays and the haters.

Not that bleeding edge is top of the priority list, but it won't be hit right out the door with "x-y-x device is faster" because they will be very hard pressed to find any decent benchmarks to prove it other than a rough estimate (that will be more or less correct) but will be hard to support the fact. I know this, because I've tried very hard to get some decent benchmarks for the evm (or anything at all running omap 5 really) and have so far been pretty unsuccessful in finding anything of worth. Only good info was from 2012 and no longer relevant.

notaz, as always seems to speak truth. I completely agree, the omap does appear to be the all around best option, even if not perfect. It seems to be the best fit for this project, given the history, it's future goals, it's scale and the size of it's target community. After some reflection, the OpenGL ES 3 vs 2 ,and the lack of openGL standard won't mean a whole lot in the grand scheme. Even the lack of a completely open source video driver won't be *THAT* big of a deal in the short term. In the long term as long as there isn't any glaring issues, it doesn't seem to be that big of a deal either. In the long long term, it may get reverse engineered and could make the gles issue a non issue.

It sounds like the decision didn't come lightly, but I really think you guys are making the right decision here. 

.... that is, unless you were to just happen across a pile of 100k tegra k1's... lol

 

[Askarus]

Maybe Snapdragon 805 could even target Gamecube or PS2 emulation.

Gamecube is already "running" on the Snapdragon 800.

But not full speed, or at least enjoyable.

805 might provide the little extra power that's needed.

Using the obscure omap in it's self will remove some comparison or at least silence those who don't really look hard into it or have intimate knowledge in the subject. If you have no intentions of running a straight android (seems to be my impression) then there won't be very many apples to apples comparisons out there because not many other devices out there run a straight linux. No consumer electronics run the omap either so that creates a veil of mystery as well. It will reduce somewhat the naysays and the haters. Not that bleeding edge is top of the priority list, but it won't be hit right out the door with "x-y-x device is faster" because they will be very hard pressed to find any decent benchmarks to prove it other than a rough estimate (that will be more or less correct) but will be hard to support the fact. I know this, because I've tried very hard to get some decent benchmarks for the evm (or anything at all running omap 5 really) and have so far been pretty unsuccessful in finding anything of worth. Only good info was from 2012 and no longer relevant.

I also thought of that.

It's a strong point I think.

.... that is, unless you were to just happen across a pile of 100k tegra k1's... lol

Snapdragon 805 is better.

 

[Natsu]

Maybe Snapdragon 805 could even target Gamecube or PS2 emulation.

Gamecube is already "running" on the Snapdragon 800.

But not full speed, or at least enjoyable.

805 might provide the little extra power that's needed.

That's my point and this is just the beginning for the 800.

I think the power we can get from 800/805 trumps the shortcomings.

 

[Askarus]

Maybe Snapdragon 805 could even target Gamecube or PS2 emulation.

Gamecube is already "running" on the Snapdragon 800.

But not full speed, or at least enjoyable.

805 might provide the little extra power that's needed.

That's my point and this is just the beginning for the 800.

I think the power we can get from 800/805 trumps the shortcomings.

And that's why I'd like to do some serious comparison.

Snapdragon has a lot of power and we should consider it as at least as good alternative to the OMAP.

(Still I'm skeptic that we'll get the Snapdragon.)

Also I don't know if we should take the 800 if the 805 won't be an option to us.

 

[Natsu]

(Still I'm skeptic that we'll get the Snapdragon.)

Same.

Forgot to mention, it runs Dreamcast pretty well too.

 

[TrashyMG]

Forgot to mention, it runs Dreamcast pretty well, too.

Seeing the raw horsepower of the omap5 I'm thinking it can run it just as fine. 

 

[Askarus]

The quad-core CPU is based on the AMRv7 instruction set, but the architecture has been tweaked by Qualcomm, which allows each core to be at a different clock based on the usage.

So the 800 must run all cores at the same clock speed?

That would be a no-go for me as it would eat up battery for nothing.

Source: http://vr-zone.com/articles/qualcomm-snapdragon-805-vs-snapdragon-800/64753.html?utm_source=rss

Forgot to mention, it runs Dreamcast pretty well, too.

Seeing the raw horsepower of the omap5 I'm thinking it can run it just as fine. 

Seeing how it runs on Pandora there is no doubt for me that OMAP will run it

 

[Klumpen]

I think, that Dreamcast is a given for the Pyra either way.

So now it's about 6 Points?

1. Possibility to get it at all

2. Power consumption (including power efficiency via DSP-code etc...)

3. PlayStation2/GameCube

4. Prize

5. Notaz

6. The Kings EDs mood

 

[Natsu]

Ok, I get it. Dreamcast will work fine. lol

So the 800 must run all cores at the same clock speed?

That would be a no-go for me as it would eat up battery for nothing.

IDK, but I really think that's a non-issue.

 

[Hồng Thất Công]

I pick notaz over any SoCs

 

[Granitehead]

If the battery life isn't much worse on x86 I'd actually like an Intel processor. It may be a bit late, but I would like to know in more detail why this wouldn't be better than arm.

And most likely the change from omap->x86 wouldn't throw the project back any more (if at all) than the move omap->snapdragon 805.

 

[Askarus]

I pick notaz over any SoCs

Only Intel will get out Notaz I think .

If the battery life isn't much worse on x86 I'd actually like an Intel processor. It may be a bit late, but I would like to know in more detail why this wouldn't be better than arm.

And most likely the change from omap->x86 wouldn't throw the project back any more (if at all) than the move omap->snapdragon 805.

We had that long ago.

This debate is over already.

 

[FBnil]

Will the pyra run 3 or 2 hours on full power?

 

[Askarus]

Will the pyra run 3 or 2 hours on full power?

Yes.

At least I hope so.

 

[Natsu]

Will the pyra run 3 or 2 hours on full power?

Huh? It should run about the same as the certain Pandora.

 

[wej]

Will the pyra run 3 or 2 hours on full power?

Huh? It should run about the same as the certain Pandora.

Under full load the Pyra will most likely run a lot shorter than the Pandora under full load, as the Cortex-A15 cores are particularily power-hungry. Their efficiency is lower than that of the Cortex A9 cores under load. The modern Intel X86 SoC are actually more power efficient than A15 based SoC.

As we know which battery will be used for the Pyra, we know its capacity, which is about 15 Wh. Under full load the SoC will probably use about 4 W, so if you are lucky you get about 3 hours under full load. This of course depends on the power consumption of the other components as well (display brightness, wifi, etc.).