Overview of Libspe

出典: PS3 Linux Information Site / Cell/B.E.のパワーを体験しよう

On PS3 Linux, applications can use SPE which is a processor for floating point operations by utilizing a library called “libspe” (SPE Runtime Management Library).

Since November 2006, there are two versions of libspe, one has APIs using libspe1 and the other has APIs using libspe2. This is very confusing to users.

This page briefly describes situations and an overview of the programming environment using libspe on PS3 (or other Cell machine).

libspe 1.x and libspe 2.x

On IBM’s Cell SDK pages and Barcelona Supercomputing Center (BSC)’s site for Linux on Celllibraries for developing SPE using libspe 1.x (an old version of libspe) have been released since around 2006.

Since then, libspe 1.1 has been released in July 2006 as part of Cell SDK 1.1, and libspe 1.2 has been released in December 2006 as part of Cell SDK 2.0. You may have used the programming environment for libspe 1.x through Programming Tutorial in Cell wiki because it was opened in IBM’s Cell Simulator Environment at a very early stage.

On the other hand, the latest (as of Jun 2007) version of the Cell SDK 2.1 contains libspe 2.1 which is a newer version of libspe, and in this SDK libspe 1.2 is marked as “deprecated”. The libspe 2.X firstly appeared in the add-on package CD for PS3 which was released with the launch of PS3. The libspe 2.X is redesigned based on API for libspe 1, and it meets a wide range of programming requirements from the low levels (near the level of abstraction using an operating system) to the high levels comparing to libspe 1.x. In the current distribution of libspe 2.X, you can use APIs in the base layer which is the most basic level (near the level of system calls) and APIs in the event layer which is above the base layer.

Granularity of the base API for libspe2 is a bit more fine-grained than that of the API provided in libspe1. Unfortunately, APIs compatible with libspe1 have not been provided in the current libspe 2.X release, although these may be provided in future. Of course, you can rewrite programs using libspe1 to the equivalent programs using libspe2.

Still many sample programs or programming tutorials released so far are based on libspe1. However, the new version “libspe2” will gradually become the most popular in the programming environment for Cell Linux in future.

How to handle SPE using libspe

In the case of libspe1, the basic procedures to handle SPE are as follows:

1. spe_open_image: Open SPE program file.
2. spe_create_thread: Create SPE threadｓ (and then the SPE threads are executed immediately.).
3. spe_wait: Wait until the SPE threads are completed (and simultaneously destroy resources for the SPE threads.)
4. spe_close_image: Close SPE program file.

In libspe1, the SPE thread creation API (spe_create_thread) is closed immediately because when SPE thread is created, the corresponding PPE thread (pthread) is also created, and the thread called can continue to perform other processing. Therefore, even when using multiple SPEs, it is only necessary to call "spe_create_thread" a number of times (the number of SPEs).

In the base layer for libspe2, SPE is used based on the procedures below:

1. spe_image_open: Open SPE program file.
2. spe_context_create: Create SPE context.
3. spe_program_load: Load SPE execution image in LS for SPE context.
4. spe_context_run: Run SPE context.
5. spe_context_destroy: Destroy SPE context.
6. spe_image_close: Close SPE Program File.

One thing to notice here is that “spe_context_run” used to run SPE context is a blocking API. In other words, when calling “spe_context_run”, procedures on the caller side may not proceed to the next step unless SPE program terminates normally or abnormally, or you call the procedure for returning such procedures to PPE side (by issuing a stop signal).

Therefore, if multiple SPEs are used in the base layer for libspe2, write a program in combination with thread libraries (e.g. pthread) on PPE. The typical procedures when using “N” SPEs are as follows:

1. OPEN SPE Program File.
2. Create “N” SPE contexts.
3. Load SPE execution image in LS for SPE contexts.
4. Create “N” PPE threads. (e.g. pthread)
   1. Run the SPE contexts in the thread.
5. Wait until “N” PPE threads are completed.
6. Destroy “N” SPE contexts.
7. Close SPE Program.

How to handle SPE using spufs: Linux

This section briefly describes how SPE is abstracted on the operating system (Linux) for your reference.

On Linux, SPE is abstracted as a virtual file system called “spufs”. Physical SPE processor is managed as virtual SPU contexts on the operating system, and each SPU context makes up a single virtual directory for spufs. Although virtual files, such as mem file used to abstract memory (LS area) in SPE, mbox file, or others, are created under the virtual directory, such virtual files are rarely used by users directly.

As SPU contexts and physical SPE are mapped at a ratio of “n:m”, user-level programs can handle virtual SPEs over the number of physically available SPEs. Consequently, almost all the SPU contexts and the corresponding operation API are mapped on SPE contexts and API in the base layer for libspe2.

---

Back To Libspe: PS3 Programming Environment

© 2007 Fixstars Corporation. © 2007 Sony Computer Entertainment Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

DISCLAIMER

THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.