Does the Wii U software use all 3 espresso cores?

[MyJoyConRunsHot]

This is just a simple hardware question but I'm doing some research on the Wii U and noticed that information on how the hardware divides user/system functions is scant compared to the 3DS. Was 1 CPU core reserved for background system functions or were all three espresso cores accessible on the user end?

 

[V10lator]

All 3 cores are accessible to software like games. When starting a new thread the software spawning it (i.E. a game) is able to decide on what core it should be pinned to (but pinning is not a must, it's just a good way to maximise performance).

On one core there's also background stuff running. Not 100% sure right now but IIRC it was core two (cores are numbered from 0 to 2). This background stuff is OS stuff as you expected through, so with clever pinning of tasks one can also maximise OS / hardware API performance here (and yes, I'm taling about also pinning tasks to core two, so they run on the same core as the OS background tasks / system functions)...

Aroma plugins on the other side don't follow this background core sheme IIRC. They can spawn/pin threads on any core they want as they have the same rights as the currently running software. Still didn't see any performance issues in demaning games or stuff caused by this.

 

[CrazySquid]

All 3 cores are accessible to software like games. When starting a new thread the software spawning it (i.E. a game) is able to decide on what core it should be pinned to (but pinning is not a must, it's just a good way to maximise performance).

On one core there's also background stuff running. Not 100% sure right now but IIRC it was core two (cores are numbered from 0 to 2). This background stuff is OS stuff as you expected through, so with clever pinning of tasks one can also maximise OS / hardware API performance here (and yes, I'm taling about also pinning tasks to core two, so they run on the same core as the OS background tasks / system functions)...

Aroma plugins on the other side don't follow this background core sheme IIRC. They can spawn/pin threads on any core they want as they have the same rights as the currently running software. Still didn't see any performance issues in demaning games or stuff caused by this.

I thought OS and background stuff was handled by the ARM. Iirc the Wii U SDK explains this, probably will read it later on

 

[V10lator]

@CrazySquid I simplified a lot... To explain this in full defail you would have to not only read the SDK docs but also understand what Nintendo doesn't tell you...

On the ARM there's IOSU. That's more or less IOS (the Wii operating system) but modified to suit the Wii U.
The ARM is basically the security chip of the Wii U: Mostly all hardware is wired to it and software on the PPC has to ask the ARM / IOSU nicely to get data from/to hardware.

On the PPC there's running another operating system: CafeOS. And that's having background tasks on core 2 which talk a lot to IOSU through an IPC mechanism between the ARM and the PPC.

Note that this was still extremely simplified...

//EDIT: But as you have access to the SDK docs it seems, this is straight from it:

The OS performs some tasks on different cores. When these tasks run, the CPU cache is effected, which has the potential to arbitrarily slow down application code. Currently, most sound processing is performed on the core from which AXInit is called. Some graphics processing is performed on Core 0, and all background processes run on Core 2

When a process is moved to the background, it has access to Core 2, and the Filesystem and Network libraries work on these cores. For this reason, it is recommended that you use Core 2 for those features. For more information, see Application Lifecycle.