SoC Poll - What's most important for you?

Power or Battery - what's more important for you?

  • Power - I don't care about battery, as long as it's the FASTEST!

    Votes: 38 11.0%
  • Balanced - I don't mind a little shorter battery life if it has more power

    Votes: 199 57.5%
  • Battery - I'm pretty sure every current SoC is fast enough for my needs, but I want a long battery l

    Votes: 109 31.5%

  • Total voters
    346

I want the Pyra to be like the Pandora, but more powerful.

That's why my votes were:

Power/CPU - Balanced

Open/Closed source - Balanced

ARM/x86 - ARM

Preference - Power/CPU

I have a handheld x86 device already (Sony Vaio UX1XN), and I've found it underwhelming in the gaming department. The Pyra would probably end up being another device like that, unless many people start coding their x86 games and whatnot much more efficiently.
 
Last edited by a moderator:
I voted Balanced power usage, and that CPU Arch is most important, but I have since changed my mind about those two answers.

I would like maximum battery life prioritized above all, and would consider that the most important.

Out of everything I love about the Pandora, the battery life is by far my favorite feature.  If the Pyra could improve upon that by as much as possible I'll be all for it.  Give me a battery five times as thick but lasts five times as long and I will stick to cargo pants only from now on just to compensate.
 
Didn't vote on this poll since it's too, well, simplistic given it makes us choose implementation details and not our goals with nothing but our imagination and very limited knowledge connecting both.

I'd like to write the goals connected to these questions and I think many of you would accept it

1. I'd like to have as much power as possible when I need it AND the ability to limit maximum power to archive great battery life when I need it.

In the past when clock was (semi) constant this was called downclocking. Nowadays all modern SoCs are limited mostly by maximum power instead of maximum clock frequency because some code may require more power to execute than the other at the same clock rate so limiting maximum clock is not the most effective way of power capping.

There are some words in intel z3* datasheet about the ability to change SDP for some processors and there is another way which uses exposed power counters in new intel CPUs (http://www.phoronix.com/scan.php?page=news_item&px=MTQ2NTk). I don't know anything about ARM SoCs though but I think there should be some mechanisms like that.

2. I care about being able to run the latest kernel (maybe not THE latest, something like half year delay is perfectly acceptable) as long as i'll have a working pyra in my hands.

What would that mean in terms of open source drivers? I might have my ideas which might be correct. It might even not be possible at all but how far we can go that route and what drivers we can choose to be open source or close source to walk this road as far as possible? I don't really have enough information about specifics so the answer could be as good as an answer obtained by  flipping the coin.

3. This question is actually a correct one as I really don't care as long as it's fast enough and well-supported (see question 2). May as well be MIPS

4. This question is bad as choosing the most important and leaving the others means the vote may be misinterpreted in many interesting ways (basically it means that other questions aren't important to a voter)

This should be changed to the order of preference (or split into multiple questions like 'what's the most important question', 'what's second most important...', '...the last question')
 
Last edited by a moderator:
^1) Sounds like balance 

 2) Sounds like system up-to-date

 3) OK

 4) Most important doesn't = others not important. It doesn't reflect the individual 2nd and 3rd, but it does reflect the community 1st to 3rd importance.
 
Last edited by a moderator:
Give me a battery five times as thick but lasts five times as long and I will stick to cargo pants only from now on just to compensate.
 Ridiculous. I wouldn't mind a slighting bigger battery for more power, but "five times" just isn't going to happen. :lol:

 Besides, he seems unmoving towards making it bigger.
 
What is more important to me is that the Pyra exists, is successful and well designed. I'm very happy that you are considering options for the SoCs. I would say to go for the safest route to success.

That being said, I answered battery, open source, don't care about the architecture, priority on battery/CPU.

I'm interested in the Linux mini-computer aspect, I'd love to have open source drivers to ensure I can install standard Debian even 10 years later and not needing to mess with anything.

I'm also interested in game emulators, I have a feeling that no SoC from the list will enable Dolphin, Yabause or PCSX2 because they are not powerful enough and they all should be beefy enough for Dreamcast. The only emulator I feel could behave differently on the different Socs of this generation would be PPSSPP. But I don't care much about PSP games. So even if the weaker CPU is chosen, I don't really mind. Maybe I'm doing a wrong analysis here. Feel free to answer me if you think I'm mistaken on this.
 
Last edited by a moderator:
The focus on open source on the boards, with the exception of people raising the issue because theiy are in favour of x86, have been for the case of freedom itself. The x86 option in this regard is the not-preferred option because it is delivered with lock down uefi-bios compared to u-boot for the other offerings. Which is a huge case, you dont get longer than even thinking about running linux on it before you run into issues, potentially all the time down the road, without much power to do anything about it.
 
I voted for x86 only because of Haiku OS [and partially ReactOS]. Apparently there will be no port for ARM devices anytime soon, so Pandora could jump on x86 to get Haiku OS. Apart of that i dont care about battery life as long it lasts 6 h of work..
 
Last edited by a moderator:
1) Sounds like balance
 
You may be right but I didn't see anyone discussing that. Everything I read was about tdp or whatever supposed maximum power of chip. In that context this question is about maximum power consumption of the chip.

2) Sounds like system up-to-date
Without any timeframe given this means everything from ' i'd like to have up-to-date system for a couple of years after pyra production starts ' to my variant that means several (my guess is at least 5, probably about 10)  years after pyra production ends with everyone including ED probably have their own meaning of this. I'd like to have this clarified explicitly

