This chapter is a general overview of the GT Graphics Subsystem.
Figure 1-1 shows a typical Sun SPARCstation 2 with a GT Graphics Subsystem.
Figure 1-1 Typical Sun GT Graphics Subsystem
The GT Graphics Subsystem consists of an SBus card in the system unit, optional color monitor, Graphics Tower, host adapter cable, and video cable.
The GT Graphics Subsystem can use either of two Sun color monitors: a 21- inch monitor or a 19-inch monitor. The 21-inch color monitor provides the best resolution of 1280 by 1024 pixels. Here are some additional specifications on the 21-inch monitor:
The standard Sun 19-inch monitor, which runs 1152 by 900 at 76 Hz, is supported in its 1280 by 1024, 67 Hz mode.
The GT SBus Adapter Board installs in the system unit and interconnects the system unit with the graphics tower. The system unit is the SPARCstation 2.
The Graphics Tower is a deskside enclosure that contains the 3D rendering engine for the GT Graphics Subsystem. The Graphics Tower contains three printed circuit boards (Graphics Processor Front End, Graphics Processor Rendering Pipeline, and Frame Buffer) plus a power supply, fan assembly, cardcage, foreplane connector, and backplane.
Figure 1-2 Graphics Tower Rear View
The power supply and fan assembly, located in the top of the cabinet, is a single module. The assembly diagrams in Chapter 5 show the physical characteristics and location of the 325 watt power supply and the four-fan assembly. Appendix A provides a diagram of the power supply wiring.
The power supply generates four regulated voltages and one unregulated voltage, as listed in Table 1-1.
The power supply voltage test points are shown in Figure A-6 on page 138.
The power convenience module, shown in Figure 1-3, contains the Graphics Tower ON/OFF switch, power indicator, ac line fuse, ac line input connector, and an ac line output connector.
The Graphics Tower fuse is one of two types, depending on the ac line voltage, as follows:
Figure 1-3 Power Convenience Module
The EMI cover protects the foreplane connector. The foreplane connector provides a signal interface between the Frame Buffer and Graphics Processor Rendering Pipeline Boards. The foreplane connector is covered by a foreplane EMI cover. These assemblies are shown in more detail in the assembly diagrams in Chapter 6.
The Frame Buffer Board, shown in Figure 1-4, contains the video connectors. The Frame Buffer is described in more detail later in this chapter. Also, see the Frame Buffer Board interconnect diagram in Appendix A.
Figure 1-4 Frame Buffer Board
The Graphics Processor Rendering Pipeline Board and the Graphics Processor Front End Board are attached and appear as a single assembly. As shown in Figure 1-5, these two boards share a double-wide panel. These boards are described in more detail later in this chapter. Also, see the board interconnect diagrams in Appendix A.
Figure 1-5 Graphics Processor Rendering Pipeline Board and Graphics Processor Front End Board
The graphics engine portion of the GT Graphics Subsystem is a three-board set that enhances the performance of three-dimensional graphics rendering on the Sun SPARCstation.
The GT Graphics Subsystem is used in MCAD, scientific visualization, and animation applications. The GT Graphics Subsystem is primarily a PHIGS+ machine. The SunPHIGS library converts user requests into GT Graphics Subsystem display lists using a SunPHIGS-to-GT compiler. The GT Graphics Subsystem then fetches these compiled instructions, traverses the lists, executes the commands, and sends the refined graphics to the monitor for display.
Figure 1-6 shows both the physical and the functional block diagrams of the GT Graphics Subsystem. The GT Graphics Subsystem consists of:
The GT Graphics Subsystem uses the system unit SBus to allow the Graphics Processor Board to fetch commands directly from system memory by way of virtual memory addressing.
Figure 1-7 shows an overall system block diagram with the four main functional blocks. The individual boards are described following the figure.
The GT Graphics Subsystem is really two systems: a master on the SBus and a slave to the system unit.
The GT Graphics Subsystem master and slave modes are supported on the SBus by the GT SBus Adapter Board. The GT SBus Adapter Board takes up one SBus slot in the system unit.
Figure 1-7 GT Graphics Subsystem Overall Block Diagram
The GT SBus Adapter Board, shown in Figure 1-8, translates SBus accesses from the system unit into the protocol necessary to communicate with the graphics engine over the Host Adapter Cable. The GT SBus Adapter Board also translates accesses from the graphics engine to the SBus protocol.
In the following descriptions, the terms slave or master are used in relationship to the system unit SBus. The terms read and write are used in relationship to the current SBus master.
The SBus access mode, slave or master, determines the data transfer direction. An SBus slave write transfers data to the graphics engine. An SBus master write transfers data from the graphics engine.
An SBus slave transfer occurs when the graphics engine acts as a slave on the SBus, such as when the system unit initializes the graphics engine, when the system unit accesses the frame buffer directly, and during diagnostics. An SBus slave write occurs when the system unit writes to the graphics engine. An SBus slave read occurs when the system unit reads from the graphics engine. The graphics engine supports one-, two-, and four-byte slave read and write transfers.
An SBus master transfer occurs when the graphics engine acts as a DVMA master on the SBus, such as when the graphics engine accesses shared host virtual memory. An SBus master write occurs when the graphics engine writes to memory. An SBus master read occurs when the graphics engine reads system memory. The graphics engine supports four-, pseudo-32-, and 32-byte SBus master read and write transfers, as well as a four-byte swap transfer.
A pseudo 32-byte transfer consists of two back-to-back 16-byte transfers without the graphics engine having to supply a second address.
Figure 1-8 GT SBus Adapter Board Block Diagram
The Graphics Processor Front End Board, shown in Figure 1-9, is a daughter board to the Graphics Processor Rendering Pipeline Board and consists of the following:
After a display list is placed in the system unit virtual memory, the Graphics Processor Front End Board acts as a master device on the SBus and reads the display instructions from memory. After reading in the display instructions, the i860 microprocessor transforms 3D model coordinates to 3D world coordinates to 3D device coordinates (frame buffer location and Z-buffer values).
The i860 also performs lighting calculations, which results in three floating- point numbers: the R, G, and B values for each vertex. These values are a function of the color and surface properties of the primitive, the position of the lights, and the angle at which the light hits the surface. The i860 also clips the image to fit the window. The i860 then passes the results of its processing to the Rendering Pipeline, and the front end is now ready to take the next set of instructions.
The Graphics Processor Rendering Pipeline Board, shown in Figure 1-10, consists of four primary parts:
Transformed coordinates from the front end arrive at the Setup Processor. From the vertices, the Setup Processor calculates various values, such as slopes of triangle sides and the corresponding increments for the RGB color values, to draw the primitive on the screen.
The Setup Processor passes the coordinates and color gradients to the Edge Walker, then the Setup Processor receives the next set of transformed coordinates. The edge walker computes the RGBZ values of each point on the pixel sampling grid and passes the values to the Span Interpolator.
The Span Interpolator interpolates the RGBZ values for the pixels that comprise the span then passes the pixels to the Frame Buffer via the Pixel Bus Multiplexer.
The Frame Buffer Board, shown in Figure 1-11, consists of four primary parts:
Figure 1-11 Frame Buffer Board Block Diagram
The Frame Buffer has two paths: a direct path for applications that have been accelerated by the rendering engine (the Setup Processor, Edge Walker, and Span Interpolator), and an accelerated path for window-system-based applications that have not seen much acceleration in the previous stages.
The Pixel Formatter provides acceleration for the window system. The Pixel Formatter provides no part in geometry acceleration.
Pixels from the Span Interpolator reach the five Pixel Processors, which allow five-way parallel processing of pixels. The Pixel Processors are responsible for raster operations, vector anti-aliasing, alpha transparency, window clipping, picking, fast clear, and Z-buffer algorithms.
The Z value of each pixel from the Span Interpolator is compared to the previous value in the Z buffer. If the new Z value is greater, the previous value is not changed (in this case, the new pixel is part of a surface that is behind what is already showing on the screen). This avoids display of hidden surfaces. If the new Z value is less than or equal to the previous value (the new surface is in front), the Pixel Processor writes the pixel's RGB values to the image planes and updates the contents of the Z buffer.
Each pixel has associated with it a Window ID (WID) number. If the WID does not match the incumbent WID, the pixel belongs to a window currently obscured on the screen, and no writes occur to the video RAM in the Frame Buffer. If the two WIDs match, the video RAM is updated with the new RGB values.
When the traversal of a complete image is completed, the double-buffering is swapped so that the newly-written buffer is displayed.
The Frame Buffer's RGB values go to the DACs, which produce the necessary analog voltage to display the desired color and intensity on the screen.
The Video Memory Array contains 108 planes, as shown in Figure 1-12.
Figure 1-12 Frame Buffer Memory Plane Groups
Image Planes. The 48 image planes are organized as two banks of 24 planes, providing full 24-bit double-buffered color. Each bank has available to it 224 (16.7 million) colors, eight-bits each of red, green, and blue, which can be displayed on the screen. The 24-bit (3 \xb4 8-bit) value is used to access the built- in RAMDAC look-up table.
The GT Graphics Subsystem provides an eight-bit index color compatibility mode, which provides six buffers of eight planes each. The eight bits from the image or overlay planes indexes one of 14 color look-up tables (CLUTs). Each of the 14 CLUTs provide 256 colors at a time from a palette of 16 million. The multiple look-up tables eliminate color map flashing, experienced in other eight- bit indexed systems.
Depth (Z Buffer) Plane. The Z buffer consists of 24 bits that represent the Z depth during modeling. This allows sufficient differentiation in Z values of pixels for accurate model representation.
Overlay Planes. The overlay plane consists of two overlay banks of eight planes each. This is just like an extra eight-bit index color double-buffered frame buffer. Windows present in the overlay planes have window IDs attached to them, allowing them to be made visible or obscured.
Window ID Planes. The ten window ID planes store the window identification code for each pixel in the current image display buffer and in the current image write buffer. During image and Z-buffer writes or overlay buffer writes, the appropriate WID associated with the new value is compared with the incumbent WID. Writes occur only if there is a match. This feature supports fast clipping to overlapping windows and to irregularly shaped windows.
The ten-bit WID also acts as an index into a Window Look-Up Table (WID LUT) to define the windows's display properties:
Fast Clear Planes. The eight fast clear planes are used to rapidly clear the screen between frames so that animation of objects appears smooth. The fast clear planes are organized as four double-buffered pairs to provide the fast clear feature for four selected double-buffered image windows at hardware speeds. Before the start of each new frame, the appropriate fast clear plane is cleared to zeros using special hardware that clears windows of any size in 200 nanoseconds. New pixel values can now be written into the image and Z buffer. As this is done, a "1" is written into the fast clear plane associated with this window indicating that the data is now valid for display.
Cursor Planes. The two cursor planes are divided into a cursor color plane and a cursor enable plane. When enable is set, the image and overlay plane values are ignored and the cursor data plane is displayed. When enable is cleared, the cursor data plane is transparent and either the overlay or the image planes show up on the screen. The one-bit cursor gives two possible colors from a separate cursor Color Look-Up Table (CLUT) located within RAMDACs.
