possible soc updates.


Another solid reason to do Linux on X86 for a Pandora successor:

http://www.zdnet.com/valve-ceo-why-linux-is-the-future-of-gaming-7000020735/

198 Steam games on X86 Linux and counting.

It sounds to me like Steam is going all in on Linux.

The big question is - can it happen?  Can the Pandora successor (insert name here) be the first solid gamer oriented X86 handheld running Steam on Linux?

ED - is there any chance of an X86 Pandora successor or should we all go find something else to research?
 
Interesting - Intel, Google, IBM and Texas Instruments all contribute more to Linux development than ARM does.

http://arstechnica.com/information-technology/2013/09/google-and-samsung-soar-into-list-of-top-10-linux-contributors/

Does anyone know if ED has given any serious consideration to this Intel option?
Using the same table, there have been 8979 commit to code support for ARMs CPUs (Samsung+arm+freescale+...) while there have only been 8928 commit to support x86 CPUs (intel+AMD)... You could also divide that with all the CPU supported by arch to show code factorisation (and present that as code quality...)
These stats mean nothing if you dont choose the right axe to look at these. ARM doesnt sell CPUs. It only license CPU design to other companies. Theirs designs might differ a bit, so ARM clients have to code their own support in the code. I'm somewhat surprised that ARM commit that much in the kernel actually. On the other hands, intel pretty much requiere linux support to sell its CPUs (think servers rooms). Beside Intel sell way much stuff than just CPUs. These too needs support for linux (that mean more commit too). arf I might have forgot to put nvidia in the ARM camp. so my comparaison isnt worth more than your's...
 
