I'm still rooting for the iMX8M
. The A15 cores actually offer a lot of raw power, but the 8M gives us 4 A53s which offer similar to better performance than the A15s (need to get some metrics to back this up) and have the benefits of aarch64. The power threshold for these SOCs is also really quite good.
https://www.nxp.com/docs/en/nxp/application-notes/AN12118.pdf. The dimensions of the chip are also similar to the OMAP5, though they are a little taller which may be a problem. Big benefit of this platform is existing and current kernel support from NXP. Any upgrade to the SOC board is a ways off though as the focus is definitely get the current one fully stabilized and as optimized as we can.
iMX8QM/P would also be quite awesome (A72x2+A53x4+GC7200x2) but the power threshold on these bad boys is likely to be way out of spec for what we are looking for. Power metrics haven't been released for these yet but the EVKs come with a big beefy heatsink and a fan so thats not a good sign...
I don't think there is much point in pursuing anything that doesn't double the performance per watt of the existing while staying within the existing envelope. I.e. it is going to have to be something in the 10nm or maybe 14nm process space while still being something that this project can actually obtain and afford.
Issue with using SOCs which are closer to state-of-the-art is part sourcing and manufacturer support. I've done work on some of these nicer SOCs (ie Snapdragon series) and they are near-impossible to source parts without an established relationship with manufacturer. You need to be purchasing very large quantities to even get a response from the sales team. The out-of-the-box software support is often very poor as well as they expect you to pay them to help you bring it up, rather than providing a fully featured and stable kernel. Additionally, getting access to the required documentation to implement this support is near-impossible and has a very high cost (I had no hardware documentation when I was working on it for a relatively large company. We had to reverse engineer a lot of the IP blocks). This route is really only worth it if you are expecting to ship units in the range of millions as the upfront cost of development is very high.
On the contrary, NXP's business model relies on accessibility and good out-of-the-box support. They sell in much smaller quantities and provide good support to provide a good platform for the littler guys like us. I could go on digikey right now and purchase a single iMX8 and download the technical reference manual, kernel, and necessary docs for free. And while the performance of the SOC I will get is not the absolute best on the market, it will be good enough for what I need to do and I will save a hell of a lot of time and money in development as I am starting from a very sold base.
The bottom line here is that a lot of the mobile processor market at the moment is based on getting the best specs and power metrics because thats what sells. A lot of this comes from marketing, but in practice this is partly due to the extremely inefficient nature of Android (the main target for these platforms). Android is about 70-80% Java code. While the JVM which it runs (Bionic/Dalvik) is highly optimized, you still have the majority of the OS frameworks running in a JVM (honestly these iMX series SOCs (excluding the 7, stay away from that one) run Android very well). On a device like the Pyra where the majority of the OS is based in well written C, we don't have anywhere near the need for the raw power these state-of-the-art SOCs provide. We can get very good performance out of a "weaker" SOC by properly leveraging the hardware acceleration the unit has to offer. While we would definitely benefit from the power threshold gains from SOCs built on a better process, from a business standpoint the cost of acquiring and using one of these SOCs is extreme in comparison. We would likely be looking at at least double the cost for a Pyra unit (plus longer development time as there is much more work to do and the software is developed purely on a volunteer basis) if ED could even swing sourcing any of these parts.
All this said, with
@daveshah's work on the OpenGL stuff, the Pyra runs damn well on the OMAP5.
