possible soc updates.

[moxie]

Quick admin request - I noted that you censored out the inappropriate name calling and foul language from Monstercameron's posts.  Please be even handed and do the same to Exophase's last 2 pages of responses.  Thank you.

 

I won't address your attacks, and hopefully won't need to explain to the readers the difference between asking you to stop fucking around and you calling me a sack of shit, etc.

This. There is a difference between name calling and not name calling. "Foul language" is not a problem. Calling other people "a sack of shit" is.

 

[moxie]

And, furthermore: Whilst I might not have used the expression "fucking around", Exophase is completely right in pointing out that monstercameron is being extremely dishonest with his arguments. Constantly moving the goalposts, doubling up the standards, twisting other peoples words around and using made-up facts. And yes, I can point to specific examples for all these behaviours if anybody wants to challenge me on it or don't understand what I mean.

Grench, you're making reasonable argument, which one can agree with, argue with, or at least understand. Exophase does likewise. Monstercameron isn't. And whether or not it ought to be called "fucking around" or "Being intellectually dishonest" might be debatable, but it surely is skirting the limits of respectful discussion. Adding personal namecalling to the mix isn't helping. 

 

[monstercameron]

And, furthermore: Whilst I might not have used the expression "fucking around", Exophase is completely right in pointing out that monstercameron is being extremely dishonest with his arguments. Constantly moving the goalposts, doubling up the standards, twisting other peoples words around and using made-up facts. And yes, I can point to specific examples for all these behaviours if anybody wants to challenge me on it or don't understand what I mean.

Grench, you're making reasonable argument, which one can agree with, argue with, or at least understand. Exophase does likewise. Monstercameron isn't. And whether or not it ought to be called "fucking around" or "Being intellectually dishonest" might be debatable, but it surely is skirting the limits of respectful discussion. Adding personal namecalling to the mix isn't helping. 

what dishonesty? and how is my argument not "reasonable"? he always gets a pass on profanity and underhanded insults yet I am the one being dishonest?

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 is what I commented...then I get answers about pandora running android and drastic being closed source so it cant[he wont] port to x86...and other crap...

*Mod Edited*  Inappropriate 

 

[bismuthdrummer]

... how is my argument not "reasonable"? ...

I know you guys like to blow exophase but atleast pretend like it isn't happening...

Ok so, your big gripe here is that ARM can't run some x86 binaries for which we no longer have source. Or in the cases of the software you're thinking of, never ever could have had the source code. This is the big horrible for sticking to ARM.

First off, that's basically a cheap shot at us being largely open source as a philosophy. That's the rough equivalent of convincing a vegetarian that they should eat meat because they'll get protein and nutrients they could never get with just vegetables (let's assume for sake of argument that meats have certain qualities not achievable by eating vegetables or other non-meat foods). Why can't they just be a vegetarian? Is it harming their health? No. Why can't we be just ARM? Is it harming our "health" as an open source handheld? No.


 Plenty of other devices out there have ARM, they're doing fine as well.

Point to you a list of closed source software for a (largely) open source handheld? Holy crap dude, where is your head right now?

Secondly, your assumption that Exophase will open source his stuff is extremely disrespectful. The proper approach is to assume that the developer will not open source it because that shows respect for the work that they've done. But you've already shown that you hold no respect for the packages that we already have, so this comes as no surprise here. I wonder if there are any developers anywhere that draw your respect, or if you just assume that the work will just automagically be done by the next developer.

Exophase could stop working on his emulators today, and delete all of the source code. He's already stated he's going to sell DraStic on Android, so it's proprietary. You want closed source? Look no further, but apparently you really can't see through those glasses anyway.

Thirdly, you play victim after laying out personal attacks, which not only undermines whatever remaining credibility you have, but it makes you look like -- well, I won't say it, but you should have thicker skin for the nature of the content in your posts. So please grow some.

Fourth, even assuming we were x86, there'd be no guarantees on getting all those precious closed source binaries for x86 to run at the proper screen resolution, utilize the peripherals and hardware, and good luck troubleshooting system crashes. All of these are potential obstacles for those packages you push so hard for running on P2. Some new games aren't even compatible with integrated Intel graphics or known system hardware, what's to guarantee these old games and software no longer being developed will work with what we get for a processor? x86 is just one piece of it, it's not a panacea by any means.

