|
Source: IBM RISC System/6000 Technology: Volume II, Sept. 23, 1993 (SA23-2619-00)
Authors: Charles R. Johns and Taggart Robertson
The POWER GXT100 and GXT150 are 2D graphics adapters based
on the Pixel Accelerator for X (PAX) 2D rendering engine and the IBM RGB
530 Palette Digital to Analog Converter (Palette-DAC). The PAX engine draws
or renders the graphical data sent from the 601 processor complex and the
RGB 530 displays the data on the screen.
The GXT100 has enough memory to support 1024 x 768, GXT150
has added memory to support up to a 1280 x 1024 screen and to utilize the
multiple color palettes in the IBM RGB 530 Palette-DAC. Both the GXT100
and the GXT150 are 8-bit adapters which require AIXwindows Environment/6000
Version 1.2.5 2D and AIX Version 3.2.5.
Design Goals and Considerations
The major goal of the PAX 2D rendering engine is for entry
workstations. The architecture is dedicated to accelerating X Window applications.
The architecture of a graphics subsystem can influence X Window performance
and time to market in several areas. The PAX architecture targeted three
areas: efficient interfaces, simple programming model, and rendering speed.
Graphics Subsystem Organization
The POWER GXT100 and GXT150 consists of the PAX 2D rendering
engine, the IBM RGB 530 Palette-DAC, 1M to 3M bytes of frame buffer memory,
and the initialization Read Only Memory (ROM). Figure 1 shows the complete
block diagram and the major interfaces of the graphics subsystem. The PAX
chip serves as the graphics accelerator as well as the system interface
for the adapter. It contains the control for accessing the initialization
ROM, the Palette-DAC control port, and the video RAM (VRAM) parallel port.
Graphics Subsystem Block Diagram
PAX attaches directly to the PowerPC 601 Microprocessor
bus. Attaching directly to the
PowerPC 601 bus improves performance by avoiding the latency and synchronization
overhead created when converting from one bus to another. The 601 bus is
a split address and data bus with 32 bits of address and 64 bits of data
[1]. The processor uses byte, half-word, or word operations to access the
graphics subsystem. Based on the address of the operation, PAX directs
the access to one of four locations: the internal registers, the frame
buffer (i.e. the VRAM),
the RGB 530 Palette-DAC, or the initialization ROM.
PAX Block Diagram
The frame buffer is constructed of specialized memory called video RAM
(VRAM). These
memory devices contain key features for increasing graphics performance
including:
- Serial output port
- Block Write
- Write per bit
The serial output port is a dedicated high speed interface
used by the Palette-DAC for scanning pixels out of the frame buffer VRAM.
This interface eliminates the overhead of refreshing the screen from the
parallel port which is often required with more conventional DRAM interfaces.
Block Write is a unique feature of VRAM which allows a
constant color to be written to multiple locations within a single write
cycle. This feature allows PAX to render up to 32 pixels in a single write
cycle.
The Write per bit feature provides a write mask which the
rendering engine uses to select which bits of the pixel are to be updated.
This feature eliminates costly read / modify / write operations.
PAX's 32-bit frame buffer architecture exploits these VRAM
features, as well as employs advanced interleaving techniques referred
to as Pixel Interleaving [2] and Load Clock Interleaving to enhance performance.
The architecture supports 1M to 5M bytes of memory which provides the capability
to support screen resolutions ranging from 1024 x 768 to 1280 x 1024. With
2M bytes or more of memory, PAX can support a double buffer display.
The IBM RGB 530 Palette-DAC serves as the video controller.
It provides four color palettes, video output (red, green, blue), display
timings, VRAM serial port control, and two hardware cursors. This device
also provides an on-chip programmable Phase Locked Loop (PLL) which allows
the graphics subsystem to support a wide range of monitors with varying
timing requirements.
As the block diagram and descriptions illustrate, most
of the logic required for the graphics subsystem is integrated into the
PAX and the IBM RGB 530 custom chips. This level of integration is key
to keeping the cost of the subsystem to a minimum while enhancing the performance
and function.
Programming Models
The PAX chip supports two different programming models: Direct Frame
Buffer Access (DFA) and "Poly" commands.
Direct Frame Buffer Access allows the Frame Buffer to be
accessed by the PowerPC 601 processor as if it were part of system memory.
This simplified interface is very effective in reducing the X Window software
development time. X Window software development uses DFA to directly map
the X Window System code received from Massachusetts Institure of Technology
(MIT) into the initial device driver for the adapter. Then, X Window software
development
optimizes the device driver to exploit the hardware accelerated functions.
DFA is also key to the performance of certain X Window commands such as
points, circles, and complex area fills because there is no additional
hardware acceleration provided for these primitives.
The "Poly" command interface provides a rich set
of rendering instructions which complement the DFA programming model. The
word "Poly" refers to the ability to render multiple primitives of the
same type with only one command. The ability to render multiple primitives
with only one command eliminates the overhead of sending a new command
with each primitive. The command set is designed to map closely to the
X Window protocol. The performance of accelerated functions using the "Poly"
command interface is significantly faster than DFA. Some of these accelerated
functions include line draw, area fill, and bit block transfer.
Rendering Engine Architecture
The PAX rendering engine architecture includes rendering functions,
rendering attributes, and 3D Application Programming Interface (API) assist
functions.
Rendering Functions
The PAX architecture consists of several processing units for accelerating
X Window System rendering commands. These processing units are used to
accelerate:
- Line Draw
- Points
- Area Fill
- Bit Block Transfer
See Figure 2 for a block diagram of the internal architecture. These
processing units provide the X Window server (X server) with dedicated
hardware to accelerate the rendering of lines, points, and area fills.
In addition to rendering, PAX also provides assistance for moving pixels
to and from system memory or to and from another screen location. This
function is referred to as Bit Block Transfer (Blits).
Vertices define the boundary of the region to be rendered.
These vertices are included in "Poly" commands. All vertices for these
drawing commands can be sent as 16-bit, two's complement, window relative
coordinates. This 16-bit vertex provides the X server with a 64 K x 64
K virtual screen. The origin of this virtual screen space is at the center,
thus allowing for both positive and negative X and Y addresses.
Line Draw
The line draw engine provides the rasterization of a line
between two points provided by an application. A technique known as Bresenham's
line algorithm [3] is used to render the line. PAX supports two commands
for rendering lines: Poly Line and Poly Segment.
Every vertex sent with the Poly Line command defines a
new line. This is useful for drawing connected lines. The Poly Segment
command requires two vertices to define a line. This command is used to
render multiple non-connecting lines.
The X Window protocol supports styled lines. These are
referred to as OnOffDashed and
DoubleDashed lines [4]. An OnOffDashed line appears as a line with
sections, or dashes, rendered in the foreground color and sections not
rendered. DoubleDashed lines appear as a line with sections rendered in
the foreground color and sections rendered in the background color.
PAX supports a set of dash counters which allow the server
to define a line style with up to 8 unique segments or dashes. The X server
selects between Dashed and Double Dashed by enabling transparent rendering.
The major performance bottleneck for the line generation
logic is the frame buffer. As mentioned earlier, PAX employs Pixel Interleaving
and Load Clock Interleaving to reduce this bottleneck.
Points
Points are rendered using either DFA or "Poly" point commands.
Points are not accelerated since there is no significant processing required
to generate them. Instead, points are provided a fast path through the
hardware so that they are rendered into the frame buffer at the maximum
frame buffer bandwidth.
Area Fill
PAX supports four types of area fills: Spans, Triangles,
Rectangles, and Quadrilaterals. A
unique command is dedicated to each type of area fill operation to
reduce the number of stores required. The Block Write VRAM feature is used
to increase the fill rate for these objects. The Block Write feature allows
PAX to write up to 32 pixels in one memory cycle - four times faster than
normal writes.
Spans are a continuous row of pixels. These are the basic
area fill primitives. All other types of area fills are broken down into
spans by the internal area fill logic.
The triangle and quadrilateral fill logic uses the line
logic and another simpler line generator to find the edges of the area.
Since only two line generators (edge walkers) are available, PAX can only
support quadrilaterals which are convex in the Y direction. See Figure
3 for examples of the
supported and unsupported areas.
Rectangles are a special case of a quadrilateral and are
handled separately. Special casing rectangles provides additional performance
since the overhead of walking the edges is eliminated. This extra performance
is beneficial to window management and clearing areas on the screen.
Quadrilaterals, rectangles, and triangles can
be drawn in one of two modes: X Window compliant or Full Fill. The X Window
mode draws the fill area such that when an object is connected to other
objects along an edge, no pixel is written twice. This is accomplished
by
rendering pixels whose center lies inside the area, on the left or
top edge, but not pixels on the right and bottom edges. Full Fill mode
draws all pixels including the edges.
Figure 3 Area Fill Examples
Bit Block Transfer
Bit Block Transfers (Blits) are a hardware assist for
the movement of blocks of pixel data. PAX supports three types of Blits:
Screen to Screen, System to Screen, and Screen to System. They are used
extensively by the X server to accelerate the movement of windows.
Screen to Screen Blits are used to copy a block of pixels
from one location on the screen to another. PAX automatically handles overlapping
source and destination blocks so that the source block appears correctly
at the destination.
Screen to Screen Blits continuously switch between frame
buffer reads and writes. These transitions drastically reduce the usable
frame buffer bandwidth. PAX has an internal buffer to reduce the number
of transitions which increases the utilization of the frame buffer's bandwidth.
System to Screen and Screen to System Blits are used to
copy pixels between system memory and the frame buffer. There are two modes
of operation for these commands: Direct and Indirect. In Direct mode, system
software controls the pixel transfer from system memory and PAX only controls
the frame buffer address. In Indirect mode, the PAX chip becomes a master
of the PowerPC bus and completes the transfer of data with no processor
intervention. The software in
this case only supplies the source and destination addresses.
PAX supports a special System to Screen Blit mode which
accelerates character performance. When operating in this mode, each bit
of the data sent is interpreted as a pixel. The hardware renders the foreground
color for all the 1s in the data word. The background color is rendered
for all the 0s in the data word if transparency is disabled and nothing
is rendered if transparency is
enabled. With transparency enabled, this function uses the Block Write
VRAM feature.
Rendering Attributes
PAX also supports a variety of rendering attributes. These
attributes can be applied to both the DFA and "Poly" command programming
models. Some of these attributes are listed below.
- Boolean operations
- Window Management
- Stipple
These attributes modify and control the rendering functions by modifying
vertices and pixel generation. Different attributes apply at different
stages in the rendering process.
Boolean Operations
The X Window protocol specifies
the rendered pixel to be a combination of the pixel's current color (destination)
and the source color. One of 16 logical functions can be selected, all
of which are supported by the PAX architecture. Below is a list of the
logical functions.
- Clear (0)
- Set (1)
- Destination (D)(NoOp) - Source (S) (Copy)
- !S
- !D
- S & D
- S | D
- S & !D
- S | !D
- !S & D
- !S | D
- !S & !D
- !S | !D
- S^D
- !(S^D)
By implementing Boolean operations in hardware, the X server
is relieved of the slow task of reading the frame buffer, modifying the
color, and writing the new color to the frame buffer. This function is
extremely important to applications which require Boolean operations.
Windows Management
Applications running under the X Window System request
a window from the X server. The user is free to resize and move these windows
at any time. Since multiple windows may be open on the screen, there is
a possibility a window may be partially obscured by others. It is the X
server's responsibility to manage these windows so that pixels rendered
to the obscured sections are not visible. PAX supports the following functions
which assist the X server:
- Rectangular Clippers
- Clipping Planes
- Window Origin Offset
- Window ID planes
The Rectangular Clipping logic consists of four pairs of
extent registers. Each pair defines a rectangular region with either an
inclusive (all pixels inside the region are rendered) or exclusive (all
pixels inside the region are NOT rendered) attribute. The X server uses
these registers to define the window's geometry to the PAX chip so that
pixels in the obscured sections of the window
are clipped.
Four regions are not always enough to define a window's
geometry. Such is the case when the window is obscured in four or more
unique areas or when shaped (i.e. non rectangular) windows are used. For
these cases, the X server may render the window's geometry to off screen
memory, referred to as clipping planes, with a unique ID. PAX then reads
the pixel's corresponding clip plane value and compares it with the clipping
ID to determine if the pixel should be written to the
frame buffer.
Applications draw using a window relative coordinate system.
Vertices in this system must be converted to screen coordinates before
they can be used to render an object. This conversion is accomplished,
in hardware, by adding the Window Origin Offset to every pixel before it
is rendered. Providing this capability in the PAX chip eliminates
the task of converting the coordinates in software which increases the
rate at which the vertices are sent to PAX. Overall, adding the window
origin offset increases the performance of processor bound primitives such
as points.
Some applications require a different color palette than
the default. If only one palette is available, the colors of other windows
will change when focused on these types of applications. The PAX chip supports
an additional four planes of memory, referred to as Window ID planes, which
allow the X server to select a unique palette on a per pixel basis. These
planes also identify other attributes of the pixels such as: frame buffer
select, pixel type, and overlay plane enable.
Stipple
The X Window protocol allows a fill pattern, such as a
checkerboard, to be applied to the
objects rendered [4]. This pattern is referred to as the Stipple pattern.
The pattern can be transparent or opaque. Transparent patterns result in
the foreground color being rendered where there are 1s in the pattern and
nothing rendered where there are 0s in the pattern. The only difference
for an opaque pattern is that the background color is rendered where there
are 0s in the pattern.
PAX supports a fixed 16 x 16 Stipple pattern. This pattern
is addressed by the four least significant bits of the window coordinate
of the pixel to be rendered. The value at that location is the stipple
value for that pixel. PAX supports stippling for all rendering operations.
Applying a transparent stipple pattern to an area fill
operation does not effect the ability to use the Block Write function.
However, applying an opaque stipple prevents the use of Block Write since
two colors must be rendered (foreground and background). This normally
reduces the performance of large opaque stippled objects by a factor of
approximately four. To prevent such a drastic drop in performance, the
PAX architecture employs a unique feature called Stipple
Invert. This feature allows an opaque stippled object to be rendered
twice using Block Write. The second time it is rendered, the stipple pattern
is inverted and the foreground and background colors are swapped. This
simple feature almost doubles the performance for opaque stippled objects.
3D API Assist Functions
PAX supports a few functions which are intended to enhance
the performance of 3D
Application Programming Interfaces (APIs). These additional functions
are listed below:
- Anti-Aliased Lines
- Sub pixel positioning of lines
- 24-bit RGB to 8-bit RGB Dither
The Anti-Aliased line draw function provides the system
software with the ability to render lines without the familiar problem
of "stair steps" or "jaggies" (i.e. aliasing). This function uses a proprietary
two pixel approximation technique to visually remove the aliasing caused
by the discrete pixels on a raster display.
Sub pixel positioning of lines allows the system software
to more precisely place the anti-aliased lines on the display.
Dithering is a technique which trades spatial resolution
for more color resolution. Essentially a 24-bit color value is converted
to an 8-bit value and then slightly modified based on the pixel's position
in the window. The overall appearance is that the graphics subsystem has
more than 256 colors.
|