You know, I think Steam is a great system. (Probably the only form of DRM that isn't hated by the majority who have to use it) But it makes me sad to see "But this can run Steam" as a compelling reason to ditch ARM, especially when all I can see this leading to is a bunch of games that can "run" on the device, but can not be optimized for the device to make the game enjoyable.

-God Ginrai
 
One of the issues with the Pandora was a lot of people saw it as a Emulation gaming handheld with an after thought of it being a UMPC.  Problem is , as a gaming handheld, it's a hard sell for the $'s it costs, as a UMPC the price is about right.  It's always been my opinion that if the Pandora was to sell more , it needs to be pushed more as a UMPC.  A P2 with a Bay Trail SOC will allow it to run  Linux, Android and Windows 8.1.  The ability to run Windows 8.1 (As well as Linux) will give it that extra bit of boost it needs to be seen more (or at least equally) as a UMPC, which it needs to do to sell for it's asking price.  That, and it will also bring in new additional customers who are after a Windows 8..1 handheld.    

ie from a business(sales) point of view, a Bay Trail based P2 makes a lot more sense than an ARM based P2.
 
Last edited by a moderator:
The only reason that would make x86 pandora somewhat conviencing is the ability to run pc softwares, but it would always be a watered down experience. Half an hour of half life 2 with 320p resolution and slideshow framerate is not a good gaming session to me. No need to mention what would happen if I want to make a powerpoint presentation with that. Even the funniest grannie punching joke would go stale after being referenced 20 times in a row in an attampt to distract my audience from how sluggish an experience it is.

Sure X86 has decent ps2 and sega saturn emulators, that's if you are running them on a gaming pc with "dedicated" graphics cards.

I would rather have a slightly more powerful pandora than a quarter arsed linux pc that fails to do anything decently and makes me want to go back to my laptop.
 
ie from a business(sales) point of view, a Bay Trail based P2 makes a lot more sense than an ARM based P2.
[SIZE=10.5pt]I hold that standpoint a few weeks ago. To me, consumer products are about amusing the maximum amount of people while maintaining a large profit margin. [/SIZE]

[SIZE=10.5pt]So, in a way, it makes sense to push out a product that not only has lots of promises, but also can totally justify its price tag.[/SIZE]

[SIZE=10.5pt]On the other hand, doing that is somewhat ignorant of pandora's current fan base. It's like a chocolate ice cream factory that's mostly known as the best choco ice cream producer in the world suddenly decides to make vanilla ice cream to appeal to more people. It would use statements like "having this is better than having nothing", "you can always stay with the last gen ice cream" and such to fool itself. However, it has overlooked the fact that all other ice cream factories are producing vanilla ice cream. Sticking in this already saturated and well-studied market is not going to do it a lot of good. Even worse, this company has no prior experience of making vanilla ice cream, and all its machineries are smelt of chocolate. [/SIZE]
 
Last edited by a moderator:
I thought the reviews people posted said that Bay Trail would have comparable battery life to ARM equivilants
 
I thought the reviews people posted said that Bay Trail would have comparable battery life to ARM equivilants
I would like to wait a while. We have all seen what those spin doctors can do. Let big guys such as sony bite that bait first.

Oh, just something I would like to mention, I've heard the ever so closed mediatek (MTK) has disclosed its sources and documentations to sony. May be we would have a chance too?
 
Well, you won't have to wait long , there are a number of tablets coming out with Bay Trail SOCs before XMas. 
 
Hmmm... what's left on the 'reasons not to'?
- Devs around here have heavyly invested into the ARM plateform (read that new DSP thread, or all the NEON code) Switching plateform would be akin to a slap in their face- Intel have lyed on the power drain and thermal values in the past (like only telling CPU number while the north bridge become hotter and drive more power than an ARM chip or the CPU ; btw the function of the northbride is part of the chip in the ARM soc world, so intel was comparing apple with orange there). Why this case is any different ? It is yet to be seen an intel plateform that allow you 10-20h of usefulness with a 4000m-amp.

- Pricier
 
- Devs around here have heavyly invested into the ARM plateform (read that new DSP thread, or all the NEON code) Switching plateform would be akin to a slap in their face
- Intel have lyed on the power drain and thermal values in the past (like only telling CPU number while the north bridge become hotter and drive more power than an ARM chip or the CPU ; btw the function of the northbride is part of the chip in the ARM soc world, so intel was comparing apple with orange there). Why this case is any different ? It is yet to be seen an intel plateform that allow you 10-20h of usefulness with a 4000m-amp.


- Pricier
Yes i was thinking about the same.

But if no company would sell an ARM SOC for a Pandora 2 what will gonna do ?

I think (like i said before) search and insisting research again for an interesting ARM SOC and ask if the company would sell to us...and if not....go for Intel
 
Purely technically speaking, I like ARM more than x86 because it is a cleaner instruction set - less legacy clutter, nicer register space, etc.

In terms of software support, I don't care, because things can be compiled for any platform. In some cases (e.g. emulators) there is some assembler optimization going on - so it might be a good idea to use x86 or ARM and not something more exotic.

I don't really see any actual advantages to x86. Being able to run closed-source binaries is not much of an advantage, since those binaries will not be designed for low-power small-screen handhelds with a relatively weak CPU and GPU. Maybe you want to run closed-source ARM binaries instead. Or just stick to retro and open source stuff.

In deciding on a SoC, I care about perf, perf/Watt, price and availability. I don't care much about architecture, but all else being equal, I'd pick ARM because it's a nice design (technically speaking).
 
Hmmm... what's left on the 'reasons not to'?
- Devs around here have heavyly invested into the ARM plateform (read that new DSP thread, or all the NEON code) Switching plateform would be akin to a slap in their face
- Intel have lyed on the power drain and thermal values in the past (like only telling CPU number while the north bridge become hotter and drive more power than an ARM chip or the CPU ; btw the function of the northbride is part of the chip in the ARM soc world, so intel was comparing apple with orange there). Why this case is any different ? It is yet to be seen an intel plateform that allow you 10-20h of usefulness with a 4000m-amp.


- Pricier
4000mAh @3.7V or 7.4V?

clovertrail came close and baytrail will follow through.
 
Purely technically speaking, I like ARM more than x86 because it is a cleaner instruction set - less legacy clutter, nicer register space, etc.

In terms of software support, I don't care, because things can be compiled for any platform. In some cases (e.g. emulators) there is some assembler optimization going on - so it might be a good idea to use x86 or ARM and not something more exotic.

I don't really see any actual advantages to x86. Being able to run closed-source binaries is not much of an advantage, since those binaries will not be designed for low-power small-screen handhelds with a relatively weak CPU and GPU. Maybe you want to run closed-source ARM binaries instead. Or just stick to retro and open source stuff.

In deciding on a SoC, I care about perf, perf/Watt, price and availability. I don't care much about architecture, but all else being equal, I'd pick ARM because it's a nice design (technically speaking).
how can you not care about the uarch? it dictates compatibility and legacy support. Unless you are building all the applications yourself, the uarch choice will be important.

open pandora doesn't have a bright future if it gets so little support. the current OP is catered to those in the know, the ones who can debug and cross compile onto the device. a regular user shouldnt have to depend on another member to port a program.
 
Back
Top