possible soc updates.

[monstercameron]

monstercameron:

Your goals are contradictory.  Switching to x86 means all existing OS images and precompiled binary packages are completely and utterly incompatible.  New bounties would need to be issued, accepted, and awarded to begin to simply start to restore the software library.

If one wants 2008 battery life, you have to stick with close to 2008 performance.

To quote ARMH's website regarding the Cortex A7:

"A single Cortex-A7 processor can deliver 5x energy-efficiency, 50% greater performance and is one fifth the size of the ARM Cortex-A8 processor, which powers many of today's most popular smartphones."

Given most of the Pandora's workload is well within the capabilities of the existing processor and a Cortex A7, it and it's low idle states while a larger core is gated off, your statement is poorly founded.  For that matter, my understanding is most of the current testing indicates that there isn't really a processing power problem so much as a code quality problem, within the regime we're talking about at least, which brings up back to the issue of binary package compatibility and bounties you're arguing should be thrown away.

What emulated systems are you thinking would be picked up beyond the current selection that'd justify having an associated BIG core running full out?  Note: assume that the emulator only uses what it needs, rather then trying to go for hundreds of frames per second.

As for price the Shield represents something Pandora will probably never be able to do as a relatively high power point for its time, and even then people were not happy with the 350USD pricepoint, and nVidia is apparently intending to reduce it to 300USD as a result.  Related to that the vendor and support differences in cost are quite significant.

Wouldn't newer images and binaries be needed switching from [forgive me if I am butchering this] soft float to hard float(using newer socs)?

besides there are already metric tonnes of compiled apps in the wild for x86, using arch? grab packages from aur, or debian based, grab them from the ubuntu repos...

 

[WizardStan]

Wouldn't newer images and binaries be needed switching from [forgive me if I am butchering this] soft float to hard float(using newer socs)?

