Pyra Pyra-optimized engines

[pmprog]

Depends what communication methods are available. In the M4 Roadmap thread shared memory and share files were mentioned. Also, maybe a virtual network could be made between the two, then you might get something like IP or Named Pipes

 

[JonnyH]

The M4s are microcontrollers - maybe useful as they have a different power island so when the AP is suspended they can still do stuff (sensors, wake events, flashing lights etc.) but for 'application' performance? You'll probably get more improvements optimising a loop by a fraction of a percent, or overclocking the CPU by 10mhz.... Especially adding in the overhead of IPC.

The DSP and blitter however may be useful - I wonder if we can make a generic pulseaudio/alsa backend for mixing multiple channels or something similar using the DSP... Might be an issue if the DSP can't get interrupts or accurate times from the DAC though.
Plus the DSS as a compositor so you don't have to use the GPU fill rate.

 

[Magic Sam]

[BUMP]
Hi all, and Happy New Year

What about the K2 Operating Systems ?

http://k2os.org/

Modern mobile System-on-chip(SoC) often embraces heterogeneous cores that are hosted in separate coherence domains, i.e. no hardware coherence among them. This architecture promises high energy efficiency, however complicates software development, thus preventing the energy efficiency from being harvested by software.

Can we ease software development by properly constructing OS for such an architecture? To answer this question, we create K2. As a refactoring of Linux 3.4, K2 reuses most of the existing Linux source. Spanning heterogeneous coherence domains, K2 provides a single system image, preserves the current OS performance, and finally ensures high energy efficiency.

K2 runs on Texas Instruments OMAP4430/4460 SoC, the hearts of Samsung Galaxy Nexus, Amazon Kindle Fire, Google Glass, etc. OMAP4 incorporates both the powerful ARM Cortex-A9 and the low-power ARM Cortex-M3.

Would such an OS allow the devs to use both the A15s and M4s ?

Cheers, Magic Sam
[/BUMP]

 

[levi]

According to the parent study group that wrote that, it's a past project, as suggested by the kernel they were working against. I can't see exactly where they got to with that, in terms of text or at best a video of them running stuff on the M3 from the A9 side.

There may be some useful stuff in the dev notes for it though. Seems they're running a linux kernel on both chips, and as the big chip spins up it reserves some memory for the small side to use, then it starts the kernel on the cortex-M little side (using rproc, whatever that is). Maybe a similar trick can be used on the Pyra, although honestly I don't see it as a priority. The M4 are clocked a lot slower and run a different instruction set to the main cores, so are extremely limited. Maybe you could use them for something strictly real-time, but a linux kernel is decidedly non-real time even these days.

Maybe you could use a real-time OS to run on it. You don't really need a mutitasking OS for most purposes, and there are a lot of open source real-time OSes to choose from, and the modern ones I've just checked out all seem to support multithreading and other goodies we never used to have back on single user systems. You might not even need to find a use case for any of this before giving it a go.

 

[Magic Sam]

[BUMP]
Hi all,

I just compiled some OpenMP "Hello World" example from one of my previous post (https://pyra-handheld.com/boards/threads/pyra-optimized-engines.77358/post-1378687) on the Pyra.

I only get "Hello World from thread 0, There are 1 threads" in the output.

I would have expected an Hello World from thread 0 and 1, and 2 threads, since the Pyra has two cores...

What am I doing wrong ?

Cheers, Magic Sam
[/BUMP]