I'll be reasonable though: yes, I'm sure you could get some and perhaps many apps to run admirably if we moved to x86.

Lastly, and I could go on but I'll end with this, you really don't know what you're talking about when it comes to software.

 

[monstercameron]

First off, that's basically a cheap shot at us being largely open source as a philosophy.

not a cheap, an intellectually honest fact.

Point to you a list of closed source software for a (largely) open source handheld? Holy crap dude, where is your head right now?

that was my point, this is an opensource handheld moving cross uarch isnt going to be impassible.

Secondly, your assumption that Exophase will open source his stuff is extremely disrespectful. The proper approach is to assume that the developer will not open source it because that shows respect for the work that they've done.

I am not sure you are serious, he is a major community member who develops closed source software on an open handheld system, yet I am the disrespectful one.

But you've already shown that you hold no respect for the packages that we already have

it is not a matter of respect...most of the software(a super majority) can be relatively easy to port to x86

I wonder if there are any developers anywhere that draw your respect, or if you just assume that the work will just automagically be done by the next developer

I have not attacked/undermined anyones software, this has been a compatibility argument, and neither have I said that it would be easy for everyone...just that it is possible.

Exophase could stop working on his emulators today, and delete all of the source code. He's already stated he's going to sell DraStic on Android, so it's proprietary. You want closed source? Look no further, but apparently you really can't see through those glasses anyway.

or he could be a good guy and release it opensource, your point? it runs on arm, it can be built to run on x86 that is my point.

Thirdly, you play victim after laying out personal attacks, which not only undermines whatever remaining credibility you have, but it makes you look like -- well, I won't say it, but you should have thicker skin for the nature of the content in your posts. So please grow some.

ok, keep blowing exo but I will try to "grow some."

Fourth, even assuming we were x86, there'd be no guarantees on getting all those precious closed source binaries for x86 to run at the proper screen resolution, utilize the peripherals and hardware, and good luck troubleshooting system crashes. All of these are potential obstacles for those packages you push so hard for running on P2. Some new games aren't even compatible with integrated Intel graphics or known system hardware, what's to guarantee these old games and software no longer being developed will work with what we get for a processor? x86 is just one piece of it, it's not a panacea by any means.

firstly, using arm their will be almost zero compatibility and the linux community is huge, so getting support would be easier than just from the op community,

I'll be reasonable though: yes, I'm sure you could get some and perhaps many apps to run admirably if we moved to x86.

that is funny, that opinion is oddly similar to my sentiment...

Lastly, and I could go on but I'll end with this, you really don't know what you're talking about when it comes to software.

I might not be much of a programmer yet but I think I can understand the concepts. x86 has been dominant is software, and to stick with arm when the only major advantage[power draw] is slowly being chipped away is just straight up bias.

 

[_wb_]

While originally, low power consumption was probably the main reason for using ARM in the Pandora, I think there are other reasons for staying with it:

- The instruction set / register model of ARM is relatively nice and clean compared to the complicated mess of legacy bloat that x86 is.

- Backwards compatibility: being able to use Pandora 1 PNDs on a Pandora successor would be nice.

- Probably more choice of SoCs.

The power consumption gap may be shrinking, but so is the software availability gap: not only does more and more stuff get released on Android and other ARM platforms, also new releases on x86 tend to be for x86-64 with specific high-end GPUs, so they won't work on mobile x86 hardware anyway.

My suggestion is to look at the hardware itself when evaluating a SoC.

 

[b_o_b]

- Backwards compatibility: being able to use Pandora 1 PNDs on a Pandora successor would be nice.

.

I agree. This should be IMO the most important feature and a priority for Pandora 2. There is quite some very nice software available for the Pandora, it would be nice to have those available from day 1. 