My understanding (and Exophase will come along and tell me I'm wrong) is that you can always use soft float. If the CPU supports hard float you can still use the soft float code, you just don't get the benefits of hard float. If you're building new then by all means use hard float, but if you already have something that uses soft float it won't need to be rebuilt for that reason.

 

[monstercameron]

Wouldn't newer images and binaries be needed switching from [forgive me if I am butchering this] soft float to hard float(using newer socs)?

My understanding (and Exophase will come along and tell me I'm wrong) is that you can always use soft float. If the CPU supports hard float you can still use the soft float code, you just don't get the benefits of hard float. If you're building new then by all means use hard float, but if you already have something that uses soft float it won't need to be rebuilt for that reason.

that might be 100% true but then some of the performance might be lost moving to a newer soc...what about optmizing  for multicore support or does the os and s/w catalog already have such support?

 

[notaz]

In context of pandora, softfp vs hardfp are just different ABIs that both use the hardware fully, and the binaries can coexist on the same system. softfp is just older abi that has (I would say) minor performance penalty when passing float args, which typical pandora programs rarely have to do (none of my released emus do it ever).

 

[Grench]

Well according to one of TI's white paper http://www.ti.com/pdfs/wtbu/ti_mid_whitepaper.pdf (Page 6, notes on the bottom) the OMAP 3 is designed to max out at 0.75W, with sleep power of around 7mW. My perspective is that so far in that regime all Intel has had to offer are single core, in order processors with around 1GHz. Them setting up a dual core out of order setup with everything else being equal at 22nm would be impressive.

Them doing that while having core to core and clock to clock performance that beats the Cortex A15 at 28nm, based on Phoronix's tests related to the D525 vs Cortex A15 being heavily in the Cortex A15's favor in those terms, and managing to have better performance per watt if paired with a Cortex A7 is a stretch. We'll see once Silvermont actually launches, but Haswell ended up over the indicated TDP budget and Intel's being even more dodgy.

There's also the issue that an Intel solution will tend to cost more, and not offer as much flexibility with selecting what suits a project like this versus the ARM sphere. Given the only upside to going with Intel would be a larger Wine compatibility library, and even Neverwinter Nights 1 is liable to be something of a stretch given where the clock rate would be liable to land, I'm not sure I see the value.

Now yes you can go active cooling like the Shield and do away with all notions of pocketability, battery life, and just about everything else that drew people to this project, but I fail to see the point particularly as that would involve making a product that's already having issues with being too expensive more so.

I expect the 22nm Atom to have a per core performance of something in the range of the Core 2 Duo machines of 6 years ago.  Complete and utter speculation though.  It should be in the sub 3W power consumption range too - again speculation.

You'd actually be a bit shocked at how well Neverwinter Nights 1 runs on a Pentium 4 under Linux at 1024x800.  A core 2 duo machine @ 2Ghz runs NWN 1 very smooth at 1920x1080.  In fact, that same machine can play pretty much anything in the Steam library too - and the Steam library for Linux has been growing steadily.

Combine that with what WINE opens up - how can you not see value in it?

However, if the solution requires active cooling - scrap it and look elsewhere.  No moving parts other than a lid hinge and SD card ejector spring things.

There are things that we could do, though, that are short of having a fan.  How about a 24ga aluminum heat spreader with dissipation fins out the -front- of the unit (moving SD slots to one or both sides)?  These type of solutions are something to consider for any SoC that generate much more heat than what we've got now in the Pandora.

IMHO - Nvidia's 'Shield' is a fail on the proportion of the N-gage.  "Is that an Nvidia shield in your pocket or are you just hideously deformed?"  They missed the mark badly on that one.  It will probably outsell the Pandora - through no fault of the Pandora.

 

[monstercameron]

Well according to one of TI's white paper http://www.ti.com/pdfs/wtbu/ti_mid_whitepaper.pdf (Page 6, notes on the bottom) the OMAP 3 is designed to max out at 0.75W, with sleep power of around 7mW. My perspective is that so far in that regime all Intel has had to offer are single core, in order processors with around 1GHz. Them setting up a dual core out of order setup with everything else being equal at 22nm would be impressive.

Them doing that while having core to core and clock to clock performance that beats the Cortex A15 at 28nm, based on Phoronix's tests related to the D525 vs Cortex A15 being heavily in the Cortex A15's favor in those terms, and managing to have better performance per watt if paired with a Cortex A7 is a stretch. We'll see once Silvermont actually launches, but Haswell ended up over the indicated TDP budget and Intel's being even more dodgy.

There's also the issue that an Intel solution will tend to cost more, and not offer as much flexibility with selecting what suits a project like this versus the ARM sphere. Given the only upside to going with Intel would be a larger Wine compatibility library, and even Neverwinter Nights 1 is liable to be something of a stretch given where the clock rate would be liable to land, I'm not sure I see the value.

Now yes you can go active cooling like the Shield and do away with all notions of pocketability, battery life, and just about everything else that drew people to this project, but I fail to see the point particularly as that would involve making a product that's already having issues with being too expensive more so.

I expect the 22nm Atom to have a per core performance of something in the range of the Core 2 Duo machines of 6 years ago.  Complete and utter speculation though.  It should be in the sub 3W power consumption range too - again speculation.

You'd actually be a bit shocked at how well Neverwinter Nights 1 runs on a Pentium 4 under Linux at 1024x800.  A core 2 duo machine @ 2Ghz runs NWN 1 very smooth at 1920x1080.  In fact, that same machine can play pretty much anything in the Steam library too - and the Steam library for Linux has been growing steadily.

Combine that with what WINE opens up - how can you not see value in it?

However, if the solution requires active cooling - scrap it and look elsewhere.  No moving parts other than a lid hinge and SD card ejector spring things.

There are things that we could do, though, that are short of having a fan.  How about a 24ga aluminum heat spreader with dissipation fins out the -front- of the unit (moving SD slots to one or both sides)?  These type of solutions are something to consider for any SoC that generate much more heat than what we've got now in the Pandora.

IMHO - Nvidia's 'Shield' is a fail on the proportion of the N-gage.  "Is that an Nvidia shield in your pocket or are you just hideously deformed?"  They missed the mark badly on that one.  It will probably outsell the Pandora - through no fault of the Pandora.

I dont want to speak for exophase but he already kinda debunked the core 2 performance metrics with the 3W power draw...

 

[vcoleiro1]

I guess we will all have to wait until later this year to get some firm understanding of what these SOCs are like including Intel's.

Don't think anything is going to happen on the P2 front until then anyway.

 

[monstercameron]

sometimes the best loses out...

 

[vcoleiro1]

Anyway we are lucky, we get to talk about, and choose 2 SOC's:

one for Dragonfly 

one for Pandora 2

 

[Franko]

sometimes the best loses out...

I'll take the Dragonfly Betamax over the Pandora 2 VHS.

 

[Batou456]

Grench:

Anandtech tends to be more on the optimistic side with Intel.  His


'>expectation

http://www.anandtech.com/show/6936/...cture-revealed-getting-serious-about-mobile/6 is that Silvermont cores will have performance of a Pentium IV operating at half the frequency. 

The Neverwinter Nights Diamond box indicates a 800 MHz Pentium III is the minimum required and a 1.3 Ghz Pentium IV is recommended.  GOG specs it out as 1GHz minimum with 1.7GHz recommended.  Following the original packaging you'd need a Silvermont core clocked at 2.6Ghz, which isn't going to happen in the envelope a Pandora or Pandora like device can handle.

My more optimistic projection that considered it barely possible took the


'>Intel Atom Z500

http://ark.intel.com/products/35472/Intel-Atom-Processor-Z500-512K-Cache-800-MHz-400-MHz-FSB due to being the only one listed as being in the proper power range.  I then did the 30% speed increase improvement for a full node shrink 3 times 45nm->32nm->22nm +1 to be favorable towards process tech X, Y, or Z.  That came out to a single in order Atom core running at 1.76Ghz. 

I then erroneously pretended that Intel would have the ability to make a Atom processor compare core to core and clock to clock to the GOG reference processor.  Ergo, just barely capable of handling the game.  As I've noted Anandtech's assessment isn't anywhere near as rosy and far more likely. 

I'm at a loss what would possess you to think a 3W processor wouldn't require active cooling in a device of this size class.  Nevermind such an active cooling solution itself is liable to thicken it enough to move it entirely out of the pocketable category even ignoring the associated battery bloat and massive price jump all of that would involve.

These are example boards with example heatsinks of the higher power Silvermont reference designs.  Take note of how big they are:

The bigger issue is this:

Die reference shot:

You'll notice that the Cortex A7 actually beats the Cortex A15 in raw performance when significantly under a Watt, despite having a lower performance potential and a almost miniscule fraction of the die area.  The A7 doesn't have much performance enhancing niceties but in that regime what it does have serves it better.  Silvermont most likely is very like the Cortex A15 in its characteristics, in this regard.

Projecting off Qemu-Wine estimates, which I understand to be currently around the equivalent of a 100MHz Pentium I, I'd tend to expect that a Cortex A15 should be able to handle the same for the full run of the Pentium I.

Realistically what you're arguing for is basically the Pentium II and possibly Pentium III era catalog that doesn't have open source ports, but is compatible with Wine.  While that era certainly isn't devoid of decent titles, I don't really see the value of that largely unavailable catalog of games outweighing the value of the existing library of Pandora native games and software.

 

[monstercameron]

Grench:

Anandtech tends to be more on the optimistic side with Intel.  His expectation is that Silvermont cores will have performance of a Pentium IV operating at half the frequency. 

The Neverwinter Nights Diamond box indicates a 800 MHz Pentium III is the minimum required and a 1.3 Ghz Pentium IV is recommended.  GOG specs it out as 1GHz minimum with 1.7GHz recommended.  Following the original packaging you'd need a Silvermont core clocked at 2.6Ghz, which isn't going to happen in the envelope a Pandora or Pandora like device can handle.

My more optimistic projection that considered it barely possible took the Intel Atom Z500 due to being the only one listed as being in the proper power range.  I then did the 30% speed increase improvement for a full node shrink 3 times 45nm->32nm->22nm +1 to be favorable towards process tech X, Y, or Z.  That came out to a single in order Atom core running at 1.76Ghz. 

I then erroneously pretended that Intel would have the ability to make a Atom processor compare core to core and clock to clock to the GOG reference processor.  Ergo, just barely capable of handling the game.  As I've noted Anandtech's assessment isn't anywhere near as rosy and far more likely. 

I'm at a loss what would possess you to think a 3W processor wouldn't require active cooling in a device of this size class.  Nevermind such an active cooling solution itself is liable to thicken it enough to move it entirely out of the pocketable category even ignoring the associated battery bloat and massive price jump all of that would involve.

These are example boards with example heatsinks of the higher power Silvermont reference designs.  Take note of how big they are:

The bigger issue is this:

Die reference shot:

You'll notice that the Cortex A7 actually beats the Cortex A15 in raw performance when significantly under a Watt, despite having a lower performance potential and a almost miniscule fraction of the die area.  The A7 doesn't have much performance enhancing niceties but in that regime what it does have serves it better.  Silvermont most likely is very like the Cortex A15 in its characteristics, in this regard.

Projecting off Qemu-Wine estimates, which I understand to be currently around the equivalent of a 100MHz Pentium I, I'd tend to expect that a Cortex A15 should be able to handle the same for the full run of the Pentium I.

Realistically what you're arguing for is basically the Pentium II and possibly Pentium III era catalog that doesn't have open source ports, but is compatible with Wine.  While that era certainly isn't devoid of decent titles, I don't really see the value of that largely unavailable catalog of games outweighing the value of the existing library of Pandora native games and software.

that is the greatest thing about freedom, every one has a choice...there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.

 

[Exophase]

there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.

That's not even true. Get your facts straight.

 

[monstercameron]

there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.

That's not even true. Get your facts straight.

give me one package that the pandora runs that cannot run on x86?

 

[Exophase]

give me one package that the pandora runs that cannot run on x86?

Just in case you're trying to catch me in a technicality here with "package" that's not the word you used, you said "software." Lots of Android stuff still doesn't support x86 natively, and while most of it can be emulated at a big performance cost some of it is entirely incompatible.

For Pandora native there's DraStic for example, which probably runs substantially better on a 1GHz Pandora than desmume does on a 1GHz Temash...

 

[monstercameron]

give me one package that the pandora runs that cannot run on x86?

Just in case you're trying to catch me in a technicality here with "package" that's not the word you used, you said "software." Lots of Android stuff still doesn't support x86 natively, and while most of it can be emulated at a big performance cost some of it is entirely incompatible.


For Pandora native there's DraStic for example, which probably runs substantially better on a 1GHz Pandora than desmume does on a 1GHz Temash...

not this time exophase

there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.

I said that the "pandora runs", which for the most part is opensource, which can be compiled to run on x86...while alot of x86 software packages are closed and only run on x86 hardware.

also my argument shifted awhile ago from cpu performance to the gpu and compatibility...

 

[_wb_]

The main reason why lots of x86 software is not available on ARM is because it's closed source, not so much because it is heavily optimized for x86 or written in x86 assembly. This is not a strength of the x86 hardware, it is a weakness of that software.

There is no reason at all why software should be restricted to only one specific type of hardware. The only exception is software that really needs to do machine-specific stuff to work or get decent performance: kernels, compilers, emulators. But even there the goal should be to make it work on as many hardware platforms as possible.

I don't like to have to adapt my hardware to my software, it should be the other way around. This is why I dislike closed source software, especially if its authors don't bother to compile their stuff for more than one platform.

 

[Exophase]

I said that the "pandora runs", which for the most part is opensource, which can be compiled to run on x86...while alot of x86 software packages are closed and only run on x86 hardware.

I guess this is where you completely stop making sense.

That Android software that's not compatible with the Intel translator is something "pandora runs" that an x86 device doesn't.

DraStic is something that "pandora runs" that an x86 device doesn't.

There's a fair amount of closed source software on Pandora. You said NO ARM software. Not little. No. Stop fucking around monstercameron.

 

[monstercameron]

The main reason why lots of x86 software is not available on ARM is because it's closed source, not so much because it is heavily optimized for x86 or written in x86 assembly. This is not a strength of the x86 hardware, it is a weakness of that software.

There is no reason at all why software should be restricted to only one specific type of hardware. The only exception is software that really needs to do machine-specific stuff to work or get decent performance: kernels, compilers, emulators. But even there the goal should be to make it work on as many hardware platforms as possible.

I don't like to have to adapt my hardware to my software, it should be the other way around. This is why I dislike closed source software, especially if its authors don't bother to compile their stuff for more than one platform.

that is not the point, I agree that foss is the way it should be but it is not, the reality is that many pieces of software are hitched to a hardware platform[sometimes for strategic reasons].

I would just like to remind us that emulators all use closed source stuff...

 

[vcoleiro1]

That's a record , it took a whole 4 pages before a thread on possible HW for the P2 devolved into a fight between Exophase and Monster.


Come on guys , just chill a little.