.An x86 one could be possible if Pyra sells well and brings cash back into the account.
SoC Poll - What's most important for you?
- Thread starter EvilDragon
- Start date
hmc
Active Member
If both versions are available some day, I agree with commander-beef that developers will concentrate on one of them, so software-wise they will probably be quite different products.
commander-beef
Very Active Member
Going into x86 we have all soft on hands from beginning, so devs could focus on develop something new than porting [which with ARM is a time-consuming thing especially with GL stuff]. Imho, fresh stuff is more important than ports, anyway.
There are 2 reasons for different software to exist on different versions (that are the same except SoC), the first being highly optimized software (a rare kind of software actually even on pandora) and the second being badly written software with architectural dependencies for no reason.
If you're thinking opengles vs opengl then atom can run opengles programs so there's no problem.
Maybe you're thinking about binary only programs? I really hope there won't be many of them in pyra as this approach is basically defective by design because it depends on a specific architecture for no apparent reason
Last edited by a moderator:
commander-beef
Very Active Member
and another though,
x86 could be beneficial for any dev doing something for Pyra. Its saving-time. No cross-compile stuff, no coding on OP [overkill
] no SSH'ing. Just dev'ing on x86 laptop and deploy to pyra easily, and this will be beneficial for new pyra coding newbies [so there will be new apps, not only ports]
EDIT:
This will be huge help for any developer that will do something for Pyra.
x86 could be beneficial for any dev doing something for Pyra. Its saving-time. No cross-compile stuff, no coding on OP [overkill
] no SSH'ing. Just dev'ing on x86 laptop and deploy to pyra easily, and this will be beneficial for new pyra coding newbies [so there will be new apps, not only ports]EDIT:
This will be huge help for any developer that will do something for Pyra.
Last edited by a moderator:
commander-beef
Very Active Member
And final one:
Im sure x86 will help bring INDIE DEVELOPERS to PYRA easily [effordless]. Basically indie devs will need add to every app/game proper scalling (small code) for Pyra and port's done . It couldnt be more easy.. If making a port for pyra from linux x86 will be effordless, why NOT RELEASE it for pyra?
ED, go.. go.. x86
Im sure x86 will help bring INDIE DEVELOPERS to PYRA easily [effordless]. Basically indie devs will need add to every app/game proper scalling (small code) for Pyra and port's done
. It couldnt be more easy.. If making a port for pyra from linux x86 will be effordless, why NOT RELEASE it for pyra?ED, go.. go.. x86
Last edited by a moderator:
Thank you ED, for this clear list of pros and cons. In the first place, I was attracted to x86, but I realized that losing our beloved star developers would be a great loss to me. They are wonderful allies, and I'd like to enjoy their company a bit longer
Moreover, I also realized that I really didn't play games like Baldur's Gates on the Pandora because of the tiny texts and interface. So the argument in favor of games optimized for small screens rang a bell.
So it seems that I finally voted like most people here.
Moreover, I also realized that I really didn't play games like Baldur's Gates on the Pandora because of the tiny texts and interface. So the argument in favor of games optimized for small screens rang a bell.
So it seems that I finally voted like most people here.
commander-beef
Very Active Member
Devs jump to Pyra x86 ship if there will be no choice to choose from. I would like to hear the opinion of Notaz+Exo+PtitSeb+M-HT about that.
Architecture doesnt count for dev as much as a unique design and usability of pyra. So in comparision x86 is way more attractive than ARM anyway.
Just ask yourself firstly why did you choose OpenPandora in first place. Because of ARM? Nah..
To be honest simple unoptimized compiled stuff will be working on Pyra as good as on optmized Pandora. [DosBox, Mupen, PCSX] because of CPU speed of pyra.
Keep that in mind.
and optimizing x86 stuff on desktop x86 linux [optimize+compile+check+debug on x86 desktop pc and finally deploy to pyra..] is way easier than on ARM [ optimize on PC / cross-compile on PC or on OP/ check on pandora / debug on pandora]
Last edited by a moderator:
What about the fear of fragmentation and favoritism by the devs?
commander-beef
Very Active Member
Its interesting statement of Notaz.. (hmm, interesting thing what lies behind that statement.. and why)
Last edited by a moderator:
I might have to mention the factor "heat", because the coolest SoC would quite likely be my favourite, if the battery life is good as well and the perfomance at least decent.
Large heatsinks or fans should not be needed and would make the design too bulky anyway and if you have to lower the highend-CPUs performance all the time nothing is gained by choosing it but a higher price.
I'd stick to ARM mostly because of them and the good experience I had with the OMAPs overclocking as a simple user.
PS: Nobody would want to lose Notaz, right?
Large heatsinks or fans should not be needed and would make the design too bulky anyway and if you have to lower the highend-CPUs performance all the time nothing is gained by choosing it but a higher price.
Me too and in the end they have earned a veto anyway.
I'd stick to ARM mostly because of them and the good experience I had with the OMAPs overclocking as a simple user.
PS: Nobody would want to lose Notaz, right?
Last edited by a moderator:
pandora never quite fared well in programming department but pyra will change that as it'll have enough power and RAM to run any IDE, will have enough flash to install any kind of development packages and these packages will be available since it's debian we're talking about and will have dock station to comfortably code on it with big monitor,mouse and keyboard. A development heaven in my opinion.
And nothing stops you from developing on your laptop or something and then compile and test it on pyra
You know, since SoC doesn't produce mechanical work its power dissipation equals its power consumption (energy conservation law)
Last edited by a moderator:
That's what I thought, but I don't know what dark magic come companies may be adding there.
slaeshjag
¯\_(ツ)_/¯
Notaz does not like x86. Notaz has publically stated that he will leave if Pyra goes x86.
ekianjo
Hardcore Member
It's not effortless. Most indie games are made for large screens. Look at FTL : it wouldn't work on a 5'' screen. And there are many other like that.Im sure x86 will help bring INDIE DEVELOPERS to PYRA easily [effordless]. Basically indie devs will need add to every app/game proper scalling (small code) for Pyra and port's done
Plus, If the game is written in C/C++/SDL, there shouldn't be much extra work to compile for ARM instead of x86. What's preventing current devs to make stuff on ARM Linux is that the market is very small, not that it's technically difficult.
ivanovic
Active Member
- Joined
- Aug 4, 2006
- Messages
- 784
Personally I would love to see an X86 since the kernel appears to be a lot better maintained for this architecture. Besides there is also the benefit of being able to use the full graphics stack which means you can just use "full" OpenGL easing the work on open source games since you can just use the existing Linux version, often with a binary directly in the package manager. The point about "energy optimizations for software" is IMO less of a problem, since those could just happen directly as part of upstream so would benefit the complete community, not just the Pyra itself.
Significant downside though is that large parts of the community are strong in the area of ARM development and ARM specific optimizations. Another "problem" would be the absence of many Android specific programs/games. Those are usually made with touch interface only and multitouch gestures in mind anyway, which is not the usual way in which a handheld like the Pyra would be used. So IMO, if neither price nor energy usage nor usability/availability of hardware speak against it, going for X86 would be a nice step.
Significant downside though is that large parts of the community are strong in the area of ARM development and ARM specific optimizations. Another "problem" would be the absence of many Android specific programs/games. Those are usually made with touch interface only and multitouch gestures in mind anyway, which is not the usual way in which a handheld like the Pyra would be used. So IMO, if neither price nor energy usage nor usability/availability of hardware speak against it, going for X86 would be a nice step.
Rockthesmurf
Advanced Member
My voting has followed the poll leaders, balanced power, ARM CPU and open source where possible but not fussed if some parts aren't.
My only thing that didn't follow the leader is the final question, for which I voted for the opens source drivers question, as the thing that would be most likely to put me off purchasing would be if I feel the unit has ended up worse than it needs to be just to be 'open' for the sake of it.
Some things are a little hard to vote without more information, i.e. for battery if three choices were:
2.0 GHz, 6 hours battery life
1.5 GHz, 8 hours battery life
1.0 GHz, 10 hours battery life
I'd probably be more tempted by the 2.0 GHz option, as 6 hours is fine for me, I don't mind changing batteries after that, and to get a considerable gain it seems worthwhile. But on the flip side, it might be the case we'd get 10% better performance for 50% less battery life, in which case I'd rather have the battery. Anyway, I thought voting for the middle option was the best bet
My only thing that didn't follow the leader is the final question, for which I voted for the opens source drivers question, as the thing that would be most likely to put me off purchasing would be if I feel the unit has ended up worse than it needs to be just to be 'open' for the sake of it.
Some things are a little hard to vote without more information, i.e. for battery if three choices were:
2.0 GHz, 6 hours battery life
1.5 GHz, 8 hours battery life
1.0 GHz, 10 hours battery life
I'd probably be more tempted by the 2.0 GHz option, as 6 hours is fine for me, I don't mind changing batteries after that, and to get a considerable gain it seems worthwhile. But on the flip side, it might be the case we'd get 10% better performance for 50% less battery life, in which case I'd rather have the battery. Anyway, I thought voting for the middle option was the best bet
Similar threads
