This chapter provides a general description and a system overview of the Leo Graphics Accelerator.
The Leo Graphics Accelerator is Sun's high end product that is primarily used for MCAD (Mechanical Computer Aided Design), three-dimensional (3D) Solids Modelling applications. It is optimized to accelerate XGL. XGL is a library of 2D and 3D graphics primitive functions that support a wide variety of graphics-based applications. It is also Sun's foundation engine for geometric APIs, such as PHIGS and GKS.
Leo is a double-wide, double-board-high SBus card. The SBus card is installed in qualified SBus workstations, such as the SPARCstation 10. It includes a connector that is used to connect the workstation to the monitor and a connector that may be used to control stereo shutters or goggles.
In this manual, the SBus workstation is referred to as the Host.
The accelerator can fetch vertex data directly from the Host system memory. This data allows the accelerator to render complex graphics at high speed into its frame buffer with little or no assistance from the Host.
Figure 1-1 shows how the Leo Graphics Accelerator fits into a Host.
The following text briefly describes each of the elements:
Host CPU. The cpu of the SBus workstation that the Leo Graphics Accelerator is installed in. Leo can only be installed in SBus workstations. Note that in workstations that support multiprocessing, there is a second CPU.
System Memory. The system memory is an MBus slave. It contains the usual cpu code and data areas. It also stores Vertex Data that is processed by the Leo Graphics Accelerator.
MBus to SBus Interface. The MBus to SBus Interface allows these two bus to talk to each other.
MBus. The host CPU uses the MBus as a high speed bus to communicate with system memory and with the Leo Graphics Accelerator.
SBus. The SBus is a high performance, byte addressed, 32-bit data-path, synchronous bus. It provides a 32-bit virtual address that allows for Direct Virtual Memory Access (DVMA) by all bus masters. This greatly simplifies software memory management. It also provides a 28-bit physical address for slaves. Leo can generate interrupts on the SBus to inform the Host of various Leo conditions.
I/O Devices. These can be either SBus slaves or masters, such as disk controllers and communications interfaces.
Leo Graphics Accelerator. The accelerator is a special purpose computing pipeline optimized for 3-D graphics. It is both an SBus slave and a DVMA (Direct Virtual Memory Access) master.
For accelerated 3-D graphics, the host CPU builds lists of vertex data in system memory. It then tells the Leo Graphics Accelerator (slave) that the data is ready. The accelerator then becomes a DVMA master, fetches the vertex data directly from system memory, and processes it. While this is taking place, the host CPU is free to perform other tasks.
GT display list code is accelerated using a GT Instruction Set interpreter that runs on the Host. This interpreter outputs vertex data that is stored in system memory and fetched by the accelerator as described above.
The host CPU (as a master) can also perform unaccelerated graphics operations (text or 2-D graphics) by writing directly into the Leo Frame Buffer (slave).
Figure 1-1 Leo Host System Block Diagram
Figure 1-2 shows the block diagram of the Leo SBus card. The individual blocks are described below.
The LeoCommand chip converts chained vertex data in a variety of numeric formats into a small number of isolated drawing primitive. The incoming vertex data contains position data, vertex and facet normal and color information, edge hi-light flags, and chaining information. Normal and color information can be represented as small or medium size fixed point integers, or as single precision floating point numbers. This data is converted into isolated triangle and line commands (all with floating point arguments) within the input fifos of the floating point chips.
The Boot PROM is a 64 Kbyte programmable read-only memory that initializes the Leo Accelerator when the workstation is turned on. The program stored in the Boot PROM is written in the FCode programming language.
The LeoFloat chips convert model space triangles, vectors, and dots into screen space fixed point rendering parameters.
The LeoDraw chips convert triangle, vector, and dot drawing parameters into individual pixel update operations for the attached VRAMs of the frame buffer.
The LeoCross chip performs output pixel multiplexing (buffer and channel selection), pseudo-color look-up, and potential gamma correction. The following monitor resolutions are supported:
Figure 1-2 Leo Block Diagram
Leo communicates with the Host workstation as an SBus slave, a DVMA Master, and by generating interrupts on the SBus. The Host uses the slave interface to directly access Leo memory and devices. Leo uses the DVMA interface to get graphics data from the Host system memory and to move raster data between the frame buffer on the Host system memory. Leo uses interrupt level 5 to inform the Host of various condition in the accelerator.
There are two data paths (see Figure 1-3) between the host and the frame buffer: a direct path and an accelerated path. The direct path allows an application to access the frame buffer directly through LeoCommand and the Render logic. This path is bidirectional. The accelerated path allows an application to access the frame buffer through LeoCommand, the Floating Point Transform logic, and the Render logic. This path is unidirectional.
Figure 1-3 Leo Graphics Accelerator Data Paths
The accelerated path is optimized for 3-D graphics applications. It accepts vertex data (such as triangle strip, polyline, dot) that supports these applications. The direct path to the frame buffer is provided for other applications, such as text update and scroll, and image load and store, which are not accelerated
The direct path to the frame buffer allows the host to bypass the floating point transformations for those applications that are better served by host based software. This includes complex primitives that are not supported through the accelerator port. Tasks such as the X/NeWS window server, ECAD (2-D) graphics, and image processing applications run on the host CPU and use the direct path to the Leo Frame Buffer.
The direct path also allows the host to access other Leo devices, for example to update the status and control registers in the various Leo devices. This path is also used to access the Boot PROM and the look-up tables in the Video Output section.
Leo is an SBus slave when the host uses the direct port to read or write the frame buffer. This is the path used by the window system. Support is provided for rendering text, area moves, and fill.
The accelerated path to the frame buffer goes through the Floating Point Transform section. This path is used to render three basic primitives: dots, vectors, and triangles. The accelerator also can render antialiased dots, antialiased vectors, and triangle strips. Various data formats may be used, which allows such things as chained or isolated data, color information, and packed or floating point normals.
After the Host CPU tells the accelerator that vertex data is ready, LeoCommand normally fetches the pipeline input from system memory using DVMA. LeoCommand converts the chained vertex data into a small number of drawing primitives with floating point coordinates. It than passes these primitive to the Floating Point Transform section, which transforms the data into screen-space, fixed-point rendering parameters and passes its output to the Render section. The Render section converts the rendering parameters into pixel operations for the Frame Buffer. The pixel operations include various blend and transparency operations along with Window ID and Z Buffer checks. The Frame Buffer stores the color, depth, and transparency for each pixel on the display. The contents of the frame buffer are continuously scanned out to the video display monitor.
The data can also be sent to LeoCommand using programmed I/O.