Pandora 1 will also benefit from Pandora 2 then and it will increase its longevity and value.  Also the creation will not split this community like we saw with the GP2X and Pandora (some very good developers like Senor Quack didn't make the switch). I can see developers wanting to optimize their software to get it working on both platforms.

 

[Asiyura]

bismuthdrummer, on 29 Jun 2013 - 05:50 AM, said: Exophase could stop working on his emulators today, and delete all of the source code. He's already stated he's going to sell DraStic on Android, so it's proprietary. You want closed source? Look no further, but apparently you really can't see through those glasses anyway. or he could be a good guy and release it opensource, your point? it runs on arm, it can be built to run on x86 that is my point.

Releasing closed or open source software don't make someone good or bad. Let me explain:

He made Drastic and want to get a bit of money back for the time he invested into it.

There have been quite a few paying emulators on android market that "shipped" without even a mention of the original author. (on XBox there is coinops, a great piece of software, but he use the work of other people without ever mentioning their names anywhere, NOT respectful at all)

So the best way to get some credit (money and respect) is to keep sources closed and release the port himself.

Nothing bad, he'll just get some money for the days he spent working on it… you know, like we all do to pay the bills…

So yes, you're disrespectful.

 

[Batou456]

The power consumption gap may be shrinking

I really don't think that's a fair characterization of the situation.  To drag in some ARM marketing materials:

Whether due to Intel's in order Atom design getting close to some Cortex A9 implementations, or otherwise it's clear that ARM's focus isn't on seeing how much power they can draw but rather maintains the traditional focus on performance/watt.  The Cortex A7 and follow up A53, as per ARMH material are intended to handle the common low to middle loads, while the Cortex 15, A12, and follow up A57 being able to switch in for the rare heavy load.

Silvermont going out of order makes it a reasonable response to AMD's Brazos and Jaguar, and the reality that the Cortex A15 appears to strongly tend to outperform the existing in order Atom hardware clock to clock and core to core.  That should help with Intel's problems related to tablets and netbook platforms, but the increased overhead of an out of order engine and whatever other performance enhancing bits they're bolting on to Silvermont that are beneficial at a couple of watts is going to hurt them below a Watt.

Simply put the gap isn't closing, it's widening in the relevant regime for a Pandora like device and will continue to do so unless Intel can develop an answer to the Cortex A7, A53, and future follow ups of ARMH's big.LITTLE design strategy.

 

[Exophase]

My suggestion is to look at the hardware itself when evaluating a SoC.

Exactly. There are a ton of criteria that are important in the evaluation.

1) Availability. Will the SoC maker even sell it to a low volume maker like this, or a distributor? These days almost none of them do. Now that TI and Freescale are out of the game Chinese SoC makers may be the most realistic option, even if they're not bleeding edge.

2) Price.

3) Peak performance in several areas, not just CPU. For example, Intel is getting mad props for their projections for Silvermont's CPU performance but their GPU projections for Bay Trail-T put it at pretty much the same level as CloverTrail+ currently is (which is far from class leading). For CPU, performance in many different threaded load scenarios, integer vs FP (I'm now hearing Silvermont has in-order FP), not just clock speed or perf/MHz but both (Jaguar has great perf/MHz but if you can only fit 2x1GHz in a reasonable power budget then it's not so great).

4) Power consumption in several areas. CPU perf/W at several points along the perf scale, not just peak or idle. Especially relevant for big.LITTLE or aSMP, currently only offered for some Cortex-A15 SoCs and Krait SoCs respectively - this makes the scale even less linear and IMO big.LITTLE is attractive for something like Pandora (a working implementation anyway). ALSO the power consumption of other SoC stuff like video decode matters.

5) System integration cost. No one even looks at this, but things like how large and expensive the PMIC and supporting circuitry needs to be, what the interfaces are like.. for example, if you take the DM3730 on today's Pandoras you need level shifters to get 3.3V I/Os and you need a pretty hefty PMIC. If you switch to an i.MX6 you'll find it can do 3.3V natively and has some of the voltage regulators integrated on SoC making for less complex support circuitry. This sort of thing can be a big deal on Pandora where board space is critical due to the keyboard and all the stuff we'd like on it (2x full SD for starters)

6) SoC peripherals, things like USB3 support and enough SD slots are important. What could also be valuable are ADCs suitable for dealing with analog nubs.

7) Easy availability of good reference designs, including recommendations for parts (or even better, package deals for parts if you get the SoC).

