Getting closer...

[levi]

Oh, thanks for the info. Based on the DMIPS speed I expect the i.MX8 M to be a little faster than the OMAP5:
(https://en.wikipedia.org/wiki/Comparison_of_ARM_cores)

I didn't think the A53 would be that bad... but thanks for clarifying

From that page, the A53 is rated as 2.3DMIPS/MHz/core, while the A15 is rated as at least 3.5DMIPS/MHz/core. The A8 in our Pandoras is rated as 2.0DMIPS/MHz/core. At the same clock speeds therefore the A53-based iMX8 M will run only 15% faster than the OMAP3 on single core workloads. The OMAP5's A15 by comparison will run at least 75% faster.

Theoretically, if something were written to be perfectly parallelisable, the OMAP5 gives you at least 7DMIPS/MHz, while the i.MX8 gives you 9.2DMIPS/MHz. So it theoretically could run slightly faster by using all four cores at once, so maybe building big projects with make -j [threads] will be quicker, but most things will be slightly slower. And things that only run on a single core would be 34% slower.

Or at least all that would be true if those DMIPS/MHz/core figures were at all accurate and valid for things other than the DMIPS benchmark, which they rarely are in my experience. But hopefully if they're all off by the same percentages, those comparisons are still valid. And it ignores the fact the iMX-8 will let you work with 64-bit numbers in each instruction, rather than being limited to 32-bits at a time - but anyone working with 64-bit numbers a lot should probably be making use of NEON instructions anyway, which are 64-bit wide on both processors.

 

[vcoleiro1]

Yeah, the i.MX8 M would be a terrible idea to upgrade to.

Oh well, plenty of time to find another viable SOC as ED mentioned

 

[ible]

looks like the a53 doesn't have out-of-order execution. immune to spectre? (but slow.)

the preproduction i.mx-8 quadplus has an additional a72 core which can run faster (a72 is the successor to a57, which scores well on the DMIPS/core wikipedia comparison page):
https://www.nxp.com/products/proces...tualization-vision-3d-graphics-4k-video:i.MX8
but that may be more heat/power than desired (especially with dual GPUs), but it's the least beefy that includes something beyond the a53 cores.
https://en.wikipedia.org/wiki/I.MX#i.MX_8_series

 

[elwing]

but anyone working with 64-bit numbers a lot should probably be making use of NEON instructions anyway, which are 64-bit wide on both processors.

I agree, but the interesting question is not whether people should be using neon for 64bits, but rather "are they using neon for 64bits operations?"...

 

[EvilDragon]

looks like the a53 doesn't have out-of-order execution. immune to spectre? (but slow.)

the preproduction i.mx-8 quadplus has an additional a72 core which can run faster (a72 is the successor to a57, which scores well on the DMIPS/core wikipedia comparison page):
https://www.nxp.com/products/proces...tualization-vision-3d-graphics-4k-video:i.MX8
but that may be more heat/power than desired (especially with dual GPUs), but it's the least beefy that includes something beyond the a53 cores.
https://en.wikipedia.org/wiki/I.MX#i.MX_8_series

That's the automotive one. Please don't use these! They need a fan and eat batteries for breakfast.

We also have the automotive version of the OMAP5 (as the mobile version never went into production, sadly), but the iMX8 is worse with heat and power consumption.

The i.MX8-M Series is the one suitable for mobile usage.

 

[Yori]

Finally some news!

How close we are getting is making me quite excited!

 

[Caine]

Do you also get like just a handful of hours of sunshine over almost the entire autumn/winter season where you live?

No, plenty of sunshine over here. I wish it was as simple as that.

 

[Jumpman]

No, plenty of sunshine over here. I wish it was as simple as that.

I know what you mean, and then some.

Chris

 

[matzesu]

The good thing about this chinese New Year: GPD is also Chinese, so unless they mass produce the Win 2 in Europe or the USA, there is a big chance the Win 2 also got delayed..

 

[EvilDragon]

The good thing about this chinese New Year: GPD is also Chinese, so unless they mass produce the Win 2 in Europe or the USA, there is a big chance the Win 2 also got delayed..

Errrm, no. The production probably was planned to happen after the CNY anyways for the Win2

 

[matzesu]

"Verdammter Mist!!!, hätte ja klappen können"
Anyway, whe still have the sales from the Preeorders, and they can then spend the good experience in the world, maybe the customers of the Pyra arend the same of the GPD Win 2,

 

[skeezix]

Be careful about hyping up the second SoC too much; I'm already considering holding out for it.

It really depends on how long it takes me to save up the money versus how long it takes you to release the second CPU board. I know we both like to take our time in those respective departments.

Edit: I just realized I may have encouraged you to take even more time in delivering the second CPU board. Oops. >_>

Lol; "The Osbourne Effect" strikes again

 

[EvilDragon]

Lol; "The Osbourne Effect" strikes again

I still got my Osbourne 1 at home and it's working fine

 

[matzesu]

I thought "The Osbourne Effect" had anything to do whit Ozzy Osbourne from Black Sabbat...

Hey how if we whe could make "Paranoid" to the Hymn of the Pyra ?? "Pyranoid"

 

[levi]

I agree, but the interesting question is not whether people should be using neon for 64bits, but rather "are they using neon for 64bits operations?"...

Well, I think I learned about that use of it from an Exophase post talking about DraStic, so I can say at least he is, after profiling his emulator and working where time needs to be spent in writing the NEON code.

 

[Grench]

The i.MX8-M Series is the one suitable for mobile usage.

I can see where having FOSS drivers for 3D is very attractive - I like that part. Being tied to old kernels due to orphaned graphics blobs has never been fun.

I'm wondering, though, if that is enough of a plus to overweight the other performance negatives. Maybe if you gave the community a set of boundaries / criteria that they should stay within, they might be able to suggest additional alternatives?

I.e., what physical dimensions does the SoC package need to stay within? I.e. is a (1384 pin Flip chip BGA (21mm × 21mm, 0.5mm pitch)) too big physically?

Now that you're working further on the Pyra thermal envelope, you should be able to estimate a bit of what the maximum rated TDP or SDP you would like to see in a future SoC is.

You have mentioned before that you like products for the automotive sector because they tend to have longer in-stock shelf lives. That might be a firm or flexible requirement...?

For this community, Linux support is a must. However, not every company defines 'Linux Support' the same way. For some, they seem to claim Linux support because Joe in IT was able to boot command line Linux on a dev board and said it was neat. At some point the candidate SoCs would need to have a dev platform purchased and evaluated. So - existence of a dev board and existence of Linux drivers for the SoC complete with 3D graphics and peripherals would need to be verified.

Availability is another big sticking point. Everyone can recommend the latest and greatest smartphone SoC that big name brand company X makes. But, if that company isn't willing to sell a few thousand to an independent project, it isn't viable.

I'm not opposed to the i.MX8-M. It has some good traits. Is there any value to opening the process to suggestions?

 

[levi]

I think the offer of the i.MX8-M is off the table for the moment, due to the single core performance, which is significantly worse than the OMAP5's unless it can be clocked a hell of a lot faster (the reduced efficiency might make it better for overclocking, but there are always hard design limits that aren't thermally limited). Unless a lot of people are clamouring for the open source graphics and are willing to put up with somewhat slower single core performance, it's not really worth investigating even at the moment.

 

