How to calculate a price for the Pyra

[TrashyMG]

If there are multiple Pyra SoCs, most developers won't have access to all of them. For example, a developer will be able to provide an OMAP build, but not an x86 build of a PND.

It's more likely that a person who is able to provide an OMAP/ARM build could easily do an x86 build.. Most open-source software outside of some of the ones heavily optimized for one architecture or another should be fairly easy to compile on both.

 

[pmprog]

So after I build my ARM version, I'll have to power down my Pyra, swap the SoC board to the x86, power back up and recompile?

Hmmm, I hope there's a good cross-compiler setup

 

[_wb_]

An automated build server will help a lot. But still it makes sense to have SoC upgrade modules that are backwards compatible, since some people still like to do platform-specific optimization (e.g. NEON assembler code), and some people also like to use closed source software.

 

[notaz]

It's more likely that a person who is able to provide an OMAP/ARM build could easily do an x86 build..

In perfect world that would probably be enough, but not really in reality because of various differences, especially with GPUs (different driver bugs, different GL extensions supported). Multiple modules will hurt developers inevitably.

So with the modularity in mind, could a lesson from android be taken? Android excels at being mostly hardware agnostic (screen size & specific architecture aside from general arm-v7 compatible doesn't really matter)

That's only in theory, in practice there are tons of device specific issues you have to go through, unless your app is really simple.

 

[CrazyIvan]

Then come the timing problems etc etc...

 
This is bad code you know, not device's problem. Solving such problems is not a matter of compatibility but code quality. You don't want you project to die with (for example) pandora rebirth, do you?

In the x86 world, the dev could just said : i dont support your GPU. Get a supported one (still very common reply).

There are standards you know. If GPU driver is broken you could support it but you shouldn't expect other drivers to be broken in the same way as it badly affects long-term support of you project.

If GPU driver is broken then it's driver's developers job to fix it and they may fix it especially if it's opensource driver. 

You shouldn't actively prevent this by relying on current driver's bugs.

 

[Exophase]

The problems with different GPU driver bugs even between SoC revisions is a big deal.. but I don't think the takeaway message is to never upgrade the hardware. It sucks if a few devs have had headaches with 1GHz units because of this but there's no way that this outweighs the benefit of the 1GHz units.

To me the bigger lesson is to do what you can to avoid relying on GPU binary blobs for OSes that almost no one with that GPU is using. IMO ED should be investigating libhybris solutions even in cases where there's a proper Linux version. Especially when that GPU driver is only promised. Did GCW-Zero ever even get the officially supported GPU driver they were promised, rather than having to rely on etnaviv? ODROID-XU also has no official GPU driver. It's unfortunate that we're probably stuck with IMG where there's no real GPU reverse engineering effort but at least the community should try to somehow encourage this effort from someone. There's got to be someone here who wants to do some of that work or who can influence others who do, and maybe a donation fund or even kickstarter could help.. It's amazing that PowerVR is on so many platforms and even a lot of them with enthusiast Linux boards, and there's existing push from FSF, but still no real RE project.

 

[EvilDragon]

I wouldn't suggest to think too much about that right now - it will be years and years away.

No one knows what SoCs will be available then.

64bit is also something that will change...

 

[SNESFAN]

That's only in theory, in practice there are tons of device specific issues you have to go through, unless your app is really simple.

I wouldn't be so sure about that, take netflix for example, that software is riddled with drm and ndk code (requires armv7) and is universally compatible. They do also have builds for different architectures like x86 (google tv) but it's a pretty complex app IMO it works on basically every android device ever made. I don't believe it uses neon code (works on tegra 2) so that may be a "simple app" in that regard. However my idea of simple app is a completely java app which is truly architecture independent (works on arm, x86, and mips) but I would go as far as to say most apps with few exceptions work like netflix.

If this were not the case then those cheap android game things wouldn't run barely anything because of the extremely varied screen size/resolution and from SoCs that aren't common in the mainstream market. But what is the situation is that you can run most everything on them. Gameloft wouldn't even bother considering a yinlips device, but trueth be told everything runs flawlessly as long at it meets the OS version requirements.

I think most apps on the pandora minus the works of yourself and exo are simple in the same regard. If they were ported to android in c with the ndk then I'd say they would be pretty universal in compatibility. I'm sure there's anomalies because of weird crap manufacturers spin into the OS, but if they were all running a stock vanilla android I would fairly confidently say universal compatibility.

I helped test drastic on android and exo/lordus didn't have some of those devices that it ran acceptably on right out of the box. That program used heavy neon code and screen size varied quite a bit... so I don't know... sounds reasonable to me to say it's at least something to consider even if not running apps in a virtual machine on a linux kernel. Some generic layer of compatibility would help people if one could be made.

 

[Exophase]

Android is a nightmare. Getting broad compatibility is possible but it sure isn't easy. Netflix has been plagued with one-off problems, including cases where it stopped working after an upgrade to a new version of Android. You don't have to search far to find examples. I'm sure they do a reasonable job countering these issues as they come up but that doesn't make it easy or cheap.

But Pyra with a few upgradeable modules can do much better than the Android configuration zoo, it shouldn't ever get anywhere close to that bad. Supporting both ARM and x86 would still be kind of a pain, hopefully it at least has fat binaries and a toolchain that easily supports this...

 

[SNESFAN]

The problems are OS build specific for the most part as I was saying, I think the hardware underneath plays little rolls especially when comparing mono core a8 vs quad core a9 vs dual core a15 and qualcom vs amlogic vs tegra  or all the different GPU's when it comes to app compatiblity. That was what my argument was about, being hardware agnostic as possible and providing an example of something that was at least attempting to do a similar thing. I could see game/app developers fearing the modularity otherwise.

Anyway, I think we're basically saying the same thing when it comes down to it and would agree that the concept of what android is trying to do if improved upon in a limited number of configuration would be a good idea as long as it's it's arm to arm. arm to x86 being a whole other animal, I could almost see not wanting to attempt that. At least considering a framework that would allow something like that now could remove problems later.

 

[CrazyIvan]

In perfect world that would probably be enough, but not really in reality because of various differences, especially with GPUs (different driver bugs, different GL extensions supported).

 
In pre-2.0 days there was a need to use driver-specific extensions but nowadays the need of driver-specific extensions is small as standards are broad enough.You just require minimum GL version and that's it. And workarounds for driver bugs is a dangerous thing as driver updates might break you app and that will be your fault.

Multiple modules will hurt developers inevitably.

 
But it will most certainly help make better software with better long term support.

 

[sebt3]

But it will most certainly help make better software with better long term support.

Pure BS. Most dev will stick to the boards they have and that's it...

 

[Klumpen]

I still wonder what kind of dual board design could result in not having to increase the height of the device tremendously. oO

 

[EvilDragon]

I have to emphasize once again:

The modular solution is NOT made to offer different SoC modules at once at the same time, but to offer an easy way to upgrade when the current model is EoL (like the Pandora is right now).

Don't expect a new module each few months!

 

[EvilDragon]

I still wonder what kind of dual board design could result in not having to increase the height of the device tremendously. oO

A design where the module is not thicker than the SD Card slots and USB Ports.


We got about 3mm heigth, afaik.


So if a PCB is 1mm thick, the plugs can be 2mm high, the SoC can be 2mm high, etc.


The SoC will be put on the same side of the board as the plug, so it is sandwiched between both PCBs. The main PCB will have a huge copper area for heat distributionj.

 

[_wb_]

This sounds really good and future-proof. Maybe it could even become a standard for modular open hardware at some point? E.g. imagine third parties making a case for an OUYA-like console, or a rugged military-grade case, or a case with more ergonomy and battery life at the expense of portability, where you can plug in the Pyra SoC module, or SoC manufacturers releasing not just a dev board but also (or instead) a Pyra SoC module. It's a nice dream

Anyway, for now, it is just a good way to ensure that if in 5 years ED wants to make a new device, chances are that more components can be reused, less redesign is needed and prototyping will be easier/faster. And you'll probably still at some point want to upgrade parts from the main pcb, like UHS-II SD slots, all USB 3.0 ports (and maybe a USB 4.0 port by then, who knows), 4G or 5G, etc.

 

[Natsu]

I have to emphasize once again:


The modular solution is NOT made to offer different SoC modules at once at the same time, but to offer an easy way to upgrade when the current model is EoL (like the Pandora is right now).


Don't expect a new module each few months!

Well then, rooting for Allwinner/Snapdragon even more so.

 

[Saber]

I still wonder what kind of dual board design could result in not having to increase the height of the device tremendously. oO

A design where the module is not thicker than the SD Card slots and USB Ports.


We got about 3mm heigth, afaik.


So if a PCB is 1mm thick, the plugs can be 2mm high, the SoC can be 2mm high, etc.


The SoC will be put on the same side of the board as the plug, so it is sandwiched between both PCBs. The main PCB will have a huge copper area for heat distributionj.

Excellent. :wub:

 

[superatarian]

If the Pyra turns out to be as good as my Pandora, price will not matter. I am planning on ordering one not matter what. I do not see why it will not be a success.

 

[leathco]

I look forward to getting one as well.  Not sure how early I could swing 700 dollars, but would be sometime during the year it releases.  I have my fingers crossed for something closer to 500 USD after all is said and done.