Abstract
The GScube, unveiled at Siggraph 2000, was to demonstrate what parallel programming can do. It showed SCEI's realization, that the single processor, sequential programming eventually needs to be phased out. The GScube - named after the PS2's Graphics Synthesizer chip was basically a parallel array of 16 improved PlayStations. This talk will discuss the design of the GScube and it's programming challenges as well as how the experience lead to the design of the CELL, which is at the heart of the new PLAYSTATION¨3.

Abstract
An industry leader in 3D photorealism and special effects, PoatÕs work has been seen in blockbuster feature films such as Starship Troopers, What Dreams May Come , and Matrix. Rudy was with Manex Entertainment (Alameda, Calif.) as part of the R&D team for What Dreams May Come. Partway through that film, he was pulled away to help design the imagery for Matrix. He was designated lead color and lighting supervisor on the film. Prior to Manex, he worked at Mass Illusion, (Lenox, Mass.) as Senior Technical Director on Starship Troopers. There he was given the task of creating software for the project, writing shaders, and designing all of the main lighting. He then went on to pursue creative Director ventures and spend some time at Wild Brain in San Francisco, Directing and developing ideas for look and lighting. Prior to that, Rudy created and directed a CG short film at Giant studios in Atlanta, again merging technology with creative ideas.

Abstract
Cooperative use of SPUs is critical to the performance of multifaceted, real-time applications such as games. The SPU Threads model is necessary for sharing SPUs between processes, but has undesired overhead when sharing SPUs inside a process. Many systems have been designed for sharing SPUs among application tasks, but none of them perform optimally for all use cases. The SPU Runtime System (SPURS) solves this problem by introducing a common scheduling layer that can be shared by all existing and (hopefully) future SPU task systems. SPURS is a multi-layered, SPU-centric scheduling framework. At 2 kilobytes, the SPURS Kernel is the only binary that is always resident in Local Store. The SPURS Kernel is responsible for cooperative, coarse-grained scheduling of SPU Workloads. The contents of a Workload is interpreted and processed by its associated Policy Module. SPURS is provided with two Policy Modules to satisfy the most common use cases of SPUs: multi-tasking and job streaming. With support for custom Policy Modules, SPURS allows high performance interoperation of heterogeneous SPU workloads without imposing any specific programming model.

Speaker Bio