Direct SPE access for applications

This section describes how applications can access directly an SPE's local store memory and the various problem state registers.

The function spe_ls_area_get maps the local store of an SPE to the thread's address space. You can then access it like regular system memory. This is not recommended for regular use because DMA operations to and from local store are generally more efficient.

A more common use of the local store mapping is to communicate the effective address of one SPE’s local store to another SPE, which allows SPEs to use DMA operations to directly transfer data to and from another local store. This mode of data transfer is very efficient, because the DMA transfers go directly from SPE to SPE, and not through system memory.

The function spe_ps_area_get maps an area of an SPE's problem state registers to the thread's address space. The problem state pointer can be used to directly access problem state features without using library system calls.

Problem state features include multi-source synchronization, proxy DMAs, mailboxes, and signal notifiers. These pointers, along with local store pointers (see spe_ls_area_get), can also be used to perform and control SPE to SPE communications through mailboxes, DMAs and signal notification.

When you use direct problem state access, you must ensure that applications serialize multiple problem state operations appropriately. Also, when you use both library and direct problem state operations, these must be properly serialized with respect to each other. Otherwise, unexpected behavior, application errors, or both can occur.

Note: (Linux) If you stop a running SPU by writing to SPE_RunCntrl , this does not ensure that the Linux kernel (scheduler) is informed allowing it to reclaim the SPE resources.