[Djoga'Ro]

I have an iMX6 SBC and I found the heat the CPU produced running simple python code to be rather excessive

The CPU has no concept of the level of sophistication your code is a display of.

So if you do use that for a CPU board upgrade you might as well upgrade to a 4K display.

Double that! I want stereo!

Don't forget the code on old consoles runs directly on hardware, often with fixed timing, while a modern OS thread can be be scheduled away anytime because OS decides it needs to do something else, so things will go out of sync very quickly.

What if one had an emulator to boot into? Not that I have one.

 

[ible]

RISC-V !!!!

but yes, probably we shouldn't speculate too much about the next CPU board, as we'll need to sell enough of the old pyras to make it sustainable. but i'm fine with slightly lower single-core performance as long as i get twice as long battery life .

 

[levi]

You can run the ARM as a single user system, but most emulators make use of the OSes graphics and sound libraries quite extensively, and those libraries depend on the kernel which comes with multiuser multiprocessing built in.

If you want to run stuff as close to on the metal as you can, I suggest you investigate RISC OS. It's a single user system with only limited multitasking, so once you launch an executable that thing runs and can't be preemtively interrupted by the kernel pretty much, and if you call the OS libraries it runs that code then returns to your code, simple as. It still has a few things hanging off ticker interrupts, such as routines to keep the sound buffer full, or to service the ethernet port, but those are hand crafted short routines written mainly by the people that designed the processor in the first place. Back when I used that OS, the computer's ethernet port had to be bought as an expansion card, and that card contained an EEPROM containing the code to service the port on a regular basis, and that would have been written by the people that made the card. I'm not sure where the ethernet code came from on recent editions of RISC OS that run on modern ARM chips though. But either way, it doesn't write log files, or ever need to rotate them, or fettle with the filesystem, or any of the other stuff that your grown up OS feels it needs to do from time to time.