Terrain Rendering Engine (TRE):
Cell Broadband Engine Optimized Real-time Ray-caster
Barry Minor, IBM
11501 Burnet Rd.
Austin, TX 78758
[email protected]
Gordon Fossum, IBM
11501 Burnet Rd.
Austin, TX 78758
[email protected]
Abstract
The development of the Cell Broadband Engine
(CBE), together with the advent of commercially
available high resolution satellite images and
digital elevation models (DEM), brings new
possibilities to visualizing the world around us.
We introduce the Terrain Rendering Engine
(TRE), a client/server ray-casting system in
which the client, through a thin layer of network
interfaces, directs the CBE server to render and
deliver 3-dimensional (3D) terrain views at
interactive speed. The TRE server, optimized for
the Cell Broadband Engine Architecture, is a
ray-casting engine that can compute high
resolution, high quality 3D views of terrain in
real-time without the assistance of a Graphics
Processing Unit (GPU).
Moreover, the
flexibility of the client/server model allows quick
bring-up of the client interface on other systems.
Van To, IBM
11501 Burnet Rd.
Austin, TX 78758
[email protected]
capabilities of the CBE such a system can
achieve interactive frame rates at HDTV
resolutions.
In our application, we have two sets of input, a
digital elevation model (DEM) which consists of
a uniform grid containing elevation data and a
satellite image that contains color data for each
grid position. Figure 1.1 shows the two inputs we
have for Mt. Rainier in Washington State. The
DEM can be represented as a grey scale image
and the color satellite image can be saved as a
regular JPEG.
Keywords
Cell Broadband Engine (CBE), “Cell”,
Synergistic Processor Element (SPE), Single
Instruction Multiple Date (SIMD), Direct
Memory Access (DMA), graphics hardware, raycasting, Digital Elevation Model (DEM).
1. Introduction
The advent of commercially available high
resolution satellite imagery and USGS digital
elevation models (DEM) has greatly enhanced
our ability to visualize the world around us. In
this paper, we describe an interactive system, the
Terrain Rendering Engine (TRE) for visualizing
terrain in 3D with height data and satellite image
overlay using a software implementation of raycasting optimized for the Cell Broadband Engine
(CBE). The system implements a client/server
model where the client directs the server to
render, compress, and deliver images at
interactive speeds for remote display. We show
that by leveraging all the parallel processing
Figure 1.1
Digital Elevation Model and Color Satellite Image
In order for a traditional graphics processing unit
(GPU) to render this data it must be preprocessed
into a more digestible form. This typically
involves decomposing the height field specified
by the DEM into triangle meshes with precomputed texture and normal information per
triangle vertex. This process results in a huge
amount of data that is then transferred
redundantly, rows of shared vertices are
transferred multiple times, over an IO bus to the
GPU for rendering. Data relaxation techniques
can be used to reduce this volume of data but
they also reduce model detail. Furthermore
many of the triangles communicated to the GPU
are not even visible in the finished image. To
optimally handle this either the CPU must
remove some of the non-visible triangles via
system side view frustum culling and the rest
with GPU back facing, and depth buffering or
communicate the entire scene to the GPU each
frame and accept the degradation in performance.
Figure 1.2
TRE Ray-casting output
Rendering the terrain directly with ray-casting
[Figure 1.2] reduces the scene’s memory foot
print by removing the need to decompose the
height field into triangles and store pre-computed
normals.
Furthermore, ray-casting only
processes the visible terrain fragments, thereby
eliminating the need to cull and depth buffer
fragments. However, today’s general purpose
CPUs can’t handle such rendering tasks at
HDTV resolutions and interactive frame rates.
By leveraging the parallel processing capabilities
of the CBE, we can finally ray-cast large 3D
terrains in real-time.
This paper is organized as follows: section 2
contains background information on relevant
aspects of the Cell Broadband Engine
architecture; section 3 presents an overview of
the ray-casting algorithm used in this
implementation; section 4 gives a description of
the TRE system, including description of the
client/server model; section 5 provides detailed
description of our ray-casting implementation
and optimization on Cell; section 6 provides
detailed information on our image compression
technique; section 7 describes a technique called
SPE repurposing which we use to increase the
SPEs’ utilization; section 8 presents the TRE’s
performance results; and section 9 contains the
conclusion and future work.
Figure 2.1
Cell Broadband Engine
The key attributes of this concept are:
•
A high-frequency design, allowing the
processor to operate at a low voltage and
low power while maintaining high
performance [5].
•
Power Architecture® compatibility, to
provide a conventional entry point for
programmers, for virtualization and multiOS support, and to be able to leverage
IBM’s experience in designing and verifying
symmetric multiprocessors (SMP).
•
SIMD architecture, supported by both the
vector (VMX) extensions on the PPE and
the SPE, as one of the means to improve
game/media and scientific performance at
improved power efficiency.
•
A power and area efficient PPE that
implements the Power Architecture ISA and
supports the high design frequency.
•
SPE with local memory, asynchronous
coherent DMA, and a large unified register
file, in order to improve memory bandwidth
and to provide a new level of combined
power efficiency and performance [6][7].
•
A high-bandwidth on-chip coherent fabric
and high bandwidth memory, to deliver
performance on memory bandwidth
intensive applications and to allow for highbandwidth on-chip interactions between the
processor elements.
2. Cell Broadband Engine Overview
The Cell Broadband Engine (CBE) consists of
one dual-threaded Power Processor Element
(PPE) with eight SIMD Synergistic Processor
Elements (SPE), along with an on-chip memory
controller (MIC), and an on-chip controller for a
configurable I/O interface (BIC) interconnect
with a coherent on-chip Element Interconnect
Bus (EIB) [8].
•
High bandwidth flexible I/O configurable to
support a number of system organizations,
including a single BE configuration with
dual I/O interfaces, and a glue-less coherent
dual processor configuration.
•
A full custom modular implementation to
maximize performance per watt and
performance per square mm of silicon and to
facilitate the design of derivative products.
These features enable the CBE to excel at many
rendering tasks including ray-casting. The key
to performance on the CBE is leveraging the
SPEs efficiently by providing multiple
independent data parallel tasks that optimize well
in a SIMD processing environment.
information necessary to compute all of the
samples in that vertical cut is contained in a close
neighborhood of the intersection between the
vertical cut and the height map. Furthermore,
each sample in the vertical cut, when computed
from the bottom to top, only needs to consider
the height data found in the buffer starting at the
last known intersection.
These two
optimizations:
•
•
Greatly reduce the amount of height data
that needs to be considered when processing
each vertical cut of samples.
Continue to reduce the data that needs to be
considered as the vertical cut is processed.
4. TRE Application
3. Ray-casting Overview
The TRE uses a highly optimized height field
ray-caster to render images. Ray-casting, like
ray-tracing, follows mathematical rays of light
from the viewer’s virtual eye, through the view
plane, and into the virtual world. The first
location where the ray is found to intersect the
terrain is considered to be the visible surface.
Unlike ray-tracing which generates additional
secondary rays from the first point of intersection
to evaluate reflected and refracted light, raycasting evaluates lighting with a more
conventional approach. At this first point of
intersection a normal is computed to the surface
and a surface shader is evaluated to determine
the illumination of the sample. Ray-casting has
the performance advantage, unlike polygon
rendering, of only evaluating the visible samples.
The challenge of producing a high performance
ray-caster is finding the first intersection as
efficiently as possible. While ray-casting is
inherently a data-parallel computational problem,
the entire scene must be considered during each
ray intersection test.
The TRE is optimized to render height fields
which are 2D arrays of height values that
represent the surface to be viewed. A technique
call “vertical ray coherence [1]” was used to
optimize the ray-casting of such surfaces. This
optimization uses "vertical cuts", which are halfplanes perpendicular to the plane of the height
map, all radiating out from the vertical line
containing the eye point. Each such vertical cut
slices the view plane in a not-necessarily-vertical
line.
The big advantage is that all the
The TRE was implemented using a client server
model. The client, implemented on an Apple
G5 system, is connected to the server via a
gigabit Ethernet. The client specifies the terrain,
viewer position and view vector, and rendering
parameters to the TRE server which in turn
computes the 3D images and streams the
compressed images back to the client for display.
We have designed the interface between the
client and the CBE server to be flexible enough
so that we can replace the Apple client with any
light-weight device that has a display and a
framebuffer (i.e. wireless PDA, PlayStation
Portable).
4.1 TRE Server
The TRE server, implemented on the STIDC
CBE bring-up boards, runs on both uni-processor
(UP) and symmetric multi-processor (SMP)
mode. The server scales across as many SPEs as
there are available in the system. When the
server starts rendering a frame, one SPE is
reserved for image compression while the other
available SPE execute ray-casting kernels. Once
the frame compression is complete the reserved
SPE is repurposed for ray-casting. Three threads
execute on the available Multi-Threading (MT)
slots of the PPE. The three threads
responsibilities break down as follows:
1.
2.
3.
Frame preparation and SPE work
communication.
Network tasks involving frame delivery.
Network
tasks
involving
client
communication.
Thread one requires the most processor resource
followed by threads two and three, so threads
two and three share the same processor thread
affinity in the UP model.
The server implements a three frame deep
pipeline (Figure 4.1.2) to exploit all the
parallelism in the CBE.
Prep Frame 0
PPE
SPE 0-6
SPE 7
Prep Frame 1
Prep Frame 2
Prep Frame 3
Render Frame 0
Render Frame 1
Render Frame 2
Encode Frame 0
Encode Frame 1
Time
Figure 4.1.2
Server Image Pipeline
In stage one, the image preparation phase, PPE
thread one decomposes the view screen into
work blocks based on the vertical cuts dictated
by the view parameters. Stage two, the sample
generation phase, is where the SPEs decompose
the vertical cuts into rays, ray-cast the rays,
shade the samples, and store the samples into the
accumulation buffer. In stage three, the image
compression/network phase, the compression
SPE encodes the finished accumulation buffer
and PPE thread two delivers it to the network
layer. All three stages are simultaneously active
on different execution cores of the chip
maximizing the image throughput.
•
•
•
Server connection and selection
Map cropping
Streaming image decompression and display
5. Ray-casting on CBE
When implementing ray-casting of height fields
we use vertical ray coherence to break down the
rendering task into data parallel work blocks, or
vertical cuts of screen space samples, using the
PPE, and dispatching the blocks to ray kernels
running on the SPEs. It is key that the SPEs
work as independently as possible so as to not
over task the PPE, given the 8 to 1 ratio, and we
don’t want the SPE’s streaming data flowing
through the PPE’s cache hierarchy. These work
blocks are therefore mathematical descriptions of
the vertical cuts based on the current view
parameters. In Figure 5.1, where the green plane
intersects the gray height map are the locations
of the input height data needed to process the
vertical cut of samples. Where the green plane
intersects the blue view screen are the locations
of the accumulation buffer to be modified.
4.2 TRE Client
The TRE client directs the rendering of the TRE
server. We have picked the Apple G5 as the
platform to develop our client for aesthetic
reasons only. The client is very light-weight and
could easily be deployed on any device that has a
framebuffer and enough computational power to
receive, and decode our images. The current
TRE client provides for the following facilities:
•
•
•
•
Input data loading and delivery to the server
Smooth path generation both user directed
and random.
Joy stick directed flight simulation
Rendering parameter modification
o Sun angle
o Lighting parameters
o Fog and haze control
o Bump mapping control
o Output image size
o Number of SPEs to render
Figure 5.1
The PPE communicates the range of work blocks
each SPE is responsible for via base address,
count, and stride information once per frame.
Each SPE then uses this information to compute
the address of each work block which is then
read into local store via a DMA read and
processed. This decouples the PPE from the
vertical cut processing allowing it to prep the
next frame in parallel. The SPEs place the
output samples in an accumulation buffer using a
gather DMA read, modify, and a scatter DMA
write. Each SPE is responsible for four regions
of the screen. Vertical cuts are processed in a
round robin fashion, one vertical cut per region,
and left to right within a each region. No
synchronization is therefore needed on the
accumulation buffer read/modify/write as no two
SPEs will ever attempt to modify the same
locations in the accumulation buffer even with
two vertical cuts in flight (double buffering) per
SPE. The SPEs are free to run at their own pace
processing each vertical cut without any data
synchronization on the input or output. None of
the SPE’s input or output data is touched by the
PPE, thereby protecting the PPE’s cache
hierarchy from transient streaming data.
finds each intersection for rays in the vertical cut
thereafter.
Ray
Ray Intersection
Intersection
Shader
Shader
Texture
Texture Filtering
Filtering
Normal
Normal Generation
Generation
5.1 Ray Kernel
Bump
BumpMapping
Mapping
The SPE ray kernel is responsible for
decomposing each vertical cut into rays,
computing
the
ray/terrain
intersections,
evaluating the surface shader at each intersection,
and updating the accumulation buffer with the
new samples.
Lighting
Lighting
Atmosphere
Atmosphere
Sample
Sample Accumulation
Accumulation
This process begins with a command parser that
looks for work in the mailbox and dispatches the
proper code fragment.
The implemented
commands include:
•
•
•
Multi-Sample
Multi-Sample Adjustment
Adjustment
Update Rendering Context
Render Vertical Cuts
Repurpose to Encoder Kernel
The “Update Rendering Context” command
signals the SPE to DMA in a new block of
rendering state which includes such information
as shader parameters for the lighting model and
atmospheric effects. This command can be
issued on a per frame basis as the “Render
Vertical Cuts” command describes a frame’s
worth of vertical cuts to each SPE. The SPE
starts the rendering process by issuing a DMA to
bring in the first work block describing a vertical
cut. DMA lists are then computed to load the
required height/color and accumulation data.
Once the data is present in local store the
rendering loop is executed which decomposes
each vertical cut into rays, finds the ray/terrain
intersections, evaluates the shader at each
intersection, and updates the accumulation buffer
with new samples.
The two blocks of code that account for the
majority of ray kernel cycles are the intersection
test and shader. The intersection test is broken
into two phases, the first searches for the initial
ray’s intersection and the second more carefully
Figure 5.1.1
Ray Kernel Sample Generation
The shader provides both terrain illumination
and atmospheric effects. The current shader
contains the following functionality:
•
•
•
•
•
•
•
•
Texture filtering via a two by two color
neighborhood.
Surface normal computation via four by four
height neighborhood
Bump mapping via a normal perturbation
function [3]
Surface illumination via diffuse reflection
and ambient lighting model.
Visible sun plus halo effects
Non-linear atmospheric haze
Non-linear ground fog
Resolution independent Clouds computed
via multiple octaves of Perlin noise
evaluated on the fly [4].
Dynamic multi-sampling is implemented by
adjusting the distance between rays along the
vertical axis (vertical cut) based on the under or
over sampling of the prior four rays [2]. The
sampling rate along the horizontal axis is a
function of the size of the image, and is
computed to ensure that no pixel is skipped over,
even after accounting for round off error.
The compute and data fetch phases of the ray
kernel execute in parallel by exploiting the
asynchronous execution of the SPE’s DMA
engine (SMF) and SIMD core (SPU). Multiple
input and output buffers are used to decouple the
two phases. The ray kernel processes the data
using double buffered inputs and outputs so as to
cover up the memory latency and data load time.
Height/color and accumulation data are brought
in by the SMF for vertical cut n+1 while samples
are computed by the SPU for vertical cut n. This
results in the SPU waiting for DMA transferred
memory less than 1% of its execution time.
Texture color data is interleaved together with
height data in system memory, 16 bits of color
(5/6/5) and 16 bits of height. The surface shader
requires a four by four height neighborhood to
compute the surface normal and a two by two
neighborhood for texture filtering. The
height/color DMA list gathers blocks of four
height/color pairs along the intersection of the
vertical cut plane and the height/color plane
[Figure 5.1.2].
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
Shuffle Byte
H C
H C
H C
H C
H C
H C
H C
Quad Word (128
Figure 5.1.3
SPE Unaligned Quad Word Load
Samples are computed in a SIMD fashion by
searching for four intersections at a time [Figure
5.1.4] and when all four are located they are then
evaluated in parallel by the surface shader. Rays
are packed four at a time into the single precision
floating point channels of each vector register.
All ancillary information need for the shader is
packaged in the same format using additional
vector registers. When an intersection is found
for a ray the channel containing the ray is locked
for all registers participating in the rendering
operations using select instructions.
Ray 1
Ray 2
Ray 3
Ray 4
Vector (128 bits)
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
H C
Quad Word (128
Quad Word (128
Figure 5.1.2
Height Color Data Memory Layout
These 128 bit (quad word) quantities are word
aligned in system memory and therefore can’t be
directly fetched by the SPE’s quad word
optimized DMA engine. To handle this situation
the height/color DMA list is constructed to fetch
256 bits of data starting at the naturally aligned
quad word address of the desired word aligned
128 bit quantity. Once the data has been
gathered into local store, pairs are run through
the shuffle byte engine to reconstruct the desired
128 bit quantity for the shader [Figure 5.1.3].
4
3
2
1
Figure 5.1.4
SIMD Ray-casting
The resulting IBM XLC compiled C code
occupies 29KB of local store and uses 204KB of
buffer space plus 4KB of stack [Figure 5.1.5].
Height/color (HC) DMA lists are implemented in
a destructive fashion where the list is constructed
in the return data buffer and is written over, or
destroyed, as the DMA list is executed and data
is returned to the buffer. The accumulation
buffer operations are read/modify/write so the
DMA lists used to gather/read the data are
preserved and re-executed to scatter/write the
modified data back to the accumulation buffer.
Height Color Data
(57 KB)
Height Color Data
(57 KB)
HC DMA List (13 KB)
HC DMA List (13 KB)
Accumulation Data
(30 KB)
Accumulation Data
(30 KB)
Accum DMA List (15 KB)
Accum DMA List (15 KB)
R
R
AC
Stack 4 KB
Code
(29 KB)
Figure 5.1.5
Ray Kernel Local Store Memory Allocation
6. Image Compression
In addition to the SPEs running the ray-kernels
one SPE is repurposed during the frame time for
image compression. The compression kernel
operates on the finished accumulation buffer
which is organized in a column major 2D array
of single precision floating point (red, green,
blue, count) data, one float per channel (128 bits
per pixel). The count channel contains the
number of samples accumulated in the pixel. The
image compression kernel is responsible for the
following tasks:
•
•
•
Normalization of the accumulation buffer
Compression of the normalized buffer.
Clearing of the accumulation buffer
The compression kernel reads sixteen by sixteen
pixel tiles from the accumulation buffer into
local store using DMA lists. These tiles are then
normalized by dividing the color channels by the
sample count for each pixel. The tile is then
compressed using a multi-stage process
involving color conversion, discrete cosine
transformation (DCT), quantization, and run
length encoding. The resulting compressed data
is then written to a holding buffer in local store
which when full is DMA written back to system
memory for network delivery. As each tile is
processed a tile of zeros is returned to the
accumulation buffer providing the clear
operation.
7. SPE Repurposing
Repurposing is a way to transfer unused cycles
from an idle SPE kernel type to an active kernel
type during a given frame. Each TRE SPE
kernel includes the capability to repurpose itself
to the other kernel type. For example, if a
“repurpose” command is issued to a SPE running
the ray kernel it will finish its current ray kernel
work, load the encoder kernel code, and begin
encoder execution. Any commands behind the
“repurpose” command in the mailbox will be
interpreted as encoder kernel commands. The
repurpose SPE thread command is implemented
as a list of programs passed to the thread upon
creation. When a “repurpose” command is
issued the SPE thread returns execution to a
special SPE crt0 that DMAs in the next programs
code and executes the new main. This provides
a very light weight application controlled SPE
context switch that, in our case, can be issued
multiple times per frame giving us the flexibility
to use any SPE as our encoder. Since the TRE
server dynamically distributes ray-casting work
across all the SPEs based on which SPE finishes
first and which SPE finishes last, the repurposed
SPE gets less work when the encoding load is
larger (high frequency image) and more work
when the encoding load is smaller (low
frequency image). Work rebalancing takes place
after each frame so the work given to the
repurposed SPE is rarely out of balance.
8. TRE Performance
The TRE code base was initially implemented on
Apple G5 systems using SIMD VMX engines.
This provided a clean porting path to the CBE as
both the SPE and the G5’s VMX engine have
similar instruction sets. The SIMD optimization
effort on the G5 resulted in a 3.25x speedup over
the scalar code base showing that we were in fact
computationally bound on the G5.
The CBE PPE is used only as a control processor
in the TRE and therefore has little impact on the
TRE’s overall performance.
The overall
programming goal for the TRE PPE threads was
to not have them touch any of the SPEs
streaming data and provide little if any of the
computational load. Only a basic tuning effort
was therefore expended on this code.
The SPE threads on the other hand were highly
optimized for computational efficiency, data
throughput, and code/data footprint. All of our
performance gains are the direct result of the
heavy lifting but simple SPE processors. The
SPE ray kernel was originally written for the G5
using only a subset of the VMX intrinsics that
mapped directly to the SPE. This allowed us to
verify the algorithms at full speed and then
directly port them to the SPE with minimal effort.
Performance analysis was then performed on the
CBE implementation using our system simulator.
Hot spots were identified and aggressively
optimized using loop unrolling, branch removal
via select operations, immediate field instruction
encodings, code interleaving, and SPE
instruction pipeline rebalancing.
Functional
blocks found not to be performance critical were
squeezed the opposite direction for reduced code
footprint. Since the SPE is a dual issue machine
the theoretical optimum cycles per instruction
(CPI) is 0.5. The optimized ray kernel executes
with a CPI range of 0.7 to 0.8 and occupies only
29KB of local store space.
The volume of scattered data gathered into SPE
local stores created a problem for the SPE
transition look aside buffer (TLB). We found
that with 4KB pages DMAs were bound by TLB
misses as a result of ray kernel DMA lists
accessing very large quantities of pages. All
streaming data was placed in 16MB pages to
alleviate this problem.
Since we wrote an optimized VMX version of
our server for the Apple G5 as part of our
development process we thought it would be
interesting to compare the performance
differences of this rendering task. We didn’t
implement an encoder for the G5 renderer since
it ran as part of our client and therefore had
direct access to the framebuffer.
In our
benchmark the Apple has a distinct advantage
given it only has to render and display the
uncompressed frames. The CBE server, on the
other hand, has to render, compress, and deliver
each frame. Even with this handicap Cell
outperforms the local G5 implementation by a
factor of 50x.
The server has many rendering parameters that
affect performance including:
•
•
•
•
Output image size
Map size
Visibility to full fog/haze
Multi-sampling rate
For benchmarking purposes the following values
were selected:
•
•
•
•
1280x720 (720p) output image size
7455x8005 Map size
2048 map steps to full haze
1.33 x (2 – 8 Dynamic) or ~2-32 samples per pixel
With these settings the following rendered frame
rates were measured:
System / frames per second
2.0 GHz Apple G5 1GB memory (no image encode)
3.2 GHz UP Cell 512MB memory
3.2 GHz 2-way SMP Cell 1GB memory
0.6
30
58
9. Conclusion and Future Work
In this paper, through the TRE system, we have
outlined how a compute intensive graphics
technique, ray-casting, can be decomposed into
data parallel work blocks and executed
efficiently on multiple SIMD cores within one or
multiple Cell Broadband Engines. We have also
shown that by pipelining the work block
preparation, execution, and the delivery of
results, additional parallelism within the CBE
can be exploited. One order of magnitude
performance improvements over similarly
clocked single threaded processors can be
achieved when computational problems are
decomposed and executed in this manner on the
CBE. Graphics techniques once considered
offline tasks can now be executed at interactive
speeds using a commodity processor.
The TRE framework and the CBE present many
avenues for future works:
•
•
•
Embed the computed depth information for
each pixel in the returned framebuffer. By
preloading this depth information into the zbuffer, we can combine the ray-cast scene
with GPU rasterized objects.
Level of Detail rendering.
Interactive modifications of the terrain. This
will enable us to simulate shock waves, add
fluid simulation to the lakes, avalanches to
the snow, and other simulations that require
real-time change in terrain geometry.
References
[1] Cheol-Hi Lee, “A Terrain Rendering Method
Using Vertical Ray Coherence”, The Journal of
Visualization and Computer Animation
[2] Cohen-Or, D., Rich, E. Lerner, U., and
Shenkar, V., “A real-time photo-realistic visual
flythrough,” IEEE® Trans, Vis. Comp. Graph.,
Vol 2, No 3, September 1996.
[3] Blinn, "Simulation of Wrinkled Surfaces",
Computer Graphics, (Proc. Siggraph), Vol. 12,
No. 3, August 1978, pp. 286-292.
[4]
Perlin,
Ken,
"Making
http://www.noisemachine.com/talk1/
noise,"
[5] H. Peter Hofstee, “Power Efficient Processor
Architecture and the Cell Processor”, to appear,
Proceedings 11th Conference on High
Performance Computing Architectures, Feb.
2005.
[6] B. Flachs, S. Asano, S. H. Dhong, H. P.
Hofstee. G. Gervais, R. Kim, T. Le, P. Liu, J.
Leenstra, J. Liberty, B. Michael, H-J. Oh, S. M.
Mueller, O. Takahashi, A. Hatakeyama, Y.
Watanabe, N. Yano. “The Microarchitecture of
the Streaming Processor for a CELL Processor,”
IEEE
International
Solid-State
Circuits
Symposium, Feb. 2005.
[7] T. Asano, T. Nakazato, S. Dhong, A.
Kawasumi, J. Silberman, O. Takahashi, M.
White, H. Yohsihara, “A 4.8GHz Fully Pipelined
Embedded SRAM in the Streaming Processor of
a CELL processor”, IEEE International SolidState Circuits Symposium, Feb. 2005.
[8] D. Pham, S. Asano, M. Bolliger, M. N. Day,
H. P. Hofstee, C. Johns, J. Kahle, A. Kameyama,
J. Keaty, Y. Masubuchi, M. Riley, D. Shippy, D.
Stasiak, M. Suzuoki, M. Wang, J. Warnock, S.
Weitzel, D. Wendel, T. Yamazaki, K. Yazawa,
“The Design and Implementation of a FirstGeneration
CELL
Processor,”
IEEE
International Solid-State Circuits Symposium,
Feb. 2005.
© IBM Corporation 2005
IBM Corporation
Systems and Technology Group
Route 100
Somers, New York 10589
Produced in the United States of America
May 2005
All Rights Reserved
This document was developed for products and/or services
offered in the United States. IBM may not offer the products,
features, or services discussed in this document in other
countries.
The information may be subject to change without notice.
Consult your local IBM business contact for information on
the products, features and services available in your area.
All statements regarding IBM future directions and intent are
subject to change or withdrawal without notice and represent
goals and objectives only.
IBM, the IBM logo, Power Architecture, are trademarks or
registered trademarks of International Business Machines
Corporation in the United States or other countries or both.
A full list of U.S. trademarks owned by IBM may be found
at:
http://www.ibm.com/legal/copytrade.shtml.
IEEE and IEEE 802 are registered trademarks in the United
States, owned by the Institute of Electrical and Electronics
Engineers. Other company, product, and service names may
be trademarks or service marks of others.
Photographs show engineering and design models. Changes
may be incorporated in production models. Copying or
downloading the images contained in this document is
expressly prohibited without the written consent of IBM
All performance information was determined in a controlled
environment. Actual results may vary. Performance
information is provided “AS IS” and no warranties or
guarantees are expressed or implied by IBM
THE INFORMATION CONTAINED IN THIS
DOCUMENT IS PROVIDED ON AN "AS IS" BASIS. In no
event will IBM be liable for damages arising directly or
indirectly from any use of the information contained in this
document.