4) Most important doesn't = others not important. It doesn't reflect the individual 2nd and 3rd, but it does reflect the community 1st to 3rd importance.
So for example when 90% of community chose 1-2-3 order and the rest 10% 3-1-2 you will see in general ranking 1-3 which would mean that question 2 should get lowest attention but 90% of people don't agree with this.

Actually I propose real Condorcet voting method (see   http://en.wikipedia.org/wiki/Condorcet_method)

The focus on open source on the boards, with the exception of people raising the issue because theiy are in favour of x86, have been for the case of freedom itself. The x86 option in this regard is the not-preferred option because it is delivered with lock down uefi-bios compared to u-boot for the other offerings. Which is a huge case, you dont get longer than even thinking about running linux on it before you run into issues, potentially all the time down the road, without much power to do anything about it.
You may not be right, see  http://www.phoronix.com/scan.php?page=news_item&px=MTU4OTU
 
For me it's important that your base system is fully open source. I voted for Yes, definitely regarding focus on open source drivers BUT I won't be angy or anything!

; )

The focus on open source on the boards, with the exception of people raising the issue because theiy are in favour of x86, have been for the case of freedom itself. The x86 option in this regard is the not-preferred option because it is delivered with lock down uefi-bios compared to u-boot for the other offerings. Which is a huge case, you dont get longer than even thinking about running linux on it before you run into issues, potentially all the time down the road, without much power to do anything about it.
Is it a fact that you need to use UEFI when using an Intel SoC? Because you make it sound like it is! If so, I'm against using an Intel SoC too. I absolutely hate UEFI. However I don't think it is. I've never heard of it and just look at the Comebooks powerd by Intel x86 SoCs. They use SeaBIOS/coreboot which is full open source! I got one of those, the Acer c720. It was easy to install Linux. Only the touchpad driver hasen't hade it upsteam yet. Still I'm quite happy with it and its fully open source drivers. ; )
 
Last edited by a moderator:
Well, if you are google/working with google, then you can have bay trail support in coreboot, everyone benefits from that, but turning that into working code for a specific board implementation is where atleast it requires effort on behalf of coreboot upstream and i dont know what else. Which is to say, i dont know if that means the road is fully open to the rest of us, nor how to go about it.

All chromebooks have had coreboot support, i think all of them with blobs here and there. It could be down to the vendor to not wish for it, but historically that has meant no working support for similar to that of the x86 coreboot products silicon.

What im worried about is the song and dance method of getting linux to work on bay trail tablets, which is the closest relevant comparison.  Having people be "angry", if that, about driver support is one thing, not being able to support your own products beyond supplying dc voltage is a potentially bigger and similar issue.
 
Last edited by a moderator:
For me it's important that your base system is fully open source. I voted for Yes, definitely regarding focus on open source drivers BUT I won't be angy or anything!

; )

The focus on open source on the boards, with the exception of people raising the issue because theiy are in favour of x86, have been for the case of freedom itself. The x86 option in this regard is the not-preferred option because it is delivered with lock down uefi-bios compared to u-boot for the other offerings. Which is a huge case, you dont get longer than even thinking about running linux on it before you run into issues, potentially all the time down the road, without much power to do anything about it.
Is it a fact that you need to use UEFI when using an Intel SoC? Because you make it sound like it is! If so, I'm against using an Intel SoC too. I absolutely hate UEFI. However I don't think it is. I've never heard of it and just look at the Comebooks powerd by Intel x86 SoCs. They use SeaBIOS/coreboot which is full open source! I got one of those, the Acer c720. It was easy to install Linux. Only the touchpad driver hasen't hade it upsteam yet. Still I'm quite happy with it and its fully open source drivers. ; )
there's no reason to use UEFI if CPU will not be sufficient to run windows 8 on these soc's, so i think as you mention there will be no UEFI
 
Last edited by a moderator:
I voted for x86, because obviously I personally have more interest in a mobile device that is fully x86 compatible (coming from the HP 200LX many years ago, and experiencing ARM-based devices always as kind of a compromise).

However, reading this thread, I see there are also good reasons for ARM, mainly the success of the Pandora / Pyra itself (independently from any use cases and performance or open source aspects). If we cannot use all the Pandora PNDs anymore, because they are compiled for ARM, this will probably be a success spoiler. Also the optimizations of e.g. the emulators, that are ARM-specific won't be an argument for buying a Pyra then.

So as much as I would love having an x86-based ultra-mobile computer again (as I already had almost 20 years ago with the HP 200LX), I see that it might be dangerous for the success of the Pyra. 

The idea of creating both flavors, first an ARM-based one, then an x86-based one, would be a good solution for this kind of problem. However, I doubt that this is financially possible. ED?
 
I dont mind to have 2 versions of pyra, but many devs will favour only one when porting stuff to pyra.. i mean if i buy x86 pyra i'll focus on x86 more than arm.. because i have more interest in it..

BTW. I dont care about OP legacy software, because mostly with bigger userbase successors for old apps/emus will eventually comes. Nobody was lamenting about OP that was no backward compatibiulty with GP2X :D where 50% of OP enthusiasts have gp2x back then..

Anyway , x86 is a good choice IMHO
 
Last edited by a moderator:
Back
Top