8) Software compatibility. Anyone who thinks there's no software advantage to x86 OR ARM is an ignorant fanboy. Real OpenGL support would also be nice - you'd get it with Jaguar SoCs and you may get it with Bay Trail-T, but you will not get it with Merrifield. Not to be ignored is OpenGL ES 3.0 support and various vendor extensions - I have no idea if the devices that support full OpenGL in Windows also have current Android support for OpenGL ES 3.0; and lastly it really should have direct OpenGL ES support in Linux. That's easy to overlook.

9) Ease of kernel development. OMAP5 would probably be the easiest migration path, since for instance we can reuse the same DSS2 setup.

Of course there's more, I can't cover everything. But whatever it is is nothing new, we've been through this a billion times, but we still get someone screaming about how we must use X.

 

[monstercameron]

ok, i'll admit I am a bit cranky, I haven't had anything solid to eat for the past 3 days [new diet], I sincerely apologize to all the developers whom I have disrespected by alleging that they can port their software to x86 and all the members whom I have insulted[i don't even know exo yet I called him a sack of shit]. Yes moxie you are right, I am intellectually dishonest and quite idiotic for suggesting that a large majority of the pandora's back catalogue can be ported and for that I sincerely apologize. Also arm is the best way forward, x86 is just a fad and anyone who uses closed source software is as amoral as RMS says he is.

 

[Franko]

^ Where's TrashyMG and his superior sarcasm dispenser?  I need him to change the voltage polarity on it slightly and see if he can detect sarcasm...  

 

[TrashyMG]

Woah..

 

[Grench]

This thread needs more cowbell.

http://www.funnyordie.com/videos/17474771de/more-cowbell-hd

 

[Franko]

Grench, I'm surprised at you - that is totally off-topic.  Now where were we?

Oh yes....AMD will rule the world and monstercameron isn't post-menopausal.  Which reminds me of hot flashes and heat distribution.  If we go with a 24 watt power draw, and a blast furnace, I think that we can build an aluminum heat-sink/grid that might be able to dissipate the heat...and make it large enough to fit in a lunchbox.

It sounds like something that I'm NOT interested in.  Let's IMPROVE upon our great device and make it better - not more cumbersome.  There IS a reason why the Pandora works for the people that use it.

Edit 1 : I have nothing against monstercameron...in fact he kind of keeps me on my toes.  His "sensationalistic" threads will probably keep coming and so will his crazy ideas, but sometimes just one of those hypothetical ideas could work.  I'd like to say to "cameron" - don't give up on learning, and don't give up on posting, but if you do have the means to do so - BUY a Pandora.  It's a treasure trove of games and good memories and entertainment all around. It does have real processing power - it is a full-fledged computer - not ever as powerful enough as you might want, but that's another subject.  If you're always going to be a "numbers guy", then when will you EVER be happy or satisfied with your purchase - if you EVER purchase?  Take it from me - purchase a Pandora and you'll enjoy it and you'll learn some stuff in the process.  Stop being a hardware guy and be a software guy...Unless you're actually on AMD's payroll, then I don't get "it".  PANDORA!

 

[_wb_]

Taking availability into account, I'm starting to think that maybe we should look at the bigger long-term picture and not worry too much about having the bleeding edge fastest processor in a successor for the Pandora. After all, in a year or two, there will always be something even better.

Instead, we should look at what is available, and what we can use in a Pandora successor. What benefit do we get, really, from extra CPU power? It seems unlikely that the extra power will be enough to be able to emulate more consoles, since single-threaded performance of even the unobtainable bleeding edge stuff is not that much better than what we already have. For more recent games that are executed natively (e.g. Android games), the GPU is probably going to be more important than the CPU. For desktop applications, having multiple cores should help to make them feel more snappy, but besides that, it's probably also not really going to be the CPU that is the main bottleneck, but rather the amount and speed of RAM and the speed of the "hard disk" (SD card).

So I'm starting to think: why don't we use something with a quad-core Cortex-A7 (so just the LITTLE part of big.LITTLE), like the recent SoCs by Allwinner and MediaTek? See also: http://arm.com/products/processors/cortex-a/cortex-a7.php

Sure, that would mean that the single-threaded performance would not increase by much compared to what we have now. But the power consumption would be incredibly low (that ARM website claims it is 5 times more energy-efficient than the Cortex-A8). And it would be relatively easy to obtain and quite cheap (under $20 per SoC). Which leaves more budget for things like fast, low-power RAM and a nice screen.

I'd rather have a Pandora successor with only a small improvement in (single-threaded) CPU performance, but with an even better battery life than what we have now, despite the extra cpu/gpu power, larger screen, faster RAM and SD. It would be totally awesome to have a device that can last like 50 hours for things like chatting on IRC, coding or remote ssh sessions (assuming a mostly black OLED screen).

Of course a full big.LITTLE SoC would be just as low-power in that scenario, but it might very well be impossible to obtain those in small quantities. So all I'm saying is the following: if we can't get something like the Exynos 5410 or Snapdragon 800, then we shouldn't go for "the next best thing" which could be something based on a quad-core Cortex-A9 (big improvement in performance, but less power-efficient), but we should go for something based on dual or quad core Cortex-A7 (small improvement in performance, big improvement in power-efficiency).

 

[Exophase]

So I'm starting to think: why don't we use something with a quad-core Cortex-A7 (so just the LITTLE part of big.LITTLE), like the recent SoCs by Allwinner and MediaTek? See also: http://arm.com/products/processors/cortex-a/cortex-a7.php

Would much rather use something like Rockchip's RK3188 which is a quad core A9.

I don't agree with you that it's worth pursuing just a minor (if even that) improvement in single threaded performance. DS and PSP emulation benefit from more, and who knows, in the future there could be heavily optimized Dreamcast and even Saturn emulators that benefit from it too. I'm sure there are some other things as well.

If you go over the top with CPU perf/W expecting to get an amazing boost in power consumption over the current Pandora you're going to be disappointed. Other components in the device will end up dominating power consumption, there's a limit to how much you can save. Cortex-A9 is really not bad, its perf/W is better than Cortex-A8 on the same process and SoCs on better processes than what Pandora's is on are available (DM3730 is TSMC 45nm, RK3188 is Global Foundries 28nm, for example).

Price-wise I doubt MediaTek stuff is that much cheaper than Rockchip.

 

[_wb_]

I agree with your point about power consumption: especially for low-load stuff (which is what I need mostly), the screen is going to be the main factor determining the battery life.

Of course better single-thread performance is always nice, I'm not against that . Just saying that for many non-emulation applications, more and faster RAM is probably more important than a faster cpu. For emulators, RAM is not that important since you always have much more RAM available than the systems you emulate, and the space overhead of emulation tends to be insignificant compared to the time overhead.

RK3188 looks fine for me

 

[Exophase]

Fair enough, just remember that a less powerful SoC may have a weaker RAM interface, and you can't go faster than the SoC.

As for capacity, I think Pandora 2 should go with 4GB regardless of the SoC choice, which is also going to be the practical limit.

 

[_wb_]

The Cortex-A7 is more recent than the Cortex-A9 though, and on the Allwinner A31 wikipedia page they claim some improvements the A7 has compared to the A9 - although of course in general, the A9 is still far superior:

In 2011, Cortex-A7 was introduced by ARM, and that is four years after Cortex-A9. When compared with Cortex-A9, Cortex-A7 design does have some improvements, as listed on ARM official website:[3]

• Lower L2 latencies (10 cycles)
• Improved OS support for L2 maintenance due to simplified software control
• Designed with a low power approach
• Improved branch prediction
• Improved memory system performance
• 64b Load Store path, improves integer and NEON performance
• 128b AMBA 4 buses improve bandwidth
• Increased TLB size (256 entry, up from 128 entry for Cortex-A9 and Cortex A5)
• Increased performance for large workloads like web browsing
• Seamlessly compatible with Cortex-A15 (big.LITTLE)

In ARM Cortex-A7, ARM transforms its design principle from improving the system performance by increasing frequency, to MPCore architecture that could bring improvements in performance, and at the same time, optimize the high power consumption and heat caused by high frequency of Cortex-A9.[citation needed]

I am not a hardware guy, I can't really tell how much of the above is marketing bullshit. More L2 cache (1MB in the Allwinner A31 and MediaTek MT6589 vs 512KB in the Rockchip RK3188) and lower latency L2 cache cannot be bad though.

As for RAM: 4GB would be nice indeed, more doesn't make much sense, 1GB is not enough of a difference compared to the 512MB we have now. The RK3188 only supports up to 2GB though, or at least that's what wikipedia says. I could live with 2GB.