SoC: Back and forth!

[wej]

This "backdoor" that people claim to be in some processors, would actually be a deliberate flaw in the RNG of that CPU. Unless the implementers are really stupid, it is next to impossible to tell if the random numbers generated are truly random or not. So if you suspect there to be a backdoor, just don't use that RNG (or any crypto instruction for that matter). Those "backdoors" can be in any CPU, not just Intel. I still don't see the point in posting that link.

 

[risho]

The main stumbling block with Qualcomm chipsets is the whole "open" concept that the Pyra is aiming for. Qualcomm is not one to give up its intellectual property easily, and I think this is one of the reasons why publicly available documentation is sparse and open source support is shoddy. Sure, there are open source projects that are helping to support Qualcomm devices (like Rob Clark's freedreno project), but a successful device won't exist without tons of support direct from Qualcomm.  

One "sociological" disadvantage of x86 is that it is likely to attract hordes of gamers who are attracted to the idea of a handheld that can run proprietary x86 PC games. It would most likely dilute our community to the point that the proportion of nice, smart and interesting people is reduced to homeopathic levels.

I was very excited about hearing about the possibility for using qualcomm or intel, but both of these posts are very compelling points against it. I don't want to have higher performance at the risk of diluting and destroying our community, and I don't want to have higher performance at the risk of winding up in a walled garden. I think over performance, we should consider the community and the open nature of this project. If we have to use weaker hardware in order to allow of innovation and the ability to sustain ourselves without relying on large companies to not abandon their hardware in a year or so then so be it. If we have to use weaker hardware to protect this niche that has been created and protect this community then so be it. My 2 cents.

 

[wej]

I don't think what _wb_calls a sociological disadvantage actually is a disadvantage. Yes, there might be those gamers who buy the device because they can possibly run their favorite x86 games, but would that really be such a bad thing? For the Pyra's success it could certainly be quite helpful. After all, it should be in everyone's interest to have as much Pyras as possible out there.

It is not like it would be a problem to create a sub forum for those gamers where they can talk about their games all day long.

 

[mjohansson]

I posted the link to the "backdoor" cos of intel came up as discussion, I just remembered something vaguely in the back of my head and this was my quick googling, since I dont understand these matters I hoped someone who did would comment or explain anything about it, if there was indeed an intended backdoor built in then that would be a reason to boycott imo.

 

[rohezal]

I think we should start to talk about putting the source into the pnd. Or upload the source to the repo and let the repo do the building. This way (maybe a bit like debian autobuild its repos) we can add new archtitectures easily.

Speed comparision:

Omap5: 2x1.7 Ghz

Snapdragon 800: 4x2.3 Ghz

Four cores are not easy to use in emulation (PSCX2 is using 3 cores), but it sounds promising.

 

[Michoko]

I must say that the intel SoC idea looks surprisingly attractive to me. I can think of some interesting pieces of software (Zsnes first coming to my mind) that would benefit from it. The first Xbox had some good ports thanks to its intel architecture.

I value this community more than any other aspect related to the Pandora. But I'm not sure keeping it confidential by fear of seeing hordes of gamers is a very good strategy. After all, the Pyra is also supposed to be successful, and there are interesting people everywhere. Keeping gamers away, like if they were some kind of plague, sounds a bit shortsighted (and xenophobic) IMO.

Anyway, I'm sure that ED and the rest of the team, will make a very educated choice, much more educated than mine, given my current knowledge of the different options. But as a potential customer, I wanted to say the intel option was appealing to me, because it seems to open many new doors (some will say too many though: but as a customer, I also want to get the most versatile device, that's why I already enjoy my Pandora so much ).

 

[Linux-SWAT]

This is where we land when moderators don't moderate.

 

[ghostpatch]

^ why? our discussion is perfectly fitting for this thread --> "SoC: Back and forth!" : p

A lot of things have changed since our last debate (new Intel SoC generation, 4000 page documentation, possibility of getting a Qualcomm SoC, etc.). Enough worth talking about. Its kinda fun too

 

[wej]

This is where we land when moderators don't moderate.

I agree. None of your posts in this thread are even remotely on-topic, unlike most others.

Mods: Feel free to delete this post.

 

[Michoko]

This is where we land when moderators don't moderate.

Is this remark aimed at my post? I don't think it is either off topic, or trolling in any way. Just stating an opinion about the intel SoC, which has been discussed in other posts on this same topic. As an open community, I suppose we have the right to give feedback to ED and the rest of the team, so they also know what their customers would be attracted to? Or are there some taboo subjects because there are some fanboys there? Talking doesn't hurt anybody.

I said that their choice would be perfect for me, whatever it is, anyway. But can we at least voice our opinion, or it asking too much?

 

[Linux-SWAT]

No that wasn't aimed at you.

ED was clear, ARM is choosen, so no further discussion is needed on the subject. Who is off-topic ?

Also in the past monthes there's plenty of threads which were derailed by x86 trolls. It was clearly on-purpose pollution and was barely moderated.

 

