Introduction

The Cell Broadband Engine (CBE) is the processor of the PS3. It features one main core, the PPE (Power Processing Element), which is a dual threaded core from the IBM POWER family, and six Synergistic Processing Elements (SPEs) are available to the user programs.

The SPEs are the computing elements of the Cell Broadband Engine processor of the PS3. They feature a computing core (SPU = Synergistic Processing Unit), 256 kB of local memory (local store) and a Memory Flow Controller (MFC), responsible for DMA transfers between local store and main memory, as well as synchronization with the other SPEs and the PPE.

The system allows two ways of handling SPEs by either using the raw SPU primitives or the SPU thread primitives. Both methods allow to efficiently exploit the SPEs, but SPU threads allow more flexibility. This tutorial only deals with SPU threads.

SPU threads

SPU threads are dedicated SPU programs running on the SPEs. There can be more running SPU threads as there are available SPEs, in that cas the system performs thread scheduling in order all threads to appear to be running simultaneously. However, scheduling has a cost, so performance-aware applications should try to avoid context switches by running exactly the needed number of threads. Ideally, unless in some very specific circumstances, only maximum 6 threads should be running simultaneously, as 6 SPEs are available on the PS3.

Running and stopping threads

Creating and running a SPU thread basically requires the following steps:

import a SPU program into a SPU image (see sysSpuImageOpen, sysSpuImageImport)
create a SPU thread group (see sysSpuThreadGroupCreate).
create the SPU thread (sysSpuThreadInitialize) for that group. Eventually create several threads for the group.
run the SPU thread group (sysSpuThreadGroupStart).

Then all threads of the group will run simultaneously. The whole thread group may eventually be preempted to allow the execution of concurrent thread groups. Obvisoulsy, if there is only one thread group running, or if all running thread groups do not exceed a total of 6 threads, no thread group is preempted.

The PPU can suspend and resume a thread group (sysSpuThreadGroupSuspend, sysSpuThreadGroupResume), preempt it (sysSpuThreadGroupYield), or even terminate it (sysSpuThreadGroupTerminate).

A SPU thread can eventually terminate itself with a call to spu_thread_exit. It also can terminate the whole SPU thread group (spu_thread_group_exit), or call the SPU thread group scheduler (spu_thread_group_yield).

A SPU thread group is terminated if all its threads are terminated.

The PPE must join a SPU thread group (sysSpuThreadGroupJoin) to ensure its threads are terminated.

Communication between threads

SPU threads can communicate with the running PPE threads, and also with other SPU threads within the same SPU thread group.

A PPE thread can :

read or write to a SPU thread's local store (sysSpuThreadWriteLocalStorage, sysSpuThreadReadLocalStorage)
write to a SPU's signal notification register (sysSpuThreadWriteSignal)

A SPU thread can :

issue DMA transfers with its MFC, between its local store and main memory, or between its local store and another SPU thread's local store. In the latter case the beginning of a SPU thread's local store effective address is SPU_THREAD_BASE + spu * SPU_THREAD_OFFSET (having spu the same thread index value as provided to sysSpuThreadInitialize).
write to another SPU's signal notification register. This must be done by writing to the memory-mapped IO registers through DMA transfers. In that case, the effective address to write to is SPU_THREAD_BASE + spu * SPU_THREAD_OFFSET (having spu the same thread index value as provided to sysSpuThreadInitialize) to which we add either SPU_THREAD_Sig_Notify_1 or SPU_THREAD_Sig_Notify_2, depending on the signal notification register to be written to.

For more information about DMA transfers and SPU programming in general, refer to the Cell Broadband Engine documentation.