[MUSIC PLAYING]
Hello.
I'm [INAUDIBLE],, IBM Resources division's vice president
of systems and software.
I would like to talk to you about the Power Visualization
System and its associated software, Data Explorer.
What I really would like to discuss with you
is what we had in mind--
invention, discovering, human problem-solving.
These are unique human capabilities, highly prized,
yet fairly not well understood.
Over the next decade, the amount of computing power
that we will get from better microprocessors, larger
memories, will increase the amount of computing power
that we can dedicate to both simulation and visualization,
and really change qualitatively the way we solve problems
with computers, in a sense, amplify our own capabilities;
amplify, if you would like to think about it this way,
our intelligence.
The cycle of problem-solving involves iteration.
We try out an idea and like to see
it result in a way that is intuitively appealing
and then try something else.
The time it takes to go through this cycle
is of great importance to determine
whether this is a useful paradigm,
and indeed, will accelerate our problem-solving.
Man has an uncanny ability to detect the most minute path
in an image, and see, gain insight,
where a computer could not find it
after billions of calculations.
So this paradigm really takes what we can do best--
detect patterns, see connections,
and connect it with the ability of the computer to crunch
through numbers at increasingly faster and faster speeds.
Armando Garcia will be describing to you
the system in great detail.
I would like to simply say that the initial set of applications
that we have found indeed demonstrate that I
think we're on the right track.
And it's very hard to tell what the human mind can
do and amplify it with such computational power
and capabilities.
But I am confident it will be nothing short of spectacular.
Hello, I'm Armando Garcia.
I'd like to tell you about the IBM Power Visualization System
and Data Explorer, two innovative products that
were conceived at IBM Research and brought to the marketplace
in under two years.
Let me first give you an outline of my talk.
First, I will cover general visualizations concepts,
as well as our unique approach to this problem.
Second, I will describe the hardware components
of the power visualization system
and our rationale for their unique design.
Third, we'll see some actual application examples that
have been computed on the PVS.
And finally, I'll summarize where visualization is today,
and where we at IBM envision it will be in the future.
So what do we mean by visualization?
Well, think of visualization as a means of analysis.
It allows us to study data from complex computer simulations
or from observational experiments
in a simple visual way.
For example, a chemist can interactively
study the molecular structures of a drug
and how it may interact with other molecules.
Petroleum geophysicists can graphically
see the result of oil and natural gas exploration
experiments.
For these experiments cubes of raw data
are gathered from seismic observations
and then analyzed using visualization techniques
to precisely locate oil and natural gas deposits.
By analyzing atmospheric observations gathered
from satellites, climatologists can visually
study the depletion of the Earth's ozone layer
over many years.
Visualization is also a means of extracting knowledge
from complex data.
It gives us the ability to ask "what if" kinds of questions,
to understand data in a visual way.
It makes use of the human visual system, its enormous capability
to absorb and comprehend complex data in a pictorial form.
For example, this visualization of the airflow over an F-15
wing clearly illustrates where the pressure of the wing
is greatest.
Rendering this data is important,
but realization is where the important discoveries
can be found.
Through the use of isosurfaces, streamlines, and streak lines,
this airplane wing can be designed
and tested over and over without the cost
of building a physical model.
Visualization is also a way of synthesizing data.
Take, for example, this photorealistic rendering
of an automobile in a virtual showroom as shown here
on the monitor.
This image sequence was rendered on PVS
using the alias parallel ray tracer frame by frame,
and is being played back in real time from disk.
Furthermore, visualization is being used extensively
in special effects for television commercials,
theatrical films, and even theme parks.
I'm sure you have seen movies like Terminator 2 or Batman
Returns and so forth, which have used extensive special effects
or visualizations.
The PVS was conceived to offer a new solution
to the interactive visualization process
and to leapfrog beyond the capabilities of today's
approaches.
Typical systems used for visualization
include workstations and supercomputers,
each having certain advantages and disadvantages.
Workstations are inexpensive, and therefore,
accessible to many people.
They provide interactivity, but obviously lack
processing power.
They can only handle small data sets
because of their limited memory, the storage and bandwidth.
And they are limited to simple visualization techniques, given
their hardware-based rendering capabilities.
Supercomputers, on the other hand,
are very expensive, and therefore
available to few people.
They are usually not interactive, what we refer to
as batch visualization.
However, they can support large problems
because they have the processing power and I/O capability
needed, and they can utilize complex visualization
techniques.
However, they usually tend to be application-specific.
The Power Visualization System represents
an innovative approach to interactive visualization.
We wanted PVS to feel like a workstation
by providing the interactivity and
the user-friendly environment.
We also wanted PVS to feel like a supercomputer,
to be able to handle the very large problems
and to be a cost-effective, integrated solution.
We also wanted to provide a general purpose visualization
tool that would be easy to use, flexible, and extensible,
so users across a wide variety of application areas
would be able to use the system.
To build this innovative system, we
assembled an entrepreneurial group at IBM Research.
The group was made up of researchers, developers,
marketing, and business operations people.
We were only one location isolated from the rest of IBM.
So in effect, we were like a small company
trying to bring our product to the marketplace
in a short period of time.
The result was the IBM Power Visualization
System and Data Explorer.
My talk will concentrate on the Power Visualization System.
A separate tape is available from IBM
which describes Data Explorer.
Let me now show you a few visualization examples
generated on our system.
Seen here is a visualization of the ozone
density over the Earth depicted as a pseudo-colored map image.
This data was collected by a NASA satellite
and is shown in conjunction with a coastline
map of the continents with some political boundaries.
Low ozone density values are represented in blue,
while medium density values are represented in green.
We now show you a morphing example
in which we take this raw static data set,
apply a Cartesian to spherical transformation,
and use several redundant techniques, including
color, opacity, and height to visualize the ozone density.
Low ozone concentrations are now depicted
as blue, transparent regions close to the Earth.
We have also included a detailed topographical map
of the Earth, which better illustrates
the registration of the ozone density data
with our world map.
This more advanced technique can aid a scientist
in identifying geographic regions of interest
during specific periods of time for detailed analysis.
This visualization was performed using
Data Explorer on the Power Visualization System
and stored as an animation sequence on the disk array.
You are seeing the animation sequence being played back
from disk in real time.
Let's now look at a more complex,
time-dependent visualization of the daily evolution
of the ozone density over the Earth through a 13-year period.
The raw data set for this visualization
is over 900 megabytes in size.
Later in the talk, you will see additional visualization
examples run interactively on the Power Visualization
System using the same data set.
Let's now take a look at the Power Visualization System.
First, I'll briefly introduce you
to the three main components, followed
by a technical discussion on the architecture and design
of the visualization server.
The system is comprised of three main components.
At the heart of the system is the visualization server,
which provides the computational and visualization
functions of the system.
It is a parallel processor with up to 32 general purpose
CPUs, up to 2 and 1/2 gigabytes of memory,
and high speed I/O channels to communicate
with high-speed devices.
It uses ANSI standard high-performance parallel
interface channels, also known as HIPPI channels,
to communicate with these various devices.
Let me now tell you about the disk array.
The server attaches to a disk subsystem
which provides high-speed data storage for the raw input
data and the resulting visualization images.
This particular device uses 16 standard 5 and 1/4 inch hard
disk drives, providing a sustained data transfer rate
of 55% megabytes per second.
It is expandable from 21 gigabytes to 180 gigabytes
by simply adding boxes.
It also has a parity drive for error recovery and a hot spare
in the event that you lose a drive.
The last major hardware component
is the video controller.
It attaches to an R/6000 workstation
and supports dynamic display of the resulting images
from the visualization server.
It uses two distinct frame buffers, an 8-bit buffer
to support X-Windows and Motif, and a double buffer,
24-bit per pixel image buffer, to support
dynamic display of the images.
Through the HIPPI channel, we can transfer 25 million RGB
pixels per second from the server to the video controller.
With this capability, we can display images
at a resolution of 1280 by 1024 at 20 frames a second, or HDTV
resolution images, which are 1920 by 1024
at 12 frames per second, the limitation being the HIPPI
channel running at 100 megabytes a second.
We also implemented a block truncation code compression
scheme, which is implemented in software on the visualization
server, and in hardware the decompression being done
in hardware in the video controller,
thus boosting the transfer rate from 25 million to 200
million RGB pixels a second.
With this capability, we can display full color HDTV movie
sequences in real time.
In addition, the video controller
can also support very high-quality stereoscopic
display using conventional monitors or projectors
at a rate of 120 hertz.
Think of PVS as an integrated system,
which offers computational and visualization services
to a network of clients.
The visualization server imports data from the high-speed disk
array, performs a visualization on these data,
and then displays the resulting images
at the user workstation on their X-Windows
and Motif using a client server model.
I should point out the data can be imported
either from the high-speed disk array, from the R/6000 support
processor, or from anywhere on the network using standard NFS
facilities.
Similarly, the resulting visualization images
generated on the server can be transferred via HIPPI channel
to an R/6000 attached video controller, or through
a standard Unix socket to any workstation on the network,
albeit a lot slower.
The video controller also supports a HIPPI daisy chain
network, which handles up 32 workstations per HIPPI channel,
and the server can address a single workstation or multicast
to a collection of workstations.
In architecting the visualization server,
we had a number of important characteristics
which we felt were critical to a well-balanced integrated
system.
By balance, I mean the integration
of high-performance processing capabilities, memory capacity,
and I/O bandwidth, as well as internal bandwidth.
Next was the idea of making the visualization
process completely programmable without using
any special purpose hardware for rendering.
The reason for this is simple.
Visualization is much more than simply rendering images.
The realization component can be quite complex
and requires a diverse collection
of techniques which are not easily mapped to hardware.
Another reason was to support advanced rendering techniques,
such as transparency, direct volume rendering,
or ray tracing.
This last capability truly differentiates
the Power Visualization System and Data Explorer
from other traditional approaches
by allowing us to combine different rendering
techniques in the same image.
As for the choice of the processing element,
we decided to use an off-the-shelf risk
microprocessor rather than implementing our own CPU.
We chose an Intel i860 because of its excellent integer
and floating point performance, and high-level language
support using standard C and Fortran compilers.
In addition, it meant that we could ride the technology curve
and evolve the product to use the next best
available microprocessor, including
our own PowerPC microprocessor.
Another architectural decision was to use parallelism.
One simple reason for this was that visualization is well
suited for parallelization, and would therefore
yield more effective processing speed versus using a vector
processing approach.
It was also felt that moderate parallelism would
be manageable in terms of the software and the system design.
We chose to implement a simple shared memory model, which
offers an effective way of supporting
low latency and fast communication
between processors.
It also offers a cost-effective solution
by providing large global memory, therefore,
handling large visualization problems
and coupling high-speed I/O from the disk to the display.
Finally, we chose to implement a hierarchical memory
architecture as an effective way of providing
low-latency and high bandwidth communication
amongst a moderate number of processors.
Each processor contains a small on-chip cache
for instructions and data.
Local memory private [INAUDIBLE] processor
is used to hold code and private data, such as the stack
and non-shared data.
This offloads the global buzz from such traffic.
Global memory is accessible to all processors.
An alternative would have been to use
a large second-level cache, but we decided against it
for two reasons.
First, there was no mechanism for maintaining consistency
between the on-chip cache and a second-level cache,
given the chosen microprocessor.
And second, maintaining consistency
across multiple caches, say, 32, was not
thought to be an effective solution.
Finally, the use of local memory within each processor
and shared memory between the processors
meant that we could very effectively
support other programming paradigms, such as message
passing.
One of our design challenges was to design a global bus that
would provide low-latency and high bandwidth
communication between a number of processors
in a global memory subsystem.
We also wanted the system to run on a single 40-megahertz clock
or above.
The technical difficulty was that traditional shared bus
systems limit the number of bus loads to less than 20,
as limited by the low current effects
and the capacitive effects.
In our case, we wanted to support up to 32 processors,
all accessing a common global memory, in addition to
high-speed I/O channels all operating at 40 megahertz.
Our solution was to use a two-level shared bus structure
with four nodes on each card sharing a global bus interface,
and to implement a common global bus
interface to couple the four nodes to the global bus.
Let me now show you the architecture
of the visualization server.
It is a scalable system containing up to 32 processors,
a multi-bank global memory subsystem providing up
to 2 gigabytes of storage, an I/O subsystem providing up
to six full duplex HIPPI channels,
each capable of sustaining up to 100 megabits per second of I/O.
And finally, a host interface card
that connects the server to a RISC System/6000
workstation, which serves as its support processor.
Connecting all the components is a 1.28 gigabyte
per second global bus operating at 40 megahertz.
Shown here is the back plane of the visualization server
which implements the global bus.
Operating at 40 megahertz, it can sustain a data transfer
rate of 1.28 gigabytes per second
using a 256-bit wide data bus.
It supports up to 14 cards, and it's
implemented as a controlled and impedance transmission
line with termination at both ends of the bus.
The bus interface logic is implemented
using 100K ECL technology, which has the necessary speed
and drive characteristics.
The global bus uses a synchronous decoupled protocol
to support multiple outstanding processor requests.
Read requests are tagged with a processor identifier, which
is returned along with the memory reply cycle
to resolve its destination.
Global bus arbitration is implemented
using a centralized, two-level, round-robin arbitration scheme.
Separate arbitration is provided for the address and data buses
in order to optimize the use of the global bus.
Thus, for example, a processor read request and a memory reply
can share the same global bus cycle, given
that the processor simply needs the address bus,
while the memory only needs the data bus.
Shown here is the global bus arbiter card
which also provides clock distribution to all the logic
cards in the system.
To support interfacing to the available bus,
we architected a generic global bus interface,
which is used in all the cards in the system.
This interface deals with a global bus protocol
and provides a buffered interface between the shared
on-card bus with four local nodes and the high speed
global bus.
For each of the four local nodes,
it provides an 8 entry FIFO to buffer read and write requests,
and another 8 entry FIFO to buffer memory replies.
This buffering helps us support high bandwidth
throughout the system and to optimize the utilization
of the global bus.
Having shown you the back plane, let me now show you
the three main logic cards and the visualization server.
On screen right is the 4-node processor card.
On screen left is the I/O processor card with four HIPPI
channels, and in the middle is the global memory card.
One card not shown is the host interface card.
Let me first point out the common global bus interface
section, which is essentially identical in all four card
types.
There are three main sections--
an address and control ASIC, 8 32-bit data path ASICs,
and registered transceivers providing level translation
from the TTL on-card bus to the ECL global bus.
As you can see, these cards are quite big.
They're 20 inches by 23 inches by 113 mils thick.
They have 10 signal layers and six power plane layers,
and they hold roughly 2,500 components--
500 active components and 2,000 passive components
comprised of capacitors and bus termination resistors.
We use a variety of through-hole components and surface
components, and there are over 35,000 holes
on each one of these cards.
Now let's take a look at the processor card architecture.
It contains four identical nodes and a shared global bus
interface.
Each node contains a risk microprocessor
with 16 megabytes of local memory
and a buffered interface to global memory.
This interface contains a 32-byte read buffer,
which reduces global memory read latency,
and performs bus width matching between the 64-bit processor
bus and the 256-bit global bus.
Global bus snooping is used to maintain buffer consistency.
Similarly, a 32-byte write buffer reduces global bus
traffic by caching up to 32 contiguous bytes,
each validated by its corresponding byte enable.
These byte enables are used to validate
the update in global memory when the right buffer is flushed.
The block labeled PBIF in the diagram
is a custom ASIC which supports a global memory
interface and the local memory.
To support a coherent shared memory architecture,
the on-chip processor cash is enabled for local memory pages
and disabled for global memory pages.
Thus, the average read latency for a 64-bit load instruction
is one cycle from the on-chip cache,
three cycles from the local memory,
and eight cycles from the global memory.
The global memory subsystem consists
of four cards, each with four independent global memory
banks.
The memory banks are interleaved across the global memory
[INAUDIBLE] space using a selectable memory stride
feature.
Each memory card contains 128, 256,
or 512 megabytes of storage plus 8 bits
of ECC for each 32-bit word, providing a single-bit error
correction and double-bit error detection.
A minimum of two memory cards are
needed to support the 1.28 gigabyte per second bandwidth
capability of the global bus.
To support atomic synchronization between
processors, we implemented a read-lock/write-unlock
mechanism, which allows a processor to atomically lock
out any location in global memory from all other
processors until unlocked by that same processor.
Using this simple hardware primitive,
we have implemented higher level atomic functions,
such as fetch-and-add in software.
While interleaved memory banks provide an effective way
of providing low latency access to many processors making
single read and write requests, we also
needed a mechanism to support multiple hundred megabyte
per second I/O channels.
To do this we implemented a fast, block DMA read feature
in the global memory, which supports
the transfer of contiguous blocks of data
with a single block read request.
This design approach resulted in a well-balanced design,
providing low latency and high bandwidth
communication with a large global memory subsystem.
And finally, to support high-speed I/O devices,
we implemented a unique audio processor card
with four high-speed HIPPI channels.
Each I/O processor card contains two HIPPI transmitters and two
HIPPI receivers, each capable of transferring
100 megabytes per second.
A dedicated processor node identical to those
on the processor cards provides high-level control
of the four HIPPI channels.
It runs the I/O device drivers and communicates
through global memory with client processes
using remote procedure calls.
I should mention that even with all four channels running
simultaneously, we have measured sustained data transfer
rates in excess of 320 megabytes per second
from an application running on the visualization server.
Having described the hardware, let me briefly describe the PVS
operating system.
The approach we took was to implement a low-level kernel,
which provides standard Unix functions, such as process
scheduling, virtual memory protection, and standard I/O
services, but without the traditional multi-user
multitasking implementation techniques, which would not
be effective for real-time applications.
Thus, the kernel does not support demand paging.
Everything must fit in local memory and global memory.
There is no task switching.
Multiple users or tasks are supported through partitioning,
whereby, a process is giving a chunk of processors and memory
which remain static for the duration of the task.
We chose to support up to eight simultaneous user tasks,
given this would still yield effective performance
for each user.
The application interface consists of standard Unix
libraries, including libc, libm, and libX, with multiprocessor
extensions to support shared memory and processor
synchronization.
In addition, a high-speed I/O library
is provided to support the high-speed disk array subsystem
and frame buffer, including support for a partition file
system and movie utilities, which allows an application
to deal with movie sequences on the disk array in a simple way.
Let me conclude the PVS technical summary
by showing you some performance numbers.
First, let me talk about theoretical peak performance
numbers for the 32-processor server.
At 40 megahertz, each i860 processor
is capable of delivering 40 MIPS and 80
megaflops single precision.
Thus, with simple arithmetic, we can
get a peak performance of 1,280 MIPS
and 2 and 1/2 gigaflops single precision.
Now, for some benchmarks.
LINPACK TPP with a problem size of 6,000 by 6,000 yields
925 megaflops on a 32-processor server.
A fast Fourier transform on a 512 by 512 RGB color image
sequence yields 10 frames per second throughput from disk
to display.
This corresponds to an actual throughput computation
exceeding 700 megaflops.
And finally, affine transformations
with rotate scale and translate on a 512
by 512 RGB color image sequence achieves
a throughput of 12 frames per second from disk to display.
At this point, I have concluded the technical overview
of the Power Visualization System.
I would like to now give you a brief introduction
to Data Explorer, followed by some demonstrations on the PVS.
Data Explorer is a fully integrated visualization tool
which can deal with data from a variety of application domains.
It uses a visual programming approach
to define a visualization program or network that
imports raw data, performs a series of realization functions
on these data, and finally, renders the resulting images.
The tool contains nearly 100 visualization modules
and uses an object-oriented data model
to represent data internally.
Modules are written generically to deal with various data
types, and they query the data model
to figure out what to do with the input data provided.
For example, an isosurface module
will compute contour lines given to the data,
or an isosurface given 3D data.
Unlike many other visualization packages,
Data Explorer is truly domain-independent.
Finally, Data Explorer uses a client server model
to support visualization.
First of all, it runs standalone at workstations,
such as the IBM RS/6000.
Second, the user interface can run on one workstation
while the server runs on another workstation.
And finally, the server component
can also run on the Power Visualization System,
thus providing the ability to handle very large data sets
and to realize complex visualization techniques.
I would now like to introduce Lloyd Trenish, who
is a research staff member in the group specializing
in a number of Earth science problems.
I'd like to talk to you about a problem of scientific interest,
or at least of great interest to me,
and that is one of ozone depletion in the Earth's
upper atmosphere.
I've been using the IBM Data Explorer
software on the IBM Power Visualization System
to study that problem.
What I'm showing here is the total column ozone,
as measured from a NASA spacecraft,
and it's being shown as a spherical shell that's
color- and opacity-mapped, as well as radially deformed,
all redundantly to show ozone.
So the idea is that low ozone values appear thin and closer
to the Earth, and higher ozone values,
such as this ridge region here, appears as further away
from the Earth and thicker.
The visualization Data Explorer is really--
is implemented to be able to examine very large data
problems.
In this case, I'm dealing with about a gigabyte's worth
of data that exists on the server.
And I can interactively browse and manipulate the data
to study it in more detail.
So let me show you some of the features of this software,
and all of the images that you're seeing
are being computed as I'm talking
in near real time on the server.
So if I'm interested in studying,
let's say, this region where we're looking at the ozone
depletion, and this is during the spring,
the Antarctic spring October in 1987.
I've taken a profile along this line
to take a look at the structure of the polar vortex,
this circulation phenomenon that you're seeing here.
And the structure is very pronounced,
and we see the depletion region.
If I'm now interested in studying that in more detail,
I've been able to implement through the Data Explorer
a number of tools to allow me to try different techniques
to literally apply a "what if" kind of notion
towards examining data sets such as this.
So now I'm only looking at the southern hemisphere,
and I can see the structure of the depletion region
and the circulation of the polar vortex around the South Pole.
What would be of interest is that we
know the depletion occurs in the late '80s
and still occurs today.
What did it look like before the ozone hole was discovered,
let's say, in the early '80s?
Right now, I'm telling the Data Explorer through this interface
that I've built with the tools that it provides that I now
want to look at 1983.
So interactively, I've gone out and I've grabbed
another year's worth of data.
And I'm immediately creating the same kind of visualization
that I looked at for 1987.
And I can do an easy comparison visually in this fashion.
We can see a similar structure associated
with the polar vortex, but a much less pronounced depletion
region.
Now traditionally, a workstation couldn't
allow me to interactively manipulate a gigabyte data set.
But the visualization Data Explorer software and the Power
Visualization System have really been
designed to scale to these types of data sets,
to deal with complexity, including, for example,
missing data.
After all, these are real data.
These are observations.
And also in order to gain the performance that's
required to manipulate these data quickly,
to perform the kinds of transformations
and rendering to take advantage of the parallel architecture
in the shared memory of the PVS.
The capabilities of Data Explorer
have allowed me to combine these different observational data
sets.
I've been interested in studying the problem of ozone depletion
and how it relates to the dynamics of the Earth's
upper atmosphere.
But until I could really use the Power Visualization
System to combine these data sets and work with
them interactively was I able to determine
that there may be a relationship between
upper tropospheric dynamics and the stratospheric ozone
depletion.
And this kind of capability, this horsepower
to interactively pose a problem and look
at a potential correlation, has been
very exciting, very gratifying to me as a scientist.
I hope you've enjoyed these demonstrations and introduction
to the IBM Power Visualization System and Data Explorer.
We believe the PVS and Data Explorer
offer an innovative solution to interactive visualization.
Together, they pave the way to a new paradigm
in technical computing--
the ability to interact with a computer simulation,
while simultaneously visualizing the results.
I would like to thank all the individuals that contributed
to the success of this project.
We learned that when you bring together
a team of highly motivated and diversified people
and allow them to be creative, the sky is the limit.
Thank you.
Outstanding.
Yeah, that was great.
Good.
[MUSIC PLAYING]