[EvilDragon]

True. Well, thanks to the way we are approaching the PCB design (having all size-critical components on the PCB and connect that to a devboard), the SoC is the last thing we put onto our design, so we can still work on that.

Intel sounds interesting now as well - but I'm still a bit sceptical.

Intel HAS modified their benchmarks in the past, I've not yet seen 3rd party testings of the intel chip.

Here's a recent article about that:

http://www.androidauthority.com/intel-vs-arm-future-mobile-technology-338340/

It seems in real life the current intel is between the Snapdragon 600 and 800 (though the Snapdragon probably doesn't have 2D acceleration, so for a Linux desktop, Intel would probably be faster), and the Snapdragon 805 will outperform the Intel again.

It looks like it'll continue like that for a while - the latest SoC will probably always be the fastest one.

We cannot keep up with that and always waiting for the next generation won't help, as development also takes time!

We've got a few important things we always need to check:

• How complex is it in hardware design? (OMAP5 is great here, as we have the schematics of the EVM and can move that over). Needs to be checked with Qualcomm and Intel as well.
• Does it have all the features we need? (Qualcomm seems to be missing Linux stuff, based on our knowledge, but that needs to be checked).
• How open is it? (Intel has good Linux support, as has the OMAP5 (except for the 3D part). Qualcomm doesn't really support Linux. Additionally, from what we know, Qualcomm does not allow releasing schematics of your own stuff (NDA), which is no problem with TI (and probably not with Intel, don't know).

These are things we need to check.

One thing that scares me a bit about Intel is that most software derived from normal desktop PCs - and as desktop PCs always had lots of horsepower, the software often hasn't been optimized.

So while you COULD run normal x86 games, it could very well be that they suck your battery dry within a short time.

Same for emulators - as ARM was slower all the time, emulators have become VERY optimized here, whereas on the PC emulators have become LESS optimized to be more compatible (but need more CPU time).

There's also WINE-QEMU for ARM in the works, I've met one of the developers at the FOSDEM and he was interested. So Windows games might also run on the OMAP5.

Linux x86 games could work with QEMU and using native libraries on an ARM system as well.

First, we need to gather more information.

There are a lot of pros and cons - but most important: We need to check what we can build with limited ressources (and without needing years).

Right now, I'm still in favor of ARM, simply because x86 seems to be a mess sometimes (according to developers), we KNOW ARM quite well, we CAN reuse all the NEON code that's been used for our optimized emulators, etc., and I'm not sure if it's good having a handheld able to run x86 games when the battery is empty after 1 - 2 hours because they simply were made for high-power machines.

 

[PokeParadox]

I'm glad you are being cautious ED!

I think it's kind of silly to scrap the software foundation we already have in ARM... and I do think the people that are harping on about x86 are under an illusion that it's somehow the magic bullet for software...

 

[TrashyMG]

There's also WINE-QEMU for ARM in the works, I've met one of the developers at the FOSDEM and he was interested. So Windows games might also run on the OMAP5. Linux x86 games could work with QEMU and using native libraries on an ARM system as well.

This is another developer other than Lunixboch's work on it? His version of Wine-QEMU with his opengl implementation had half-life 1 running, but slow.. another version he passed to me had is almost playable, but with graphical glitches.. So in my mind even with ARM based SoC in the pyra it will open some doorways in Windows gaming through wine.

 

[wej]

I'm not sure if it's good having a handheld able to run x86 games when the battery is empty after 1 - 2 hours because they simply were made for high-power machines.

That should not be the case. Maybe some games run slowly because they are poorly implemented, but the Intel chip does not consume arbitrary amounts of energy. Its TDP is pretty much the same as that of the competiting ARM SoCs. The actual power consumption of the previous generation was even lower than that of similar Cortex-A15 SoC (see the Anandtech article in one of my previous posts). The new 22 nm generation is supposed to be even more efficient (I haven't found such a comparison for the new chips, but when comparing the desktop generations, this assumptions is probably true).

I don't think the choice should be made based on the speed of the SoC. Probably all of the SoC in question are fast enough. The more importaant aspects are things like "openness". This is supposed to be an open source handheld after all. In that regard Intel clearly stands out. Qualcomm itself is rather disappointing in that regard, but the community support isn't all that bad (especially the open source graphics driver is nice), but surely needs to be investigated further.

With Intel it would probably be a lot easier to have complete mainline support for Pyra in the kernel. Which would be a very nice thing. That was probably what I found most disappointing about the Pandora.

and I do think the people that are harping on about x86 are under an illusion that it's somehow the magic bullet for software...

Not at all. As I said earlier, the actual architecture does not matter in most cases anyway. There are a lot of other aspects when it comes to SoCs and those can actually be more important than the architecture of the CPU cores.

 

[EvilDragon]

There's also WINE-QEMU for ARM in the works, I've met one of the developers at the FOSDEM and he was interested. So Windows games might also run on the OMAP5. Linux x86 games could work with QEMU and using native libraries on an ARM system as well.

This is another developer other than Lunixboch's work on it? His version of Wine-QEMU with his opengl implementation had half-life 1 running, but slow.. another version he passed to me had is almost playable, but with graphical glitches.. So in my mind even with ARM based SoC in the pyra it will open some doorways in Windows gaming through wine.

Yes, it's another developer (WINE is doing this officially), and I wanted to get in contact with lunixbochs about it, they can collaborate on both.

I'm not sure if it's good having a handheld able to run x86 games when the battery is empty after 1 - 2 hours because they simply were made for high-power machines.

That should not be the case. Maybe some games run slowly because they are poorly implemented, but the Intel chip does not consume arbitrary amounts of energy. Its TDP is pretty much the same as that of the competiting ARM SoCs. The actual power consumption of the previous generation was even lower than that of similar Cortex-A15 SoC (see the Anandtech article in one of my previous posts). The new 22 nm generation is supposed to be even more efficient (I haven't found such a comparison for the new chips, but when comparing the desktop generations, this assumptions is probably true).

I don't think the choice should be made based on the speed of the SoC. Probably all of the SoC in question are fast enough. The more importaant aspects are things like "openness". This is supposed to be an open source handheld after all. In that regard Intel clearly stands out. Qualcomm itself is rather disappointing in that regard, but the community support isn't all that bad (especially the open source graphics driver is nice), but surely needs to be investigated further.

Yes, if the games are THAT unoptimized that they don't even run fullspeed, it won't matter (they won't be played anyways), but if a game runs fullspeed, it might be it uses 90% CPU power whereas it COULD run with 20% CPU power if it had been optimized.

The result would be a game running in fullspeed with a very high power consumption.

You don't think that a normal ARM game (mostly created to run on smartphones 1 - 3 years old) is more optimized than a normal x86 game (where developers don't care about the system that much, as the user can simply buy a new GPU / PC).

ARM was pretty much fixed in speed (slower thant current PCs), and game developers tried to get the same or similar games out on that platform.

Max Payne or GTA3 probably is more optimized on ARM than the old PC version.

Speed is not the main issue to choose an SoC, but if the device is out, people and press try to run all kinds of PC games and then complain about the battery life, it's not a good start either.

 

[Ziz]

Foxblock showed me something interesting a few moments ago...

http://repo.openpandora.org/?page=detail&app=windowsrg.dimag0g

 

[wej]

Yes, if the games are THAT unoptimized that they don't even run fullspeed, it won't matter (they won't be played anyways), but if a game runs fullspeed, it might be it uses 90% CPU power whereas it COULD run with 20% CPU power if it had been optimized. The result would be a game running in fullspeed with a very high power consumption. You don't think that a normal ARM game (mostly created to run on smartphones 1 - 3 years old) is more optimized than a normal x86 game (where developers don't care about the system that much, as the user can simply buy a new GPU / PC).

Oh, that was not what I meant. I do not doubt that ARM games might be more optimized in terms of ressource usage than the average PC game. That's probably the case, because of the reasons you mentioned. What I was trying to say is, that power consumption of those x86 SoC will not be that much different than those of the ARM SoC. Sure you want optimized x86 software, when running on a battery operated handheld. Then again, you don't have to run poorly optimized software, but it might still be nice if you can. Most open source software isn't optimized for one specific architecture anyway. Emulators are probably the only prominent exception, but as there were emulators on the PC when PCs were rather slow, there probably have also been optimizations on x86 emulator code.

Games from the GTA3 era should actually run fine on that SoC, even in Wine. PCs of that time were much slower so with a frame rate limited to the screen refresh, the CPU load should be reasonable.

 

[ghostpatch]

Well, we *may* be able to offer different and exchangeable CPU boards if we can squeeze them all onto a small and flat CPU only board... Maybe in a second step... Just dreaming

I hope not ; )

I think we should start to talk about putting the source into the pnd. Or upload the source to the repo and let the repo do the building. This way (maybe a bit like debian autobuild its repos) we can add new archtitectures easily.

In addition to pre-compiled pnd's, how about providing the source code together with architecture independent build scripts just like SlackBuild Scripts?

 

[Thorgan]

Oh, that was not what I meant. I do not doubt that ARM games might be more optimized in terms of ressource usage than the average PC game. That's probably the case, because of the reasons you mentioned. What I was trying to say is, that power consumption of those x86 SoC will not be that much different than those of the ARM SoC. 

CISC cpu's are supposed to perform better on poorly optimized code (I mean badly written assembly code or a poor compiler output). RISC cpu's on the other hand are only doing what they are told (very dependant of hand-made and compiler optimization). Compilers and langages are getting better and better which reduce the importance of the CISC advantage.


I sincerely doubt that x86 CISC overhead is free. Part of the bloat is hidden by the overengineering of these chips. That's why independant reviews of the intel chips are needed .