Download Workstation graphics capabilities for the 1990's and Zyda, Michael J.

Calhoun: The NPS Institutional Archive
Reports and Technical Reports
All Technical Reports Collection
1985-09
Workstation graphics capabilities for the 1990's and
beyond / [by] Michael J. Zyda.
Zyda, Michael J.
Monterey, California. Naval Postgraduate School
http://hdl.handle.net/10945/26340
NPS52-85-012
NAVAL POSTGRADUATE SCHOOL
Monterey, California
WORKSTATION GRAPHICS CAPABILITIES FOR THE 1990'S AND
BEYOND
MICHAEL J. ZYDA
SEPT 1985
Approved for public release; distribution unlimited
Prepared for:
f
FEDDOCS
D 208.14/2
NPS-52-85-012
of Naval Research
va
npt-on
g
'
,
NAVAL POSTGRADUATE SCHOOL
Monterey, California
Hear AHmirul K.H. Slmmakcr
Superintendent
A
Srhrariv
Provost*
The work reported herein was supported by in part
by the Foundation Research
Program of the Naval Postgraduate School with funds provided by the Chief of Nava
Research.
Reproduction of all or part of this report is authorized.
This report was prepared by:
s
—
-
UNCLASSIFIED
_______
.
SECURITY CLASSIFICATION OF THIS PAGE
ft»7i»n
Data Entered)
READ INSTRUCTORS
BEFORE COMPLETING FORM
FQSM
REPORT DOCUMENTATION PAGE
REPORT NUMBER
I.
2.
GOVT ACCESSION NO
3-
RECIPIENT'S CATALOG NUMBER
5.
TYPE OF REPORT
6.
PERFORMING ORG. REPORT NUMBER
•
CONTRACT OR GRANT NUMBER(t)
.
NPS52-85-012
TITLE (and
*.
Subtitle)
ft
PERIOD COVERED
WORKSTATION GRAPHICS CAPABILITIES FOR THE 1990'
AND BEYOND
AUTHORfiJ
7.
Michael J. Zyda
PERFORMING ORGANIZATION NAME AND ADDRESS
9.
PROGRAM ELEMENT. PROJECT, TASK
AREA WORK UNIT NUMBERS
10.
ft
Naval Postgraduate School
Monterey, CA 93943-5100
61152N: KR000-01-NP
N0001485WR41005
CONTROLLING OFFICE NAME AND ADDRESS
II
12.
Sept 1985
Chief of Naval Research
Arlington, VA 22217
14
MONITORING AGENCY NAME
13.
NUMBER OF PAGES
15.
SECURITY CLASS,
Jl5_
ft
ADDRESSf/f
dlllerent Irom Controlling Olllce)
15a.
16
DISTRIBUTION STATEMENT
REPORT DATE
(ol thle report)
DEC LASSIFI CATION /DOWN GRADING
SCHEDULE
(ol this Report)
Approved for public release; distribution unlimited
17.
DISTRIBUTION STATEMENT
18.
SUPPLEMENTARY NOTES
19.
KEY WORDS
(ol the abetract entered In
(Coniinu* on reverie elde
Block
20, II different Irom Report)
neceeeary and Identity by block number)
II
Algorithms, architecture, contour surface display generation, real-time display
generation, graphics workstations
20.
ABSTRACT
(Continue on reverae elde
II
neceeeary and Identity by block number)
We present in this paper a look at the future graphics capabilities of the
workstation. We begin by examining the cyccles of special hardware development
We show how the current
that have occurred for graphics systems in general.
to applications user
response
direct
is
a
workstation
evolution of the graphics
and hardware
software
The
systems.
graphics
desires for higher performance,
the workfor
operations
graphics
levels that perform the input and output
capabigraphics
future
station are described with an eye towards categorizing
DD
i
jan
73
1473
EDITION OF
S
I
NOV
65
IS
N 0192- LF-014-6601
OBSOLETE
UNCLASSIFIED
SECURITY CLASSIFICATION OF THIS PAGE (Whan Dmlm
Kntared)
IINPT
ASSTFTFD
SECURITY CLASSIFICATION OF THIS PAGE
<TH»«n
Dmtm Eni*t*d)
lities.
The implementation of those levels in the Silicon Graphics, Inc.
IRIS is cited as an example of the leading edge for graphics capabilities in
Current research leading to future enhancements of the graphics
a workstation.
workstation is presented as a continuation of the historical response to
applications user desires for ever higher performance, interactive systems.
S-N 0102- LF-014-6601
SECURITY CLASSIFICATION OF THIS PAGEfWhtt Dmtm Bnffd)
Workstation Graphics Capabilities
Beyond
Michael
J.
for the 1990's
and
|
Zyda
Naval Postgraduate School,
Code
52, Dept. of
Computer
Science,
Monterey, California 93943
ABSTRACT
We
present
workstation.
We
in
this
paper a look
at the future
that have occurred for graphics systems in general.
evolution of the graphics workstation
is
We
show how the current
a direct response to applications user
desires for higher performance, graphics systems.
els
graphics capabilities of the
begin by examining the cycles of special hardware development
The software and hardware
lev-
that perform the input and output graphics operations for the workstation are
an eye towards categorizing future graphics capabilities. The
implementation of those levels in the Silicon Graphics, Inc. IRIS is cited as an
example of the leading edge for graphics capabilities in a workstation. Current
described with
research leading to future enhancements of the graphics workstation
is
presented
as a continuation of the historical response to applications user desires for ever
higher performance, interactive systems.
Categories and Subject Descriptors:
1.3.1
[Hardware Architecture]:
architec-
VLSI implementations; 1.3.2 [Graphics Systems]:
multiprocessing systems; 1.3.3 [Picture/Image Generation]: surface visualization: 1.3.6 [Methodology and Techniques]: contouring, interactive systems,
parallel processing; 1.3.7 [Three- Dimensional Graphics and Realism]: line
tures,
parallel
processing.
drawings, line generation algorithms, real-time graphics, surface plotting, surface
visualization, surfaces: 1.3.m [Miscellaneous]:
VLSI;
General Terms: Algorithms, architecture;
Additional Key Words and Phrases: contour surface display generation, real-time
display generation, graphics workstations;
t This
at
work has been supported by the
NPS
Foundation Research Program. The work was originally presented
an Institute for Graphic Communication conference on Engineering Workstations, the 3rd of February 1985.
-
1.
-
2
Introduction
Graphics workstations represent the culmination of a long history of hardware developments
for purposes of real-time,
provide the
trol
human
demands
idea behind such systems
situations,
and other time-critical applications.
Historically,
to
the future capabilities of such systems,
we must examine the
In order to
It
effort
to
understand
cycles of hardware development.
days of computer graphics, applications users were happy
a picture to the display device.
the
a push-and-pull cycle of increasing applications
driving special hardware additions to the graphics system.
In the early
is
Such capabilities are an integral part of visual training simulators,
improve the capabilities of such systems has been
user
The
user immediate feedback of visual information in response to any physical con-
manipulations made.
command/control
interactive applications systems.
if
they could just get
did not to matter that the display device took
two to three
minutes for one picture as the alternative was to not be able to get the particular application
done.
In
those early days, the computer was generally a single user system, with the graphics
applications program consuming
tive
all
systems was that there was a
sequently, one of the
picture delivery.
first
available resources.
lot of idle user
The key problem with
respect to interac-
time during the waits for the next display.
Con-
problems that was solved with special hardware was the speeding up of
This can be considered the
first
cycle of special hardware for the graphics sys-
tem.
Applications users readily took to computer graphics once they saw that they could get their
picture to the display device in a reasonable
computer graphics with such
a
amount
of time.
fervor that they began
In fact, applications users took to
demanding what
to
them seemed
like the
next logical development, the addition of matrix multipliers for the real-time operations necessary
for rotating, scaling,
and translating vectors. This was the second cycle of special hardware addi-
tions to the graphics system.
This addition to the display system was quite important
in
that
it
allowed the development of real-time interactive applications not previously possible without the
special hardware.
(One example of
this has
been the near abandonment
of the use of hard models of large molecules for the
in
the field of chemistry
more readily manipulated computer models).
DUDLEY KNOX LIBRARY
NAVAL POSTGRADUATE SCHOOL
MONTEREY CA 93943-5101
3
Anyone who has
spent any
amount
The addition
they are never completely satisfied.
came towards
knows quite
of time with applications users
of the special
hardware
matrix multipliers
for
the end of the cycle of single user minicomputer systems.
well that
Applications program-
mers momentarily got used to the immediate response of the single user computer graphics
This capability was
tem, and then almost immediately lost that capability.
fact that the applications users
The
was
is
response to that
tion functionalities
tem.
The
move
to
third cycle of
improvements to the graphics system
typified by the offloading of the graphics
and interac-
from the host computer to a special processor dedicated to the graphics sys-
goal behind this
the
This cycle
loss.
due to the simple
outgrew the single user minicomputer systems, and moved onto
the larger, shared super-minicomputers.
in
lost
sys-
was
to reclaim the real-time, interactive capabilities lost during the
This cycle created the modern interactive graphics
shared super-minicomputer.
workstation.
2.
Interactive Graphics Workstation Organization
Current high performance graphics workstations have some variant of the organization depicted in Figure
In that figure,
1.
we
see a central bus, typically the
hang the CPU, the terminals, the disk
output devices.
On
IEEE
drives, the Ethernet interfaces,
the other side of the
CPU, we
Multibus, off of which
and the other miscellaneous
see a bus going to a unit labeled
DPU,
or
display processing unit, with that bus passing through and towards the actual display device, or
display surface.
Connected to the
DPU
are an array of interactive devices,
joysticks, dials, buttons, switches, data tablets, light pens,
study,
we
are primarily interested in the part of Figure
With
respect
to high
operations with which
gram
we
is
devices,
For
this
there are
two
directly concerned with graphics.
1,
are concerned: (1) Getting tht Picturf There (from the applications pro-
to the display surface),
There,
mouse
and perhaps, a keyboard.
performance graphics, and the top half of Figure
and (2) Manipulating
interactive devices such that a picture change
ture
1
i.e.
is
the Picture (by
generated).
most often termed the "output" function
in
means that we use some mathematical description encoded
The
way
first
of
some movement
operation, Getting the Pic-
the field of computer graphics.
in
of the
the applications
program
This
to put a
Display
Terms
Disks
Interactive
Devices
Mouse Devices
Joysticks
Dials
Buttons
Switches
Data Tablets
Light Pens
Keyboard
Output
Devices
Jthernet
Figure 1
Basic Block Diagram of a Typical Interactive Graphics Workstation
Applic
Graphics
Device
Program
Package
Driver To
DPU
(Software)
(Software)
(Lqw Level
Software)
Figure 2
Software for the Output Function
Applic
Data
Struct
Graphics
Data.
Struct
Device
Driver
Data
i
i
I
i
Applic
Graphics
Device
Program
Package
Driver To
DPU
Subroutine
Calls
Opcodes
Data
Figure 3
A Look at the Applications Program
-
4
visual display, or output, on the display surface.
tion,
we need
-
understand the output func-
In order to properly
examine both the software and the hardware currently used to perform that func-
to
tion.
Software
2.1.
A
ure
for the
sketch of the levels of software involved in performing the output function
we
In that figure,
2.
Output Function
see an applications
program (software) making
calls to
seen in Fig-
is
a graphics pack-
age (software), with those calls being converted into calls to a device driver (low level software).
Beyond
directed to
DPU's hardware.
the
The
gram
is
applications program
the set of
is
the start of the
design program, thai
is
it
applications program
This means that
the set of instructions that
makes
calls
to
the
Part of this transformation step
The
driver expects.
by the
DPU. The
to the
DPU. The
applications pro-
is
to
next step
the applications program
knows about
is
a
VLSI
transistors, registers, etc..
(Figure
The
3).
The
graphics package
and passes the transformed data onto the
it,
putting the data into an opcode format the dev-
pathway
final operations in the software
The device
the device driver.
if
graphics package
makes some transformations on the data passed
device driver.
pathway
computer instructions that maintain the abstract mathematical description, or
model, of the applications user's world.
ice
commands
the device driver are even lower level software calls, or perhaps,
to the
DPU
are performed by
driver converts the data received into the opcode streams required
in
the output function
is
a
hardware
step.
the
i.e.
DPI
's
conversion
of that stream into a form that can be sent to the display.
Hardware
2.2.
for the
Once we have
tion,
we then need
within the
the
DPU
a
Output Function
rough idea of the software pathway necessary to perform the output func-
to look at the
(Figure
pathway from the
4).
refresh
hardware pathway.
The only
The hardware pathway
part of the hardware
pathway that
subsystem to the display surface.
The
DPU
is
is
mostly contained
outside of the
is
DPU
comprised of the
is
fol-
lowing pieces of hardware: the display controller, the raster subsystem, the frame buffer, and the
5
-
refresh
subsystem.
DPU
we
if
discuss
We
can best understand the function of these different components of the
them
terms of their data flow.
in
The data
the device driver software.
lines
At the start of Figure
we
4,
see an
opcode
This stream contains the instructions and data output by
stream entering the display controller.
tem are
-
that leaves the the display controller for the raster subsys-
and polygons, and their associated colors and
The
fills.
raster subsystem, in turn,
converts those lines and polygons into the set of pixels necessary for their representation
frame
buffer.
The frame
pixels into electron
in
beam
With the above
DPU
mind, we can define the parts of the
We
the output function.
2.2.1.
begin by looking
in
brief overview of the data flow of the
DPU
with respect to the graphics capabilities needed for
more
detail at the display controller.
Graphics Capabilities for the Output Function: Display Controller
The
bilities.
by the refresh subsystem, which converts those
buffer's pixels are read
deflections.
in the
display controller
As seen
in
Figure
is
4,
best understood in terms of
its
text, colors, linestyles,
fills,
transformed coordinates
The operations
i.e.
etc..
is
i.e.
The data going out from the
familiar to those with a background
The
display
determines the operations
in
of display
describing the desired image.
opcode stream
it
display controller
text, colors, linestyles,
in is
comprised
is
comprised of
fills, etc..
the input data are the following: (1)
world coordinates to frame buffer coordinates.
operation, that
as formatted
rotations, scalings. translations, (2) coordinate system mappings,
perspective orthographic, and (4) display
the fourth
The stream coming
in,
a collection of untransformed coordinates, matricies,
the display controller performs on
matrix transformations,
clippings,
The data
frame buffer space,
in
operational capa-
its
the display controller has an opcode stream coming
by the device driver, and has vectors and polygons going out.
of opcodes followed by data.
data flow, and
list
management.
graphics
list
Now
The only one
management.
A
projections,
(3)
the
list
In reference to the previous discussion,
list
is
it
interpreted by the display controller.
in the
to
2D,
some explanation
set
is
of instructions
is
a
is
the data input as an
The
display controller
needs to perform on the input data from the display
on the remainder of the work to the next system
3D
three operations are
first
that requires
displax
i.e.
and
list,
and passes
hardware path, the raster subsystem.
X
ee
I—
a
co
•H
Q
CO
c
a
i
I
43
-^-
43
43
•H
S
rf
<o
03
rH
a)
CQ ^h
m
V
a
H
s
X!
•H
bO
•
G
H
0)
CO
(0
+3
V
CO
CO
(V
ll
>>
o
*H
(0
(0
J3
tf
3
u
Pu
Cfl
>>
CO
iI
T3
-#-
rH
i-H
a
ri
0)
CO
X
(0
•H
•H
OS
O
C
Ih
a)
0)
CO
<*H
+3
«H
ri
u
cd
3
fe
•H
bO
0Q
u
<o
a
o
CO
ii
43
0)
+3
-^~
.
-H
X
In
•H
Oh
>
a
CO
+3
3
o
S
0)
CO
(h
43
a>
-P
co
w
>>
43
Ih
CD
TO
J3
tf
3
W
CO
CO
c
43
bO
Oh
i1
-D
**
4-3
nj
.-i
CO
cu
u
d
0)
>
-o
1
>>
D
ti
X
f-H
03
•H
Q
5
3
£5
C;
3
CO
iI
§
~^-
CO
'
a
a
+3
CO
-
2.2.2.
6-
Graphics Capabilities for the Output Function: Raster Subsystem
The
raster subsystem
have been transformed into frame
receives lines and polygons that
buffer space, text, colors, linestyles, and polygon fillstyles from the display controller.
can discuss the operations performed by the raster subsystem,
buffer, the destination for the
The frame
buffer
is
drawn
be
at that position
system are
The data
at
memory.
segments into the
describe the frame
Each position
in
the frame buffer
each pixel location corresponds to the color that should
on the graphics display.
The operations performed by
The
destined for output to the frame buffer.
all
first
raster
set of pixels necessary for the display of those
the raster sub-
subsystem converts input
The
segments.
fills.
The
raster subsystem provides a similar treatment for text,
i.e.
line
raster subsystem
also converts input polygons to the set of pixels necessary for the display of their boundaries,
interior
we
output from the raster subsystem.
a two-dimensional array of
has a value, called a pixel.
we must
Before
it
fills
and
the frame
buffer with the appropriate patterns of pixels.
2.2.3.
Graphics Capabilities for the Output Function: The Refresh Subsystem
The
The
tron
final
pathway
part of the hardware
for the
output function
is
the refresh subsystem.
Tefresh subsystem reads rows of pixels from the frame buffer and produces the necessary elec-
beam
deflections on the cathode ray tube of the graphics display.
either every sixtieth or every thirtieth of a second,
It
performs this operation
depending on the cathode ray tube driver tech-
nology used.
2.3.
Software and Hardware for the Graphics Input Function
Wit h respect
is
to the graphics workstation, the second operation with
the input function (Figure
but
we
ices
at
It
is
more correctly termed the picture manipulation function
stick to the accepted terminology.
the applications program
function
5).
is
the
is
performing
really a feedback function,
DPU,
which we are concerned
is
i.e.
It
is
called the input function because the operation
reading a value from an interactive device.
we read some
The input
control values from the interactive dev-
pass those values back to the applications program,
make
a
change
in
the
>>
a
r—i
a
GO
•H
Q
0)
>
4
•H
01
d
-h
fc
>
o;
<d
0)
1
f
u
3
P
p Q
c
•
H
O
H
CL
P
a.
Q
P
bO
a
•H
CO
P
•—
3
i I
•
JS
PS
C
flj
10
(-1
o
•H
>
f
Q)
a
ri
<u
•H
>
0)
>
-H
Sh
3
^
a>
Q
Q
P
CO
S
3
o3
i—
PS
ri
V
w
u
h
C
•H
A
•
55
=
>
o
c
3
P
3
a
c
H
S,
M
™
-c
P
*y
o>
rf
^
~rt
°-
u
c
i
CO
i
p
m
•H
—
a
a
<
Jz
<*
<—
cd
rt
•H
t
>
v
U
•H
s
rt
U
hC
»h
Du
N
c
hD
O
new picture
picture at that level, and then send the
This
is
emphasized
Figure 5 by a pathway of directed arrows from the
in
the applications program, and another
The values read from
display.
program
tions
utilized
in
in
in the direction of
DPU
and then the
the interactive devices are typically passed back to the applica-
program, the raw values are
In the applications
an applications programmer written procedure to modify some aspect of the current
of this
is
the conversion of a dial value into an angle, with that angle being
command
plugged into a rotation matrix, or rotation
2.3.1.
DPU
towards the
of directed arrows back
set
an unchanged, or raw form.
An example
display.
pathway described above.
via the output
Hardware
for the
passed back to the
DPU.
Input Function
Other than the actual interactive device hardware, and the interfaces to support those devices,
there tends not to be
major exceptions:
(l)
much
special
direct cursor
modification hardware.
hardware to support the input function.
movement hardware
Cursor devices,
mouse
i.e.
There are two
support, and (2) display
devices, data tablet pens,
and
list
parameter
light pens,
some-
times have hardware support that eliminates the need to feed raw data values back to the applications program to change the position of the cursor.
the
DPU.
It
does not require
Display
direct cursor
ters
list
in
in
the
way
is
is
This hardware provides a mechanism by which modifications of parame-
display
lists
can be routed directly from the
the routing of a raw control value, or
value, as a direct replacement of an
angle value
in
a
generally carried out by
similar in goal to that of the hardware for
DPU
rotation
argument
command.
in
some simple
an instruction
of this type of
linear modification of that
in a
This type of operation
on interactive control move-
An example
ment, rather than through the longer applications program loop.
operation
is
of special hardware.
parameter modification hardware
movement
embedded
much
This operation
is
display
list.
similar in
i.e.
raw
replacing the
concept to the
ill-
thought-of practice of self-modifying code and requires some knowledge of the internal structure of
the selected graphics system's display
lists.
Besides hardware for the above two input operations, there
for the input function.
is
generally no special hardware
This lack of hardware limits the sophistication of the types of interactive
-p
U
co
<y
h c
H C3
•
C
>>
rH
h a
(0
to
o
p
•H
Q)
X!
O
B
3
P.
-O
•H
P
rH
CD
C
^
3
3
2
rH
CO
a;
u
3
•H
.-I
-p
hD-H
C
•HMO
O
fc
XH
P> O
Ctf
CO
«+-t
I
c
a c
ci
u
->
bDr-l
•H
C
Q •H
,* -P
-H
T5
rH T3
+3
we
operations
hardware
-
8
-
we
to support special input functions,
DPU
3.
Leading Edge Graphics Workstation Capabilities
to the applications
this point
We
bilities.
special
pathway from
are limited to the slow, feedback
the
To
Without
are currently capable of performing in the graphics workstation.
program and back.
we have not
talked about commercially available graphics workstations' capa-
have only given a generic description of the input and output functions with respect
hardware and software subsystems necessary to perform those functions. To show the lead-
to the
we
ing edge of technology for the graphics workstation,
back to some of those descriptions
refer
and point out how they are available on one high-performance graphics workstation.
The
3.1.
Silicon Graphics, Inc.
IRIS Workstation
on graphics capabilities
In the section
for the
output function of the display controller, we
listed the
operations that are performed by that part of the
mations,
(2)
coordinate system mappings, and clippings,
management.
tem of the
of the
Inc.
DPU
is
The
example of
best
component,
as
7,
and
five
[2
cies
this for a graphics workstation
').
The IRIS system has
major components,
shown
in
Figure
7, is a
chip pipeline for matrix multiplication.
all
fourth component
is
a
two chip
projection operation, and the
space.
The
final
(4)
display
list
component
i.e.
first
three functions
that of the Silicon Graphics.
"Geometry Pipeline"
for these opera-
special purpose
VLSI subsystem
floating point format.
The
third
top, bottom,
chips.
The second component
component
left,
VLSI
to convert uorld, or appli-
This part of the pipeline operates on
setup for rotations, translations, and scalings.
clippers that perform geometric clipping,
a
is
implemented via
special
Geometry Engine
cations program coordinates to
a four
and
projections,
(3)
the addition of a special pipeline processor to perform the
This pipeline has
first
are (l) matrix transfor-
of the leading edge developments that have been accomplished for this subsys-
IRIS (Figures 6 and
tions
The
list.
One
DPU. They
is
right, near,
a
six
and
4 x 4
is
matri-
chip pipeline of
far clipping.
The
pipeline, labeled scalers, that performs a perspective division, the
mapping
of the three-dimensional coordinates to two-dimensional
of the pipeline
is
a
VLSI subsystem
to convert back from
Geometry
W
w
0)
a;
ti
I I
c
•H
TJ
^*
CO
^
g
O
o
4->
7 *
1
w S
o >
CO
/- v
(h
CD
i—
a
°
rH
CO
D.
•
•
f>
c
-H
X!
)
cu
i- (
cU
'
co
03
+3
CD
a
o
cu
O
CO
H
to
OS
(0
a
o
o
0)
J2
•H
<—<
a
•H
Tt
o
co
•H
a
o
X
•H
CO
a
^
c
u
Js
J^
35
S
tT
CO
E
Ph
T3
C
•
rH
<-t~
i—l
U
C
T-H
10
V
r-H
*
C
T
O
-
9-
We
Engine floating point format to world coordinate format.
though not directly useful
Geometry Engine
ics,
Inc. for the
output operation,
for the graphics
note here that this operation,
somewhat
is
useful
when
The brochure produced by
pipeline as a computational engine.
IRIS-2400 model containing this pipeline
cites a capability for
utilizing the
Silicon
4x4
80K
Graph-
transfor-
mations per second.
The
Silicon Graphics, Inc.
One
hardware.
of these
is
in
IRIS-2400 has other leading edge functionalities present
DPU, polygon
the raster subsystem of the
hardware converts two and three-dimensional polygon data into the
pixels that represent the polygon
capability for filling polygons
at
in
hardware.
fill
set of textured
This
and colored
rate cited for the IRIS-2400
is
the
is
the
approximately 44 million pixels per second.
Another leading edge function of the IRIS
intensity modulation of line segments so that
brighter,
The
the frame buffer.
in special
is
Depth cueing
depth cueing hardware.
components of the segment near the viewer appear
The
and those farther away appear dim.
rate cited for this
hardware capability
is
from
1.5 to 3 million pixels per second.
Gouraud shading
algorithm useful
in
is
Gouraud shading
another feature of the IRIS-2400.
depicting surfaces via computer graphics.
is
a
smooth shading
This algorithm works by taking the
polygons that form the surface and shading those polygons by linear interpolation of the color
the verticies of the polygon
intensities specified at
tinuities
bility is
and produces
up
surface
hardware addition,
frame
same time
elimination
are
realistic surface.
buffer.
is
is
a
is
via
The
special
a special piece of
Depth information,
as color information
As each new
provided
is
called a Z-buffer.
the frame buffer, there
fashion.
smoother, more
rate cited for this
hardware capa-
to 3 million pixels per second
Hidden
as the
a
This technique eliminates intensity discon-
z
hardware on
memory
coordinate values,
written into the frame buffer.
matching
z
coordinate.
piece of the picture
compared against those already
in
is
is
the
the
The
IRIS-2400.
same two-dimensional
stored into this
memory
size
at the
This means that for each pixel
This information
is
used
in
in
the following
processed by the raster subsystem, the pixel values
the Z-buffer.
If
the
new
pixel
is
closer, the color associated
10
-
with that pixel replaces the old one
the Z-buffer.
is
the frame buffer, and the
in
farther
This special hardware addition
carded.
is
the new pixel
If
cited
IRIS literature
in the
for the
-
away than
z
coordinate
subsystem of the IRIS.
speed of this Z-buffering technique,
approximately the same rate as the polygon
written into
is
that indicated in the Z-buffer, the pixel
to the raster
is
new
it
is
dis-
Though no value
should operate at
hardware, with some degradation due to the addi-
fill
tional z coordinate value that needs to be propagated.
4.
Trends
Graphics Capabilities
in
The above
is
Workstation
for the
a quick overview of one leading edge graphics workstation.
There are others
that exhibit similar capabilities, though most are not nearly the speed of the IRIS.
brief look at the leading edge though,
performance graphics functionality
in
functionality,
is
see
two
The
first
past, the graphics applications user
We
new
technol-
hardware additions requested by
do not expect
became accustomed
to turn around almost immediately with
VLSI
trend, the increasing importance of high perfor-
a continuation of the cycles of
the ever unsatisfied graphics applications user.
this
trends, (1) the increasing importance of high
the workstation, and (2) the increasing use of
ogy to implement this functionality.
mance graphics
we
From
requests.
to
this trend to diminish.
new hardware additions
In the
rapidly, only
Given human nature, we do not expect
this to change.
To understand
the second trend, the increasing use of the
VLSI technology
to
enhance the
graphics capabilities of the workstation, we need to answer the question, what does VLSI provide?
VLSI provides
processors
We
8.
the capability for the parallel operation of large
111.
we
sometime between the years 1990 and 2001
these numbers, graphics researchers tend to see tens of processors per chip,
parallel
on some graphics algorithm
JSome landmarks
50,000
of relatively inexpensive
see 2 million transistors per chip in the research laboratory
are promised 10 million transistors per chip
From
chip
Currently,
numbers
in
|3|,
the
PLA
for transistor
and
ROM)
and 194,000 transistors
in
18,000 transistors
the Motorola
in
the
MC68020
in
the
Z8000
[7].
Motorola MC68000 (16,000 in the processor,
40,000 transistors in one Geometry Engine
14],
.
12;.
operating
$.
count are 68,000 transistors
[4j,
all
9
in
11
-
-
Fourth Cycle of Hardware Improvements to the Graphics System: Research
4.1.
Besides the improvement of the capabilities of the standard hardware that performs the
input and output functions of the graphics workstation,
hardware developments also
cial
work
is
The
(The need
algorithm.
for a
methodology
thrust of this research
and producing a
for taking a graphics algorithm
hardware development.
time
and
software engineering
is
engineering,
prominent
for the real-time display
is
the development of a
quite simply to save time for the next
is
to the other cycles of special graphics
software
cycle, the
system that performs that
silicon
through the hardware development process.) The scope of this work
graphics
new
In this
VLSI architectures
the design of special, application dependent
methodology
see the start of a fourth cycle of spe-
VLSI technology.
utilizing the
generation of select graphics algorithms.
we
VLSI computer
part of this effort in that before one
It
is
algorithm
quite large in comparison
encompasses the areas of
architectures.
commits
to
Real-time
real-
graphics
implementing a particular
graphics algorithm in silicon, one needs to be able to evaluate whether or not that algorithm can
be
computed
in
research effort
is
real-time
to
on
a
currently
available,
produce a system that can automatically model the desired algorithm such
that runtime parameters can be obtained for hypothetical architectures,
the
MC68000
is
processors like
VLSI.
in
The
research effort
is
twofold.
The
the determination and evaluation of a special architecture for the studied algorithm.
The detcrminat ion
by
known
architectures are part of this effort in that the hypothetical architectures
modeled are those capable of being implemented
part
i.e.
for subparts of the larger algorithm.
VLSI computer
first
The
high-performance graphics system.
of the architecture
is
accomplished through iterative design refinement driven
The evaluation
previous experience with such special processors.
runtime evaluation, and
died algorithm
is
a
technological evaluation.
capable of being executed
technological evaluation determines
current technological constraints.
if
in
The runtime evaluation determines
is
if
both a
the stu-
real-time on the hypothetical architecture.
the proposed architecture
Part of this
of the architecture
effort
is
is
The
capable of being built within
the examination of the changes required in
the design of the graphics system that receives the output of the real-time display generator.
12
-
The second
part of the research effort
in
-
the area of
VLSI computer architectures
is
the
evaluation and refinement of the software tools available for putting an architecture on silicon.
VLSI technology
Since
relatively new, the available software tools for producing special purpose
is
VLSI chips and systems
such software.
The
are crude.
Since this
research of the fourth cycle presupposes the existence of
clearly not the case, this research effort necessarily
is
encompasses the
refinement and development of such software tools.
We
Where
4.2.
The
Are Today
in
hardware
initial special
the Fourth Cycle
efforts of the fourth cycle are the construction of single
VLSI multiprocessors compatible with commercially
The
tations.
selection
of the
commercially
hardware additions cuts the research
effort
board
available, high-performance graphics works-
available workstation
as
bed for the special
the
with respect to real-time display generators
delaying for later consideration possible changes to the design of the display system
by
in half,
Such
\.
a
sectioning of the research effort allows the design and testing of single board parts of perhaps
much
larger
One such
VLSI systems.
underway
effort
design of a Multibus compatible, single board
at the
Naval Postgraduate School
VLSI multiprocessor
is
the
contour surface
for generating
displays in real-time 13i.
4.2.1.
Contour Surface Display Generator
The
goal of the contour surface display generator
surface of a
graphics workstation,
in
one-thirtieth
is
of a
to
produce and deliver to the display
second, the complete contour surface
display generated from a 30 x 30 x 30 three-dimensional grid.
system
is
in
mind
for this
one directly from X-ray crystallography, the determination of molecular structures from
electron density data
ics
The application
1
.
Such an operation
program that displays
a
Dreiding
is
(stick)
executed interact
i\
ely
by using a computer graph-
model of the molecule,
inside a contour surface
display of the corresponding region of the molecule's electron density grid.
In addition to the
graphics function, the computer program monitors a series of signals generated by the user, while
t
There are currently substantial research
efforts in the direction of the redesign of the graphics
system
|5,
10i
Figure 8
Contour Surface Display Generated from a Hydrogen Atom
Wavefunction Squared (3dz2 orbital)
13
-
the user
-
turning the various knobs on a control console
is
program
are interpreted by the
16,.
The values read from
these knobs
as modifications to either the molecule or the surface display.
Modifications to the molecule take the form of bond rotations or bond lengthenings.
Modifica-
tions to the contour surface display take the form of an increase or decrease of the contour level.
The
goal of this process
given electron density data
model of the molecule that best
to produce the stick
is
The
set.
user can determine whether or not the
model
fits
grid by modifying the contour level, shrinking the contour surface to the molecule.
user can
expand the contour surface from the
stick
model
inside the
fits
for better visibility.
the density
Similarly, the
This function
requires that the hardware have the capability to rapidly change the contour display as
its
con-
is
con-
tour level changes.
4.2.2.
Decomposable Algorithm
The algorithm around which
structed
is
presented
algorithm that
is
used to contour
three-dimensional
larger
Contouring Operation
the design of the contour surface display generator
That algorithm
14'.
in
for the
all
is
constructed from a two-dimensional contouring
the possible planar, orthogonal, two-dimensional grids of a
The two-dimensional contouring
grid.
algorithm
of
comprised of components, called algorithm components, that operate on individual
of a larger two-dimensional grid.
(Note: a 2 x 2 subgrid
dimensional grid bounded by four adjacent grid points.)
sar>
for
generating
required for any other
for all
2x2
2x2
2 \ 2
subgrid.
If
If
In the
2x2
we
study
2x2
subgrids
is
defined to be that portion of the two-
algorithm, the computations neces-
subgrid
are
independent
we compute the contours corresponding
subgrids of a two-dimensional grid, then
contours for that grid.
ble
contour lines for a single
the
is
that
will
from those
to contour level k
have determined the complete
we compute the contours corresponding
set of
to contour level k for all possi-
subgrids of the larger three-dimensional grid, then we will have the complete contour
surface display for that
simultaneous display of
dimensional
grid,
development of
grid.
all
The assemblage
the
of the contours created by this process,
contours created
for
all
2x2
subgrids of the
produces a "chicken-wire-like" contour surface display (Figure
this
algorithm can be found
in
14
.
V\ e refer to the results
i.e.
larger
8).
the
three-
The
full
of those studies, and
U)
•
A 2 x 2 Subgrid
2
A 2D Grid of Size
(1
-
1)
x
(m -
1)
A 3D Grid of Size
1
x
(m -
1)
x
(n
-
1)
2x2
+
m x
(1
-
2x2
1)
1
x m Has
2x2
1
x
Subgrids
x m x n Has
(n
1) - n x
(1
Subgrids
Figure 9
Subgrid Count for 2D and 3D Grids
1)
x
(m -
1)
-
do not
cover
algorithm
the
here
great
in
14
-
We
detail.
only
note
that
for
the
largest
three-
dimensional grid of interest for the above application, a 30 x 30 x 30 grid, this means the potential for
75,690 parallel operations (Figure
4.2.3.
Architectural Goals for the Contour Surface Display Generator
The
meets
first
the
goal
in
9).
the design of the contour surface display generator
performance
requirements,
30 x 30 x 30 grid, and delivered to a display device
tious goal but
it
sitions
in one-thirtieth of a
must be noted that one-thirtieth of a second
allowable for the operation.
Any
longer
to build a system that
new contour surface display computed from
a
i.e.
is
amount
the
is
second.
This
is
an ambi-
maximum amount
of time does not provide the viewer
a
of time
smooth tran-
between successive contour surface displays. This goal says nothing about the load time of
the 30 x 30 x 30 grid to the special piece of hardware that computes the contour surface display.
Consequently, we allow solut ions that pre-load the
The second
grid.
goal for the construction of the contour surface display generator
mentioned above, that we be able
hardware and software changes.
plug
it
into
an
For the purposes of
chosen to be the Silicon Graphics,
currently the highest
to
Inc.
existing
graphics system
this study,
IRIS workstation
the one
with minimal
graphics system
is
Silicon Graphics, Inc. IRIS
is
the target
The
[2j.
is
performance graphics system that best matches the selected application's
goals.
Architectural Outlines
4.2.4.
Given that we have
and given that our goal
wo can make about
arra\
(Note:
is
highly decomposable algorithm for contour surface display generation.
a single
board
\
LSI multiprocessor, there are some simple statements
the system's architecture.
of independent
(Figure 10)
a
The
first
statement
processors, each processor containing
we
call these processors,
is
that
it
is
some subpart of the
comprised of an
total algorithm
algorithm component processors.) In the case of the
contour surface display generation algorithm, this means that each processor contains one or more
2x2
subgrids taken from the larger three-dimensional grid
It
also
means
that each processor
is
System Bus
Ext .Port
Multibus
Figure 10 Contour Surface Display Generator
-
ir,
-
responsible for computing the pari of the surface" display represented by
performs these eornput
at
is
algorithm
in
each processor
in
the architecture for the contour surface display
though we compute the subparts of the contour surface display generation
that, even
parallel,
The system
subgrids.
ions in parallel.
The second statement we can make about
generator,
its
we need
a serial,
the coordinates and drawing instructions generated
to output
one processor
at
This statement
a time, fashion.
is
in
based upon the
requirement that the contour surface display generator be plugged into an existing graphics sys-
tem (Figure
11).
Currently available graphics systems only have
display processing units.
a
single data
path into their
Consequently, some mechanism needs to be provided to output the data
generated from the algorithm component processors, one
at
a time, to the display
processing unit
of the graphics system.
A
third statement
delivering the
2x2
we can make about the architecture
Subgrid delivery
subgrids.
ponent processor addressability
determined processor.
a
A
.
i.e.
we need
for this qualification
tiple
VLSI chips
lines
between
\
be able to put each set of subgrids
is
a
large
number
is
mechanism
based upon the knowledge that
scarce resource.
y
The output mechanism
is
pre-
that n must be
to run
between mul-
package pins
for control
for the coordinates
and
a similar processor addressa-
capability
A fourth statement we ran make about the architecture
is
that
we need some mechanism
delivenne the new contour level? to the algorithm component processors.
can be delivered either
serial,
com-
a
in
for
of control lines and arbitration circuitry.
that v\e expect the addressing
This qualification
LSI chips arc
a
drawing instructions of the contour surface display generator needs
bilit
we need some mechanism
qualification to ihi^ processor addressability capability
simple mechanism that doesn't require
The reason
that
qualified by the necessity for algorithm
is
to
is
in
parallel, to the
Since
we
are already putting one
system for loading data into the processors, we expect that
levels.
levels
complete system of processors during one cycle, or
to each processor on a separate cycle.
contour
The new contour
for
Consequently, the new contour
it
mechanism
in
in
the
can also be used to deliver the new
levels are delivered in serial, in a
manner
similar
d
•H
(0
a
CO
M
(V
to
fa
o
r—
fa
r-H
a
-P
fa
10
o m
+3
a
Q
T3
c
In
s
-P
X,
c
±>
Q)
•H
C
to
a
oj
(h
U
<
to
U
<
w
(D
to
to
o
B
hD
rH
cd
o
DQ
U
-P
d
CO
0)
CQ
c
4^
a
u
c:
H
-P
o
to
d
>>
CQ
C
rH
a
o
to
•H
Q
to
\
o
c
C
a
C
8
•H
>
P
c
o
o
in
Q
5-!
£J
O
P
c
O
SD-QHMOQ^Cfl
-
16
-
mechanism.
to the subgrid load
Architecture of the Contour Surface Display Generator
4.2.5.
The contour
surface display generator
rithm component processors,
ponent processor
and
itself,
is
comprised of four subsystems:
(2) the controller for that
(4)
(1) the
array of algo-
array of processors, (3) the algorithm com-
the interface to the graphics system.
how
Figure 11 shows
the
four subsystems relate to the target graphics system.
The Array of Algorithm Component Processors
4.2.5.1.
Figure 11 depicts the array of algorithm component processors as a single box, with three
connections to the outside environment, an input bus for contour levels and subgrids, an output
bus for coordinates and drawing instructions, and
dual bus configuration
autonomous nature
The input bus
to the array
is
bus for controlling the array of processors.
a
chosen to maximize the amount of concurrency
in
the system due to the
of the input with respect to the output.
is
the
medium
of algorithm
responsible for delivering subgrid definitions and contour levels
component
processors.
Because
ihis
is
the only data required to be
transmitted on the bus. the bandwidth of the input bus does not need to be very high.
at
A
The
rate
which subgrid definitions are loaded into the algorithm component processors does not directh
the real-time capabilities of the system.
affect
displax
generator are determined b>
component processor. This,
unit.
The output bus
is
in
The
real-time capabilities of the contour surface
the rate at which data can be produced in each algorithm
turn, directly affects the rate of output to the display processing
responsible for delivering the coordinates and drawing instructions to the
display processing unit.
The
sar\ to
control bus for the contour surface display generator contains
manage
the data flow on the input side of the system (Figure 12).
lines are required
the algorithm
12
all
the control lines neces-
Two
additional control
on the output side of the system to coordinate the two wire handshake between
component processors and the display processing
shows the signals that are needed
for all
unit
(Geometry Engines).
Figure
the pin assignments of the algorithm component
SYSTEMS
1
——A
Input
Bus
1BO 1B16
Control Bus
Reset
Mul t i bus \
I nt erf ace
86 Pins
Test
Load Subgrids
Compute Contours
Input Count Enable
Input Count Enable Return
Output Count Enable
CONTROLLER
Output Count Enable Return
Wait/Test Acknowledge
Write Enable
Error
nput
Bus
IBO-IB15
I
N
.ALGORITHM
Output
Bus
OBO OBI
Wait/Test
Acknowl edge
Reset
Write
Enable
Test
Load
Su bgr ids
Comput e
Contours
I r.
p at
Court
COMPONENT
.
Output Count
Enable Return
^
Enable Return
Output Count
Enabl
Input Count
En ab i e
PROCESSOR
ge req
ge ack
Figure 12
Functional Pin Diagrams of the Systems Controller
and the Algorithm Component Processor
-
17
-
processor.
Systems Controller
4.2.5.2.
Control of the array of algorithm component processors involves the integration of several
The one which coordinates
components.
different
The systems
systems controller.
places the
mands
controller converts
The Multibus bus master
commands on
of these processors
the Multibus.
the board
is
The systems
controller
in
is
the Multibus Backplane which
a slave in that
it
reacts to
that
is
responsible
for
the
is
is
the algorithm
component
an overview diagram of the key components of that processor.
is
interested
4.2.5.4.
in a
is
a
full
microprocessor of the Motorola
more complete treatment
We
is
referred to
do not go into great
MCG8000
It
should
The reader
class.
13
surface display generator
is
connected to the Silicon Graphics.
system b> means of the IEEF. standard Multibus Backplane Bus 6
all
inputs to the contour surface displa\ generator.
classifications of bus
different
mands, and
(2)
Slaves
Master module
module
Fig-
System Interfaces
The contour
provide.*
Each
processor.
identical and functions independently in the production of the outputs.
be noted that the processor
the
com-
production of the coordinates and drawing
detail about that processor other than to point out the items that appear in Figure 13.
two
the
incoming signals from the Multibus bus mas-
instructions for the contour surface display generator
ic K
is
Algorithm Component Processor
The component
1?.
other components
placed on the Multibus.
4.2.5.3.
ure
all
IRIS workstation into signals which make sense to the algorithm
ter of the Silicon Graphics, Inc.
component processors.
the operation of
in that
for
svstem.
-
modules:
(1)
those which respond to
the graphics system.
Masters
-
.
Inc.
IRIS graph-
This Multibus connection
The Multibus
interfaces to basically
those modules which generate com-
commands. The parent processor (MC68000)
The contour surface display generator
is
is
a slave
L
0)
P.-H
3
rt
to
c
C-H
H
+3
u
V
C
CD
O
>,
ci
u
/
1
(X
(0
\
•H
(0
tO
\
hD
QJ
O
J
CD
Pi
Cu
ci
*H
CD
CO
-p
CO
co
O
u
DQ
to
Du
S
en
+3
u
o
2S
c
o
H
to
CO
c
O
o
CO
-P
c
p
o
c
0)
a
PQ
O
43
CD
-D
(0
<
to
.
CO
"bO
*H
c
(1)
•H
Q
co
3>
<,
T3
•H
tf
P
hD
bD
u
Pu
T3
P
P
a
CO
C
43
c
«j
Xi
3
3
CO
^^
-p
a
o
a
o
e
43
•H
Jh
bD
t
d d c
C-H
IM
-
The output
of the contour surface display generator
The Private Bus
(Figure 11).
-
a unidirectional.
is
16
to the Private
is
bus dedicated to the provision of coordi-
bit
nate and drawing instructions to the high speed Geometry Engines.
of data
line
Bus of the IRIS system
Coordination of the transfer
between the algorithm component processors and the Geometry Engines
done via
is
a
two
handshake protocol.
System Implementation
4.2.5.5.
The IRIS graphics workstation
communications network and
hardware elements
(Figure
a
make up
that
is
MCoSO(K)
uses the Motorola
whose output
is
between devices
operating system, the Ethernet
real-time three-dimensional color-raster graphics system.
as a controller
and
Geometry Engine
a
done on the Multibus.
The terminal
terminal on the workstation.
a host
pipeline for matrix operations
destined for a high-resolution color raster-scan display.
is
The
the workstation are connected to one another via the Multibus
Graphics commands are issued by
(3).
UNIX
comprised of the
Graphics pipeline data
is
The communications
transferred on the Private
Bus.
Graphical output
pipeline.
initiated
is
l>\
the ('PI
sending
l>\
The Geometry Engines perform matrix
fonts,
The update controller does scan conversion of polygons,
The
lines
display
and constructs
and characters.
capabilities required
I
The
and polygons.
The results of those
2'.
Integration of the Contour Surface Display Generator
The Multibus Backplane
generator
lines
scaling.
controller fetches the picture-element
values from ihe frame buffer and draws them on the face of the color monitor
4.2.5.G.
to the graphics
transformations, clipping and
frame buffer controller interprets characters, controls
operations an- placed into the frame buffer.
commands and data
is
to
of that s\ stem.
IRIS supplies
t
In-
power and inter-board communications
implement an integrated graphics system.
constructed as
and memory device.
of the
a
peripheral board and
is
added
The contour
to the IRIS graphics
surface display
system as a slave
Figure 6 shows the contour surface display generator as an integral part
J
GE
=
=
MC68000
PROCESSOR
J
BOARD
3
(GF1)
J
2
BOARD
—
J
(PM1)
1
n
fo:
Figure 14a
Silicon Graphics, Inc. IRIS Pipeline Connection
the Private Bus (Courtesy of Silicon Graphics, Inc.)
GE
BOARD
—
CONTOUR
(GF1)
SURFACE
DISPLAY
—
GENERATOR
Figure 14b
The J3 Pipeline Connection of the Silicon Graphics, Inc
for the Contour Surface Display Generator
Private Bus
-
The
19-
use of the contour surface display generator in the graphics system involves the estab-
lishment of a physical connection between the peripheral board containing the algorithm com-
ponent processors and the display system.
This connection involves the Private Bus port which
transports the data directly to the Geometry Engines.
tem has
a
In its present configuration, the
IRIS sys-
connecting cable that directly connects the system processor to the Geometry Engines
(J3 connection of Figure 14a).
When
the contour surface display generator
must be shared by both
itself
added to the system,
is
To
and the system processor.
processor and generator data to the
Geometry Engines,
a
this physical connection
enable the user to alternatively route
hardware switch
added to the system.
is
This hardware provides the system with a way to multiplex the direct path of the Private Bus.
software switch then provides the control of the Private Bus
:
origin
A
When
and configuration.
activated, this switch establishes a path from the contour surface display generator (Figure 14b).
If
is
it
4.2.6.
not activated, the IRIS system remains
13
tem
.
is
the
a
quick overview of the architecture of the contour surface display generator.
in
this
system
is
obviously the algorithm component processor.
determined that 50 algorithm component processors are
to generate
mine the
is
components
of the key
it
original configuration.
Hardware Complexity Estimate
The above
One
in its
and deliver the average sized picture
feasibility of the
algorithm
complete system, we need
component
processor.
The derivation
equivalent devices necessary.
only that the total
660K devices
being produced
number
This number
in
Figure
is
well below the
research laboratories
is
less
J9'.
of the
a circuit
a
in less
in
the sys-
In order to deter-
complexity estimate for the
summary
numbers on
number
of the
that' figure
is
in
size of
of transistor
13
We
.
component processor
two million devices per chip
For
than 5 VLSI chips.
grasp of current technology.
is
that are needed
30 x 30 x 30 grid.
of devices required for one algorithm
rithm component processors can be built
per chip level, this
15
for a
all
In
level that
is
is
note
about
currently
this level of chip complexity, the array of algo-
than 25 VLSI chips.
The design
At the ten million devices
of this system
is
therefore
within the
(1)
RAM
space
8192
(2)
ROM
(2
devices 'bit)
32 bits
x
space
— Tree
-
--
(1
device
524,288 devices
'bit)
tables
=
2048 x 16 bits
--
Microcode
2048 x 32
(3)
—
--
ALU
—
Register block
--
Control section
— Data,
65,768 devices
bits
Processor space
—
32,768 devices
address and control buses
Refresh logic
23,000 devices
(4) Interface
Unit and Test Bed
— External
— Test
—
Interface Logic
circuitry
— Latches and
Drivers
15,000 devices
Device Total
660,582 devices
Figure 15
Algorithm Component Processor's Circuit Complexity Estimate
20
-
-
Conclusions
5.
The above
is
but one example of the fourth cycle of hardware developments for the graphics
The purpose behind
system
the presentation of this effort
One
limitations of research in this cycle.
is
to highlight the possibilities and
of the key points described at the start of this paper
is
that applications users are never satisfied with the graphics capabilities of the currently available
We
system.
need to reexamine this notion
We
display generator.
can be assured that once we produce such a system that the applications
user will return to us with further
in
demands
the already manufactured system.
demand,
make
or
cannot count on the widespread
The only
mance.
The
step
first
in
solution then
that process
is
we need
to
for
make
VLSI
set
to put together a
The
communit)
hardware
Once
after standard interfaces
for select graphics
hardware
effort
on the
If
for
We
which we desire real-time perfor-
methodology based upon experience with design-
design and production of special
the establishment of "silicon foundries".
cial
any algorithm
methodology
that
We
standards for the production of such systems.
design.
university
to either justify the special
the production of that special hardware inexpensive.
ing such special purpose display generators.
can then
respond to these desires for special hardware for
the production of that special hardware inexpensive.
demand
is
for either other algorithms, or additional capabilities
In order to
select applications graphics algorithms,
basis of widespread
of the production of the contour surface
light
in
is
sufficient ly developed,
can see an analogy
VLSI chips came within the
were defined
we extend
in
we
the world of
possibilities of the
for rhip production.
Hence, we saw
this idea to that of the production of spe-
algorithms of the applications user, this means that somewhere
the future there will be "real-time, graphics foundries".
It
is
toward*
this direction that
in
we can
expect future developments for workstation graphics capabilities to proceed.
G.
1.
References
Barry. C. D. and Sucher.
J.
H.
"Interactive Real-Time Contouring of Density Maps." Ameri-
can Crystallographic Association Winter Meeting, Honolulu. March 1979, Foster Session
2.
Clark.
J.
H and
Davis, T.
Electronics. October 20. 1983.
"Workstation
I
nites
Real-Time Graphics with
I nix. Ethernet."
21
3.
Clark.
4
"The Geometry Engine: A VLSI Geomctn
H.
J
A Quarterly Report
Graphics:
-
of
S1GGRAPH- ACM,
System
Computer
for Graphics,"
Vol. 16. No. 3 (July 1982).
127
p.
Frank. Edward H. and Sproull. Robert F. "Testing and Debugging Custom Integrated CirComputing Surveys. Vol 13. No. 4 (December 1981), p. 425.
cuits."
5.
Fuchs, Henry
ments
No. 3 (July 1985),
6.
Intel
"Fast Spheres, Shadows, Textures, Transparencies, and Image Enhance-
et al.
Pixel-Planes."
in
Computer Graphics: A Quarterly Report
of
S1GCR APH-ACM,
Vol. 19,
111.
p.
Corporation Technical Publication, Intel Multibus Specification, Intel Corporation, Santa
Clara, California, 1982.
7.
MacGregor.
4.
No. 4 (August 1984).
D.. Mothersole, D.,
"The Motorola MC68020," IEEE Micro,
and Moyer, B.
Mead, Carver and Conway. Lynn Introduction
Addison-Wesley Publishing Company. 1980.
8.
9.
Micronews "IBM Experimental Million
1984),
10.
p.
Vol.
p. 101.
Bit
to
VLSI Systems, Reading. Massachusetts:
Memory Chip," IEEE Micro,
Vol.
4.
No. 4 (August
119.
SIGGRAPH. VLSI for Computer
Graphics. Special Interest
Group on Computer Graphics An-
nual Meeting, San Francisco. July 1985, Notes for Course 20.
can.
I.E. and Mead, C.A.
September 1977. pp. 210-228.
12.
I hr.
11.
Sutherland.
Academic
13.
Leonard
"Microelectronics and
Algorithm-Structured
Computer
Computer Arrayt
and
Science," Scientific Ameri-
Networks,
Orlando.
\\ alker.
Robert A. and Zyda. Michael J "An Integrated Systems Architecture for Real-Time
Contour Surface Display Generation." Technical Report NPS52-85-010. Monterey.
Department of Computer Science. Naval Postgraduate School. August 1985.
14.
Florida:
Press. 1984.
"A Decomposable Algorithm
Zyda. Michael J
for
California:
Contour Surface Display Generation."
Technical Report NPS52-84-011. Monterey, California: Department of Computer Science. Naval
Postgraduate School. August 1984.
16.
Zyda.
Technical
November
Michael
J.
"Joystick
Memorandum
1980.
Driven Display
24. St. Louis:
Rotation and Control Console Management."
Department of Computer
Science.
Washington University,
Distribution List for Papers Written by Michael J. Zyda
Dr. Henrv Fuchs,
208 New West Hall (035A),
University of North Carolina,
Chapel Hill, NC 27514
Dr. Kent R. Wilson,
University of California, San Diego
B-014,
Dept. of Chemistry,
La Jolla, CA 92093
Dr.
Guy
L. Tribble, III
Apple Computer.
20525 Mariani Ave,
Cupertino,
CA
95014
Dr. Victor Lesser.
University of Massachusetts. Amherst
Dept. of Computer and Information Science,
Amherst,
MA
01003
Dr. Gunther Schrack.
Dept. of Electrical Engineering,
University of British Columbia.
Vancouver, B.C., Canada V6T 1W5
Dr. R. Daniel Bergeron.
Dept. of Computer Science.
University of New Hampshire.
Durham.
NH
03824
Dr. Ed Wegman.
Division Head.
Mathematical Sciences Division.
Office of Naval Research.
800 N. Quincy Street.
Arlington. VA 22217-5000
Dr. Gregory B. Smith.
ATT
Information Systems.
190 River Road,
Summit. NJ 07901
Dr.
Lynn Conway.
Defense Advanced Research Projects Agencv/IPTO,
1400 Wilson Blvd.,
Arlington. VA 22209
Dr. John Lowrance,
SRI International,
333 Ravenswood Ave.
Menlo Park, CA 94025
Dr. David Mizell,
Office of Naval Research,
1030 E. Green St.
CA
Pasadena,
91106
Dr. Richard Lau.
Office of Naval Research,
Code 411,
800 N. Quincy St.
Arlington, VA 22217-5000
Dr. Y.S.
Wu.
Naval Research Laboratory.
Code 7007,
Washington. D.C. 20375
Dr. Joel Trimble.
Office of Naval Research.
Code 251.
Arlington. VA 22217-5000
Robert A.
Ellis.
Calma Company,
527 Lakeside Drive.
Sunnyvale. CA 9408C
Dr.
James H. Clark,
Silicon Graphics, Inc.
630 Clyde Court.
Mountain View, CA 94043
Shinji
Dept
Tomita.
of Information Science.
Kyoto University.
.
Sakyo-ku. Kyoto, 606, Japan
Hiroshi Hagiwara.
Dept. of Information Science.
Kyoto University.
Sakyo-ku. Kyoto, 606. Japan
Dr. Alain Fournier.
Dept. of Computer Science.
University of Toronto.
Toronto. Ontario. Canada
M5S 1A4
Dr. Andries Van Dam.
Dcpt. of Computer Science,
Brown
University.
Providence. RI 02912
Dr. Brian A. Barsky,
Berkeley Computer Graphics Laboratory,
Computer Sciences Division,
Dept. of Electrical Engineering and Computer Sciences,
University of California,
Berkeley, CA 94720
Dr. Ivan E. Sutherland,
Carnegie Mellon University,
Pittsburg. PA 15213
Dr. Turner Whitted,
208 New West Hall (035 A),
University of North Carolina.
Chapel Hill, NX 27514
Dr. Robert B. Grafton.
Office of Naval Research,
Code 433.
Arlington. Virginia 22217-5000
Nakamae,
Machinery Laboratory.
Hiroshima University.
Higashihiroshima 724. Japan
Professor Eihachiro
Electric
Carl Machover.
Machover Associates.
199 Main Street.
White Plains. New York 10601
Buddy Dean.
Naval Postgraduate School,
Dr.
Code
52. Dept. of
Computer
Science.
Monterey. California 93943
Earl Billingsley.
43 Fort Hill Terrace.
Northhampton,
MA
01060
Dr. .Ian Cuny.
University of Massachusetts. Amherst
Dept. of Computer and Information Science,
Amherst.
MA
01003
Robert Luin.
Silicon Graphics. Inc.
630 Clyde Court.
Mountain View. CA 94043
-
4
-
Jeff Hausch,
Silicon Graphics, Inc.
630 Clyde Court,
Mountain View, CA 94043
Robert A. Walker,
Naval Sea Systems Command (SEA 61 YM),
Department of the Navy,
Washington, DC 20362-5101
Lt.
Dr. Barry L. Kalman,
Washington University,
Department of Computer Science,
Box 1045,
St. Louis, Missouri 63130
Dr.
W m.
7
Randolph Franklin,
Computer, and Systems Engineering Department,
Electrical,
Rensselaer Polvtechnic Institute,
Troy, New York 12180-3590
Dr. Gershon Kedem,
Microelectronics Center of North Carolina,
PO Box 12889,
3021 Cornwallis Road,
Research Triangle Park,
North Carolina 27709
Dr. Branko
J.
Gerovac.
Equipment Corporation.
150 Locke Drive LM04/H4. Box 1015
Digital
Marlboro, Massachusetts 01752-9115
Robert A. Schumacker,
Evans and Sutherland.
PO
Box 8700.
580 Arapeen Drive.
Salt Lake City. Utah 84108
R. A. Dammkoehler,
Washington University,
Department of Computer Science,
Box
1045.
St. Louis.
Missouri 63130
Dr. Lynn Ten Eyck,
Interface Software.
79521 Highway 99N,
Cottage Grove, Oregon 97424
-
5
-
Toshiaki Yoshinaga,
Hitachi Works, Hitachi Ltd.
1-1. Saiwaicho 3 Chome,
Hitachi-shi, Ibaraki-ken,
317 Japan
Takatoshi Kodaira,
Omika Works,
2-1,
Hitachi Ltd.
Omika-cho 5-chome,
Hitachi-shi, Ibaraki-ken,
319-12 Japan
Atsushi Suzuki,
Hitachi Engineering, Co. Ltd.
2-1, Saiwai-cho 3-Chome,
Hitachi-shi, Ibaraki-ken,
317 Japan
Toshiro Nishimura,
Hitachi Engineering, Co. Ltd.
Saiwai-cho 3-Chome,
Hitachi-shi. Ibaraki-ken,
2-1,
317 Japan
Dr. John Staudhammer.
Dept. of Electrical Engineering,
L'niversity of Florida.
Gainesville, Florida 32611
Dr. Lewis E. Hitchner.
Computer and Information Science Dept.
237 Applied Science Building,
University of California at Santa Cruz.
Santa Cruz. California 95064
Dr. Pat Mantey.
Computer Engineering Department,
University of California at Santa Cruz.
Santa Cruz. California 95064
Dr. Walter A. Burkhardt,
University of California, San Diego
Dept. of Computer Science,
La Jolla. California 92093
P. K. Rustagi,
Silicon Graphics. Inc.
630 Clyde Court.
Mountain View, CA 94043
Peter Broadwell,
Silicon Graphics, Inc.
630 Clyde Court,
Mountain View.
CA
94043
-
Norm
(i
Miller.
Silicon Graphics, Inc.
630 Clyde Court.
Mountain View, CA 94043
Dr. Tosiyasu L. Kunii,
Department of Information
Science,
Faculty of Science,
The University of Tokyo,
7-3-1 Hongo, Bunkyo-ku, Tokyo
Japan
113,
Dr. Kazuhiro Fuchi,
Institute for New Generation Computer Technology,
Mita-Kokusai Building 21FL.
1-4-28 Mita. Minato-ku, Tokyo 108, Japan
Defense Technical Information Center (2)
Attn:
DTIC-DDR
Cameron Station
Alexandria, VA 22314
Library, Code 1424 (2)
Postgraduate School
Monterey, CA 93943
Naval
Research Administration Office
Code 012
Naval Postgraduate School
Monterey, CA 93943
Center for Naval Analyses
2000 N. Beauregard Street
Alexandria, VA 22311
DUDLEY KNOX LIBRARY
3 2768 00347475