Floating Point Processor for a Three-Dimensional Graphics Accelerator Which Includes Floating Point, Lighting and Set-Up Cores for Improved Performance

The present invention relates to a 3-D graphics accelerator, and more particularly to an improved floating point processor architecture for a 3-D graphics accelerator which includes floating point, lighting, and set-up cores for improved performance.

A three dimensional (3-D) graphics accelerator is a specialized graphics rendering subsystem for a computer system which is designed to off-load the 3-D rendering functions from the host processor, thus providing improved system performance. In a system with a 3-D graphics accelerator, an application program executing on the host processor of the computer system generates three dimensional geometry data that defines three dimensional graphics elements for display on a display device. The application program causes the host processor to transfer the geometry data to the graphics accelerator. The graphics accelerator receives the geometry data and renders the corresponding graphics elements on the display device.

The design architecture of a high performance three dimensional graphics system historically embodies a balance between increasing system performance and minimizing system cost. However, prior graphics systems usually suffer from either limited performance or high cost due to a variety of system constraints.

Applications which display three dimensional graphics require a tremendous amount of processing capabilities. For example, for a computer system to generate smooth 3-D motion video, the computer system is required to maintain a frame rate or update rate of between 20 to 30 frames per second. This requires a 3-D computer graphics accelerator capable of processing over a million triangles per second.

In general, 3-D computer graphics accelerators have had three major bottleneck points which limit performance. A first bottleneck is the requirement that geometric rendering primitives, e.g., lines and triangles, be transferred from the main system memory on the host computer to the graphics accelerator. The operation of the host processor memory system and system bus on which the data is transferred can limit the transfer rate of these geometric rendering primitives from the host memory to the 3-D accelerator. A second bottleneck is the vertex processing requirements, including transformation, lighting, set-up, etc. inside the accelerator. A third bottleneck is the speed at which pixels from primitives can be filled into the frame buffer.

In order to build a higher performance 3-D graphical architecture, the throughput of all the above three areas must increase. As mentioned above, one of the main bottlenecks in 3-D graphics architectures has traditionally been the speed at which pixels from primitives are filled into the frame buffer memory. Systems have traditionally used dual ported video RAM (VRAM) or interleaved DRAM in attempts to achieve higher throughput. A new type of video memory referred to as 3DRAM increases the pixel throughput rate by an order of magnitude. With use of 3DRAM in a graphics accelerator system, the 3-D rendering bottleneck no longer resides at the fill rate at which pixels from primitives are filled into the frame buffer. Rather, with the use of 3DRAM, the performance bottleneck typically comprises either the transfer rate of geometry data on the system bus or the 3-D graphics accelerator processing, including the vertex processing. Therefore, a new 3-D graphics accelerator architecture is desired which provides increased floating point performance.

A 3-D graphics accelerator is generally required to perform a large number of floating point operations, including vertex position transformations, clip testing, lighting, and set-up computations, among others. In general, the floating point operations performed by a 3-D graphics accelerator is in many cases the bottleneck of the graphics acceleration process. Therefore, some 3-D graphics accelerators include a specialized or dedicated floating point processor which is designed to perform all of the required floating point operations.

U.S. Pat. No. 5,517,611 to Deering, which is assigned to Sun Microsystems, discloses a floating point processor for a 3-D graphics accelerator according to the prior art. As shown, this prior art floating point processor includes a plurality of floating point units which each implement a parallel floating-point multiplier, a parallel floating-point ALU, parallel floating-point iterative reciprocal circuit, reciprocal square root circuitry, and a parallel integer ALU. The floating point processor described in U.S. Pat. No. 5,517,611 performs all of the transform, lighting and set-up computations in one programmable unit. However, current 3-D graphics applications require even greater performance, including greater floating point performance. Therefore, an improved floating point processor architecture is desired which provides increased performance over prior art designs.

The present invention comprises a floating point processor for a 3-D graphics accelerator which includes improved performance over prior art designs. The floating point processor includes three specialized engines or function units which streamline floating point operations and which provide improved performance over prior systems. In the preferred embodiment, the floating point processor comprises a floating point core (F-core), a lighting core (L-Core), and a set-up core (S-core). Computations for triangles and vectors are split over the three function units for improved efficiency.

The F-core processor receives geometry primitive data and performs floating point operations on the received geometry data. The F-core processor performs operations such as transforming vertex positions from model space to view space, performing clipping operations on received geometry data, performing perspective division to convert received vertex information to screen space, and determining if a triangle is front-facing or back-facing. The F-core processor also performs some lighting operations.

The L-Core processor comprises a fixed point computational unit for performing lighting computations. The lighting core is coupled to receive output data from the floating point core and is also coupled to receive primitive data directly from the bus interface. The L-core processor is designed specifically to perform lighting calculations. In the preferred embodiment, the L-core processor performs most of the lighting operations. The F-core block performs lighting computations for more complex light sources, such as point and spot light sources.

The set-up core comprises a fixed point computational unit for performing set-up calculations for geometric primitives. The set-up calculations include sorting the three vertices of a triangle in ascending y order for draw processing. The set-up core receives an output from the lighting core and the floating point core and provides an output to draw processors.

Therefore, the present invention comprises an improved floating point processor for a three-dimensional graphics accelerator which includes three separate processing units for improved performance.

A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:

FIG. 1 illustrates a computer system which includes a three dimensional (3-D) graphics accelerator according to the present invention;

FIG. 2 is a simplified block diagram of the computer system of FIG. 1;

FIG. 3 is a block diagram illustrating the 3-D graphics accelerator according to the preferred embodiment of the present invention;

FIG. 4 is a block diagram illustrating a portion of the 3-D graphics accelerator of FIG. 3;

FIG. 5 is a block diagram illustrating the command preprocessor in the 3-D graphics accelerator according to the preferred embodiment of the present invention;

FIG. 6 is a block diagram illustrating one of the floating point processors in the 3-D graphics accelerator according to the preferred embodiment of the present invention;

FIG. 7 is a block diagram illustrating one of the draw processors in the 3-D graphics accelerator according to the preferred embodiment of the present invention;

FIG. 8 is a block diagram illustrating the CF bus connecting the command preprocessor to each of the floating point processors;

FIG. 9 is a block diagram illustrating the FD bus connecting each of the floating point processors to each of the draw processors;

FIG. 10 is a block diagram illustrating the CDC bus connecting the command preprocessor to each of the draw processors;

FIG. 11 is a block diagram illustrating the F-Core block;

FIG. 12 is a block diagram illustrating the L-Core block; and

FIG. 13 is a block diagram illustrating the S-Core block;

Referring now to FIG. 1, a computer system 80 which includes a three-dimensional (3-D) graphics accelerator according to the present invention is shown. As shown, the computer system 80 comprises a system unit 82 and a video monitor or display device 84 coupled to the system unit 82. The display device 84 may be any of various types of display monitors or devices. Various input devices may be connected to the computer system, including a keyboard 86 and/or a mouse 88, or other input. Application software, represented by floppy disks 90, may be executed by the computer system 80 to cause the system 80 to display 3-D graphical objects on the video monitor 84. As described further below, the 3-D graphics accelerator in the computer system 80 enables the display of three dimensional graphical objects with improved performance.

Referring now to FIG. 2, a simplified block diagram illustrating the computer system of FIG. 1 is shown. Elements of the computer system which are not necessary for an understanding of the present invention are not shown for convenience. As shown, the computer system 80 includes a central processing unit (CPU) 102 coupled to a high speed bus or system bus 104. A system memory 106 is also preferably coupled to the high speed bus 104.

The host processor 102 may be any of various types of computer processors, multi-processors and CPUs. The system memory 106 may be any of various types of memory subsystems, including random access memories and mass storage devices. The system bus or host bus 104 may be any of various types of communication or host computer buses for communication between host processors, CPUs, and memory subsystems, as well as specialized subsystems. In the preferred embodiment, the host bus 104 is the UPA bus, which is a 64 bit bus operating at 83 MHz.

A 3-D graphics accelerator 112 according to the present invention is coupled to the high speed memory bus 104. The 3-D graphics accelerator 112 may be coupled to the bus 104 by, for example, a cross bar switch or other bus connectivity logic. It is assumed that various other peripheral devices, or other buses, may be connected to the high speed memory bus 104, as is well known in the art. As shown, the video monitor or display device 84 connects to the 3-D graphics accelerator 112.

The host processor 102 may transfer information to and from the graphics accelerator 112 according to a programmed input/output (I/O) protocol over the host bus 104. In the preferred embodiment, data is transferred from the system memory 106 to the graphics accelerator 112 using a CPU copy (bcopy) command. In an alternate embodiment, the graphics accelerator 112 accesses the memory subsystem 106 according to a direct memory access (DMA) protocol.

A graphics application program executing on the host processor 102 generates geometry data arrays containing three dimensional geometry information that define an image for display on the display device 84. The host processor 102 transfers the geometry data arrays to the memory subsystem 106. Thereafter, the host processor 102 operates to transfer the data to the graphics accelerator 112 over the host bus 104, preferably using the bcopy command. Alternatively, the graphics accelerator 112 reads in geometry data arrays using DMA access cycles over the host bus 104. In another embodiment, the graphics accelerator 112 is coupled to the system memory 106 through a direct port, such as the Advanced Graphics Port (AGP) promulgated by Intel Corporation.

The three dimensional geometry information in the geometry data arrays comprises a stream of input vertex packets containing vertex coordinates (vertices), vertex position, and other information that defines triangles, vectors and points in a three dimensional space, which is commonly referred to as model space. Each input vertex packet may contain any combination of three dimensional vertex information, including vertex position, vertex normal, vertex color, facet normal, facet color, texture map coordinates, pick-id's, headers and other information.

Referring now to FIG. 3, a block diagram is shown illustrating the 3-D graphics accelerator 112 according to the preferred embodiment of the present invention. FIG. 4 is a more detailed diagram illustrating a portion of the 3-D graphics accelerator 112. As shown, the 3-D graphics accelerator 112 is principally comprised of a command preprocessor or command block 142, a set of floating-point processors or floating point blocks 152A-152F, a set of draw processors or draw blocks 172A and 172B, a frame buffer comprised of 3DRAM, and a random access memory/digital-to-analog converter (RAMDAC) 196.

As shown, the 3-D graphics accelerator 112 includes command block 142 which interfaces to the memory bus 104. The command block 142 interfaces the graphics accelerator 112 to the host bus 104 and controls the transfer of data between other blocks or chips in the graphics accelerator 112. The command block 142 also pre-processes triangle and vector data and performs geometry data decompression, as described further below.

The command block 142 interfaces to a plurality of floating point blocks 152. The 3-D graphics accelerator 112 preferably includes up to six floating point blocks labeled 152A-152F, as shown. The floating point blocks 152A-152F receive high level drawing commands and generate graphics primitives, such as triangles, lines, etc. for rendering three-dimensional objects on the screen. The floating point blocks 152A-152F perform transformation, clipping, lighting and set-up operations on received geometry data. Each of the floating point blocks 152A-152F connects to a respective memory 153A-153F. The memories 153A-153F are preferably 32k.times.36-bit SRAM and are used for microcode and data storage.

The command block 142 interfaces to the floating blocks 152A-152F through a plurality of point-to-point buses or direct data channels, labeled 154A-154F. Thus, the command block 142 includes a direct channel to each of the respective floating point blocks 152A-152F. The plurality of point-to-point buses or direct data channels 154A-154F are each preferably unidirectional 8 bit buses operating at 100 MHz. The direct data channels 154A-154F collectively comprise 48 bits, and the direct data channels 154A-154F are collectively referred to as the CF-bus (Command/Float bus). Data transfers across the CF-bus comprise 48 bit transfers performed over 6 cycles, with the start of the transfer synchronized among the six separate buses.

As discussed further below, the CF-bus also includes 9 additional bits which combine with three of the 8 bit buses to form a 33 bit bus, referred to as the CD bus (FIGS. 8-10). As shown in FIGS. 3 and 4, the buses 154A, 154B, and 154C collectively comprise the CD bus and are 11 bit buses, wherein each comprises an 8 bit bus plus 3 additional bits. The CD bus is a direct unidirectional bus from the command block 142 to draw blocks 172A and 172B. The CD bus "borrows" cycles and data lines from the CF-bus 154 to rapidly send 32 bit data from the command block 142 to the draw blocks 172A and 172B using data paths in three of the floating point blocks 152A-152C as a conduit.

As shown, the command block 142 includes separate FIFO buffers 144A-F which correspond to each of the respective channels 154A-F. These FIFO buffers 144 are used to store or buffer data before the data is transmitted on the respective channel 154A-F to the respective floating point block 152A-F. As shown, each floating point block 152A-F includes a respective input FIFO buffer 155A-155F coupled to receive data from the respective channel 154A-F.

Each of the floating point blocks 152A-F connects to each of two drawing blocks 172A and 172B. The 3-D graphics accelerator 112 preferably includes two draw blocks 172A and 172B, although a greater or lesser number may be used. The draw or rendering blocks 172A and 172B perform screen space rendering of the various graphics primitives and operate to sequence or fill the completed pixels into the 3DRAM array. The draw or rendering blocks 172A and 172B also function as 3DRAM control chips for the frame buffer. The draw processors 172A and 172B concurrently render an image into the frame buffer 100 according to a draw packet received from one of the floating-point processors 152A-152F, or according to a direct port packet received from the command preprocessor 142.

Each of the floating point blocks 152A-F connect to the two drawing blocks 172A and 172B through respective point-to-point buses or direct data channels 162A-162F and 164A-164F. As shown, each of the floating point blocks 152A-F include a respective first direct channel 162A-F to the drawing block 172A, and each of the floating point blocks 152A-F include a respective second channel 164A-F to the other drawing block 172B. Thus, each of the floating point blocks 152A-F includes a direct channel to each of the drawing blocks 172A and 172B. The plurality of point-to-point buses or direct data channels 162A-162F and 164A-164F are each unidirectional 11 bit buses operating at 100 MHz.

Thus the graphics accelerator 112 includes two sets of 6 11-bit buses, providing independent paths from each floating point block 152A-F to each draw processor 172A and 172B. The direct data channels 154A-154F collectively comprise 48 bits, and the direct data channels 162A-F and 164A-F are collectively referred to as the FD-bus (Float/Draw bus).

Each of the floating point blocks 152A-F preferably operates to broadcast the same data to the two drawing blocks 172A and 172B. In other words, the same data is always on both sets of data lines coming from each floating point block 152. Thus, when the floating point block 152A transfers data, the floating point block 152A transfers the same data over both channels 162A and 164A to the draw processors 172A and 172B.

Data is transferred on the FD bus 32 bits at a time using three cycles, with no synchronization between the six separate buses. The 33.sup.rd bit of each transfer is a control bit, which is set to 1 to indicate the last word of the primitive being transferred. In some instances, the outputs from three of the floating point blocks 152A-152C are "borrowed" for a 33 bit (32 data, 1 control) CD-bus cycle, as described above.

As shown in FIG. 4, each of the floating point blocks 152A-F include output FIFO buffers 158A-F which are coupled to each of the respective channels 162A-F and 164A-F. Likewise, each of the respective drawing blocks 172A and 172B include input FIFO buffers 182 and 184, respectively. As shown in FIG. 9, the drawing block 172A includes input FIFO buffers 182A-F for coupling to the respective channels 162A-F. Likewise, the drawing block 172B also includes respective FIFO buffers 184A-F (not shown) for coupling to the respective channels 164A-F.

The graphics accelerator 112 includes two unidirectional buses referred to as the CD bus (FIG. 10) and the DC bus 173 for data transfers between the command processor 142 and the draw processors 172A and 172B. The CD bus is a unidirectional bus for transfers from the command processor 142 to the draw processors 172A and 172B. As discussed above, the CD bus is partially comprised in three of the respective floating point blocks 152A-152C. The CD bus utilizes or "borrows" cycles and wires from the CF-bus, the three floating point blocks 152A-152C, and the FD bus. The DC bus 173 is a unidirectional bus for transfers from the draw processors 172A and 172B to the command processor 142, as shown in FIGS. 3 and 4. The CD bus and the DC bus are more clearly illustrated in FIG. 10.

Each of the respective drawing blocks 172A and 172B couple to a frame buffer, wherein the frame buffer comprises four banks of 3DRAM memory 192A-B, and 194A-B. The draw block 172A couples to the two 3DRAM banks 192A and 192B, and the draw block 172B couples to the two 3DRAM banks 194A and 194B, respectively. Each bank comprises three 3DRAM chips, as shown. The 3DRAM memories or banks 192A-B and 194A-B collectively form the frame buffer, which is 1280.times.1024 by 96 bit deep. The frame buffer stores pixels corresponding to 3-D objects which are rendered by the drawing blocks 172A and 172B.

Each of the 3DRAM memories 192A-B and 194A-B coupled to a RAMDAC (random access memory digital-to-analog converter) 196. The RAMDAC 196 comprises a programmable video timing generator and programmable pixel clock synthesizer, along with cross-bar functions, as well as traditional color look-up tables and triple video DAC circuits. The RAMDAC in turn couples to the video monitor 84.

The graphics accelerator 112 further includes a bi-directional bus 195, referred to as the CM bus, for connecting the command block 142 and the RAMDAC 196. As shown, a Boot PROM 197 and an Audio block 198 are coupled to the CM bus 195. The CM bus 195 preferably operates at 25 MHz.

The command block is preferably implemented as a single chip. Each of the "floating point blocks" 152 are preferably implemented as separate chips. In the preferred embodiment, up to six floating point blocks or chips 152A-F may be included. Each of the drawing blocks or processors 172A and 172B also preferably comprise separate chips.

As discussed above, the 3-D graphics accelerator architecture of the present invention includes a plurality of direct channels between the command block 142 and each of the floating point blocks 152A-F, as well as a plurality of direct channels between each of the floating point blocks 152A-F and the respective drawing blocks 172A and 172B.

As discussed in the background section, prior art architectures have included a common bus connecting these elements. However, the command block 142 generally operates to send separate data to each of the floating point blocks 152A-152F, generally in a round robin fashion. In other words, the command logic 142 generally operates to provide a burst transfer of data to only one of the floating point blocks 152, such as floating point block 152A, and then provide a burst data transfer to another of the floating point blocks, such as 152B, and so on. This burst nature of data transfer also occurs between each of the floating point blocks 152A-F and the two drawing blocks 172A and 172B. In other words, each of the respective floating point blocks 152A-152F generally provides respective individual burst data transfers to each of the drawing blocks 172A and 172B.

The plurality of direct data channels or point-to-point buses perform the burst data transfers between the command block 142 and each of the floating point blocks 152A-152F. The plurality of direct data channels or point-to-point buses also perform the burst data transfers between each of the floating point blocks 152A-152F and the draw processors 172A and 172B. The use of direct data paths instead of a shared bus enables the use of a number of smaller data paths, e.g., 8 bit data paths, while providing similar bandwidth to prior art designs. The use of these smaller direct data paths also provides better electrical characteristics for the graphical architecture. First, the direct data channel output pins on the command chip are only required to drive a single device, as opposed to driving multiple devices in a shared bus architecture. Also, each of the floating point processors 152A-152F have a reduced number of pins, since each only connects to an 8 bit bus. Further, the direct data paths provide improved connectivity between multiple boards. The improved electrical characteristics also enable the user of higher clock speeds, thus providing increased transfer bandwidth.

In some instances, the command block 142 is required to send the same data to each of the floating point blocks 152A-152F. For example, if the command block 142 is required to send matrix data followed by a plurality of triangle data, and each of the subsequent triangles require use of the matrix data, then the matrix data is first required to be transferred to each of the floating point blocks 152A-152F before any of the subsequent triangles are sent to any of the respective floating point units. In other words, a floating point block 152 cannot be allowed to receive one of these subsequent triangles until the respective matrix, which is required to process the triangle, has already been received.

When the command block 142 is required to send the same data to each of the floating point blocks 152A-152F, then the command block 142 is required to wait for all of the FIFOs 144A-144F to be empty and/or for there to be sufficient room in the respective FIFOs for this common transfer to occur. Thus, when the command block 142 is required to send the same data, i.e., broadcast data in parallel, to each of the floating point blocks 152A-152F, the command block 142 is required to wait for each of the FIFOs 144A-144F to have sufficient room in their FIFOs and is required to transfer the same data to each of the FIFOs 144A-144F. It is noted that this broadcast transfer may occur at a reduce transfer rate of a prior art system employing a common bus. However, these common transfers are generally infrequent and do not adversely effect system performance.

The floating point blocks 152A-152F may not necessarily output triangles in the exact order that these triangles are received by the command block 142. It is noted that it is generally not necessary to maintain the exact serial ordering of the received triangles. In the preferred embodiment, the 3-D graphics accelerator architecture includes a first mode where exact serial ordering of the received triangles is not maintained. The system also includes a second mode, wherein the floating point blocks 152A-152F are configured to output rendered triangles in the exact order that these triangles are received by the command block 142.

Therefore, the system and method of the present invention provides a plurality of direct channels or point-to-point buses between the command block 142 and each of the floating point blocks 152A-F. The system and method of the present invention also provides a plurality of direct channels or point-to-point buses between the floating point blocks 152A-152F and each of the drawing blocks 172A and 172B. In other words, the present invention provides a plurality of dedicated narrow buses, preferably 8-bit data buses, which connect the command block 142 to each of the floating point blocks 152A-F, as well as a plurality of narrow buses, preferably 8-bit buses, which connect each of the floating point blocks 152A-F to each of the drawing blocks 172A and 172B. Thus, the present invention does not includes a common bus or shared bus architecture for connectivity, but rather includes direct interconnections between each of the logical elements. This provides improved electrical characteristics and reduced pin requirements, and also facilitates higher clock speeds, thus providing improved performance over prior art designs.

As discussed above, the command preprocessor or command block 142 is coupled for communication over the host bus 104. The command preprocessor 142 receives geometry data arrays transferred from the memory subsystem 106 over the host bus 28 by the host processor 102. In the preferred embodiment, the command preprocessor 142 receives data transferred from the memory subsystem 106, including both compressed and non-compressed geometry data. When the command preprocessor 142 receives compressed geometry data, the command preprocessor 142 operates to decompress the geometry data to produce decompressed geometry data.

The command preprocessor 142 preferably implements two data pipelines, these being a 3D geometry pipeline and a direct port pipeline. In the direct port pipeline, the command preprocessor 142 receives direct port data over the host bus 104, and transfers the direct port data over the command-to-draw (CD) bus to the draw processors 172A-172B. As mentioned above, the CD bus uses or "borrows" portions of other buses to form a direct data path from the command processor 142 to the draw processor 172A-172B. The direct port data is optionally processed by the command preprocessor 142 to perform X11 functions such as character writes, screen scrolls and block moves in concert with the draw processors 172A-172B. The direct port data may also include register writes to the draw processors 172A-172B, and individual pixel writes to the frame buffer 3DRAM 192 and 194.

In the 3D geometry pipeline, the command preprocessor 142 accesses a stream of input vertex packets from the geometry data arrays.

When the command preprocessor 142 receives a stream of input vertex packets from the geometry data arrays, the command preprocessor 142 operates to reorder the information contained within the input vertex packets and optionally delete information in the input vertex packets. The command preprocessor 142 preferably converts the received data into a standard format. The command preprocessor 142 converts the information in each input vertex packet from differing number formats into the 32 bit IEEE floating-point number format. The command preprocessor 142 converts 8 bit fixed-point numbers, 16 bit fixed-point numbers, and 32 bit or 64 bit IEEE floating-point numbers. For normal and color values, the command pre-processor 142 may convert the data to a fixed point value.

The command preprocessor 142 also operates to accumulate input vertex information until an entire primitive is received. The command preprocessor 142 then transfers output geometry packets or primitive data over the command-to-floating-point (CF) bus to one of the floating-point processors 152A-152F. The output geometry packets comprise the reformatted vertex packets with optional modifications and data substitutions.

Referring now to FIG. 5, a block diagram illustrating the command processor or command block 142 is shown. As shown, the command block 142 includes input buffers 302 and output buffers 304 for interfacing to the host bus 104. The input buffers 302 couple to a global data issuer 306 and address decode logic 308. The global data issuer 306 connects to the output buffers 304 and to the CM bus and performs data transfers. The address decode logic 308 receives an input from the DC bus as shown. The address decode logic 308 also couples to provide output to an input FIFO buffer 312.

In general, the frame buffer has a plurality of mappings, including an 8-bit mode for red, green and blue planes, a 32-bit mode for individual pixel access, and a 64-bit mode to access the pixel color together with the Z buffer values. The boot prom 197, audio chip 198 and RAMDAC 196 also have an address space within the frame buffer. The frame buffer also includes a register address space for command block and draw processor registers among others. The address decode logic 308 operates to create tags for the input FIFO 312, which specify which logic unit should receive data and how the data is to be converted. The input FIFO buffer 312 holds 128 64-bit words, plus a 12-bit tag specifying the destination of data and how the data should be processed.

The input FIFO 312 couples through a 64-bit bus to a multiplexer 314. Input FIFO 312 also provides an output to a geometry decompression unit 316. As discussed above, the command block 142 receives both compressed and non-compressed geometry data. The decompression unit 316 receives the compressed geometry data and operates to decompress this compressed geometry data to produce decompressed geometry data. The decompression unit 316 receives a stream of 32-bit words and produces decompressed geometry or primitive data. Then decompressed geometry data output from the decompression unit 316 is provided to an input of the multiplexer 314. The output of the multiplexer 314 is provided to a format converter 322, a collection buffer 324 and register logic 326. In general, the decompressed geometry data output from the decompression unit is provided to either the format converter 322 or the collection buffer 324.

In essence, the geometry decompression unit 316 can be considered a detour on the data path between the input FIFO 312 and the next stage of processing, which is either the format converter 322 or the collection buffer 324. For data received by the command processor 142 which is not compressed geometry data, i.e., non-compressed data, this data is provided from the input FIFO 312 directly through the multiplexer 314 to either the format converter 322, the collection buffer 324, or the register logic 326. When the command processor 142 receives compressed geometry data, this data must first be provided from the input FIFO 312 to the geometry decompression unit 316 to be decompressed before being provided to other logic.

Thus, the command block 142 includes a first data path coupled to the input buffers 302 or input FIFO 312 for transferring the non-compressed geometry data directly through the multiplexer 314 to either the format converter 322 or the collection buffer 324. The command block 142 also includes a second data path coupled to the input buffers 302 or input FIFO 312 for receiving compressed geometry data. The second data path includes a geometry decompression unit coupled to an output of the input FIFO 312 for receiving and decompressing the compressed geometry input data to produce decompressed geometry input data.

The format converter 322 receives integer and/or floating point data and outputs either floating point or fixed point data. The format converter 322 provides the command processor 142 the flexibility to receive a plurality of different data types while providing each of the floating block units 152A-152F with only a single data type for a particular word.

The format converter 322 provides a 48-bit output to a vertex accumulation buffer 332. The vertex accumulation 332 in turn provides an output to vertex buffers 334. The vertex accumulation buffer 332 and the vertex buffers 334 provide outputs to the collection buffer 324, which in turn provides an output back to the output buffers 304.

The vertex accumulation buffer 332 is used to store or accumulate vertex data required for a primitive that is received from the format converter 322. The vertex accumulation buffer 332 actually comprises two sets of registers, i.e., is double buffered. The first set of registers is used for composing a vertex, and the second set of registers is used for copying the data into one of the vertex buffers 334. As discussed further below, these two sets of registers allow for more efficient operation. Data words are written one at a time into the first or top buffer of the vertex accumulation buffer 332, and these values remain unchanged until a new value overwrites the respective word. Data is transferred from the first set of registers to the second set of registers in one cycle when a launch condition occurs.

The vertex buffers 334 are used for constructing or "building up" geometric primitives, such as lines, triangles, etc. Lines and triangles require two and three vertices, respectively, to complete a primitive. According to one embodiment of the invention, new primitives may be created by replacing a vertex of an existing primitive when the primitive being created shares one or more vertices with the prior created primitive. In other words, the vertex buffers 334 remember or maintain previous vertex values and intelligently reuse these vertex values when a primitive or triangle shares one or more vertices or other information with a neighboring primitive or triangle. This reduces the processing requirements and makes operation of the Open GL format operate more efficiently. In the preferred embodiment, the vertex buffers 334 can hold up to seven vertices. This guarantees maximum throughput for the worse case primitive, i.e., independent triangles. The vertex buffers 334 also operate at optimum speed for dots, lines and triangles and is substantially optimal for quad primitives.

Each of the vertex accumulation buffer 332 and the vertex buffers 334 are coupled to a collection buffer 324. The collection buffer 324 provides respective outputs to the output buffers 304 as shown. The vertex buffers 334 are coupled to provide outputs to CF bus output FIFOs 144. The collection buffer 324 is also coupled to provide outputs to the CF bus output FIFOs 144. The collection buffer 324 is used for sending all non-geometric data to the floating point blocks 152A-152F. The collection buffer 324 can hold up to 32 32-bit words. It is noted that the operation of copying data into the CF-bus output FIFOs 144 may be overlapped with the operation of copying new data into the collection buffer 324 for optimal throughput.

As mentioned above, the command block 142 includes a plurality of registers 326 coupled to the ouput of the multiplexer 314. The registers 326 also provide an output to the UPA output buffers 304. Register block 326 comprises 16 control and status registers which control the format and flow of data being sent to respective floating point blocks 152A-152F.

Each of the vertex buffers 334 and the collection buffer 324 provides a 48-bit output to CF-bus output FIFOs 144. The CF-bus output FIFOs 144 enable the command block 142 to quickly copy a primitive from the vertex buffers 334 into the output FIFO 144 while the last of the previous primitive is still being transferred across the CF-bus. This enables the graphics accelerator 112 to maintain a steady flow of data across each of the point-to-point buses. In the preferred embodiment, the CF-bus output FIFOs 144 have sufficient room to hold one complete primitive, as well as additional storage to smooth out the data flow. The CF output FIFOs 144 provide respective 8-bit outputs to a bus interface block 336. The bus interface 336 is the final stage of the command processor 142 and couples to the CF-bus as shown. In addition, the CF/CD bus interface 336 provides "direct port" accesses to the CDC bus which are multiplex on the CF-bus as mentioned above.

The command block 142 also includes round robin arbitration logic 334. This round robin arbitration logic 334 comprises circuitry to determine which of the respective floating point processors 152A-152F is to receive the next primitive. As discussed above, the graphics accelerator 112 of the present invention comprises separate point-to-point buses both into and out of the respective floating point processors 152A-152F. Thus, the round robin arbitration logic 334 is included to distribute primitives evenly between the chips and thus maintain an even flow of data across all of the point-to-point buses simultaneously. In the preferred embodiment, the round robin arbitration logic 334 utilizes a "next available round robin" arbitration scheme, which skips over a sub-bus that is backed up, i.e., full.

For information on another embodiment of the command processor 142, please see U.S. Pat. No. 5,408,605 titled "Command Preprocessor for a High Performance Three Dimensional Graphics Accelerator", which is hereby incorporated by reference in its entirety.

Referring now to FIG. 6, a block diagram illustrating one of the floating point blocks or processors 152 according to the preferred embodiment of the present invention is shown. Each of the respective floating point processors 152A-152F are identical, and thus only one is described here for convenience. As shown, each of the floating point blocks 152 includes three main functional units or core processors, these being F-core 352, L-core 354, and S-core 356. The F-core block 352 is coupled to receive data from the CF-bus transferred from the Command block 142. The F-core block 352 provides output data to each of the L-core block 354 and the S-core block 356. The L-core block 354 also provides data to the S-core block 356. The S-core block 356 provides output data to the FD bus.

The F-core block 352 performs all floating point intensive operations, including geometry transformation, clip testing, face determination, perspective division, and screen space conversion. The F-core block 352 also performs clipping when required. In the preferred embodiment, the F-core block 352 is fully programmable, using a 36-bit micro instruction word stored in a 32k word SRAM.

The L-core block 354 performs substantially all lighting calculations using on-chip RAM-based microcode. Lighting calculations are tuned for the color to vertex format. The L-core block 354 block also includes an efficient triple-word design for more efficient lighting calculations. This triple-word design operates with a 48-bit data word comprising 16-bit fixed point values. Thus one instruction can perform the same function on all three color components (RGB) are all three components of a normal (N.sub.x, N.sub.y, and N.sub.z) in one cycle. The math units comprised in the L-core block 354 automatically clamp values to the allowed ranges, thus allowing no additional branches.

The S-core block performs setup calculations for all primitives. These set-up calculations involve computing the distances in multiple dimensions from one vertex to another and calculating slopes along that edge. For triangles, the slopes of the Z depth, the color, and the UV (for texture) are also computed in the direction of a scan line.

As shown, each of the floating point blocks 152 includes CF-bus interface logic 362 which couples to the CF-bus. Each of the floating point blocks 152 includes FD-bus interface logic 366 which couples to the FD-bus. Each floating point block 152 includes a bypass bus or data path 364 which serves as the data transfer path through a respective floating point block 152 for the CD bus. Data which is sent over the CD bus, i.e., which is sent directly to the FD bus, travels on the data transfer bus 364, thus bypassing the floating point logic comprised in the floating point block 152. The operation of this bypass bus 364 is shown more clearly in FIG. 10 and is discussed in conjunction with FIG. 10.

In general, data which is provided to the floating point block 152 can have one of three destinations, these being the F-core block 352, the L-core block 354, or directly out to the FD bus, i.e., a CD bus transfer. In the preferred embodiment, data which is destined for the F-core block 352 comprises 32-bit words, including 32-bit IEEE floating point numbers and other 32-bit data. Data destined for the L-core block 354 comprises 48-bit words comprising three 16-bit fixed point numbers.

As shown in FIG. 6, the floating point block 152 includes six combined input and output buffers, as well as two specialized buffers which provide communication between the F-core block 352 and the L-core block 354.

As shown, the floating point block 152 includes a float input buffer (FI buffer) 372 which receives data from the CF-bus which was provided by the command block 142. The FI buffer 372 is double buffered and holds 32 32-bit entries in each buffer. The first word, word zero, stored in the FI buffer 372 comprises an op code which informs the F-core block 352 which microcode routine to dispatch for the received geometric primitives. Only the header and X, Y and Z coordinates are provided to this buffer.

The floating point block 152 also includes an F-core to L-core buffer (FL buffer) 374. The FL buffer 374 is double buffered and holds 16 16-bit entries in each buffer. The F-core block 352 operates to write or combine three F-core words into one L-core word which is provided to the FL buffer 374. From the L-core perspective, each buffer in the FL buffer 374 appears as five 48-bit entries. During lighting operations, three X, Y, Z coordinates are sent from the F-core block 352 through the FL buffer 374 to the L-core block 354. These three X, Y, Z coordinates are used to compute lighting direction. When lighting attributes are written, however, five separate values are sent from the F-core block 352 to the L-core block 354 through the FL buffer 374, these five values being values for emission, ambient, diffuse, specular and specular exponent variables.

The floating point block 152 includes an L-core input buffer (LI buffer) 376 which receives data sent across the CF-bus which was provided from the command block 142 and provides this data to the L-core block 354. The LI buffer 376 comprises five buffers, each of which hold seven 48-bit entries. These seven 48-bit entries comprise three vertex normals, three vertex colors and one word with three alpha values. The FI buffer 372 and the LI buffer 376 collectively comprise the floating point block input buffer 155 (FIG. 4).

The floating point block 152 also includes an FLL buffer 378, which connects between the F-core block 352 and the L-core block 354. The FLL buffer 378 is a FIFO used for transmitting lighting and attenuation factors from the F-core block 352 to the L-core block 354. These attenuation factors comprise three X,Y,Z position values, three attenuation values, and one attenuation shift word containing three packed values. An FLF buffer 380 is also provided between the F-core block 352 and the L-core block 354. The FLF buffer is a bi-directional buffer used for communicating data between the F-core block 352 and the L-core block 354 under F-core control.

An L-core to S-core buffer (LS buffer) 386 is coupled between the L-core block 354 and the S-core block 356. The LS buffer 386 is a double buffer with each buffer holding four 48-bit words.

The floating point block 152 also includes an F-core to S-core buffer (FS buffer) 384 which is used for transferring data from the F-core block 352 to the S-core block 356. The FS buffer comprises five buffers which each hold 32 32-bit values. These five buffers are designed to match the pipeline stages of the L-core block 354, these being the two FL buffers, the two LS buffers, plus one primitive which may be stored in the L-core block 354. Data transferred from the F-core block 352 through this buffer to the S-core block 356 includes a dispatch code that indicates which microcode procedure to run in the S-core block 356.

Finally, the floating point block 152 includes an S-core output buffer (SO buffer) 158 which is coupled between the S-core block 356 and the FD bus interface 366. The SO buffer 158 collects data to be sent across the FD bus to the respective draw processors 172A-172B. The SO buffer 158 is double buffered and holds 32 32-bit words in each buffer. The SO buffer 158 holds up to two primitives comprising fixed point data in the order needed by the respective draw processors 172A-172B. The SO buffer 158 includes a separate status register which indicates how many words are valid so that the minimum number of cycles are used to transfer the data across the bus. The SO buffer 158 comprises the floating point block output buffer 158.

For information on the floating point operations performed in the floating point processor 152, please see U.S. Pat. No. 5,517,611 titled "Floating Point Processor for a High Performance Three Dimensional Graphics Accelerator", which is hereby incorporated by reference in its entirety.

Referring now to FIG. 7, a block diagram illustrating one of the respective draw processors 172 is shown. Each of the respective draw processors 172A and 172B are identical, and thus only one is described here for convenience. The draw processor 172 manages the sequencing of the 3DRAM chips. Each draw processor 172 comprises 3DRAM scheduling logic for both internal pixel caches and video output refresh. These resources are controlled by queuing up rendered pixels before they reach the 3DRAM and snooping the pixel addresses in this queue to predict 3DRAM cache misses.

As shown, each draw processor 172 includes an FD bus interface block 402 for interfacing to the FD bus. The FD bus interface block 402 couples to CDC bus interface logic 412. The CDC bus interface logic 412 couples to scratch buffers 414 and a direct port unit 416. The direct port unit 416 receives input from frame buffer interface logic 436 and provides an output to pixel data mux logic 432. The CDC bus interface logic 412 also couples to provide output data to the DC bus. The FD bus interface 402 provides outputs to primitive accumulation buffers 404.

As noted above, the FD bus comprises six independent buses that are synchronized only on a per word basis. The FD bus interface 402 serves two functions. First, the FD bus interface 402 converts each set of three 11-bit data pieces transferred across the FD bus back into a 32-bit word, plus a control bit. Secondly, the FD bus interface 402 directs received data from the FD bus either to primitive accumulation buffers 404 or to CD bus interface logic 412.

The CDC bus interface logic 412 operates with 32-bit data words. As described above, the CDC bus comprises portions of other buses, including the CF-bus and FD bus and is used for allowing the command block 142 to transfer pixels into the 3DRAM chips 192 and 194. The DC bus allows the reading of registers from the draw processor 172, as well as reading pixels from 3DRAM. Data which is provided to one of the draw processors 172 on the CD bus requires a header as a first word. Data which is provided back on the DC bus has no headers since the command block 142 always knows what was requested.

The draw processor 172 also includes scoreboard 418 which keeps track of primitive ordering as specified by the command processor 142. As shown, the scoreboard logic receives an F.sub.-- Num input and provides an output to the primitive accumulation buffers 404. The command block 142 provides a 3-bit code to the draw processor 172 every time a (unicast) primitive is copied into one of the CF-bus output FIFOs. The code specifies which of the six floating point block processors 152A-152F receive the primitive. The code also includes a bit which indicates whether the primitive is ordered or unordered. All ordered primitives are required to come out in the order that they were put in. Unordered primitives may be taken from the primitive accumulation buffers 404 whenever they become available. Some primitives, such as text and markers, output multiple primitives for each primitive input, and these primitives are preferably placed in unordered mode for efficiency. However, all attributes sent to the draw processor 172 must remain ordered relative to primitives they might modify. In addition, there are cases with lines and triangles where strict ordering must also be preserved. The scoreboard logic 418 keeps track of at least 64 primitives. The scoreboard logic 418 provides a signal back to the command block 142 when the scoreboard logic 418 is close to being full, in order to prevent overflowing the scoreboard buffer 418.

As mentioned above, the primitive accumulation buffers 404 receive outputs from the FD-bus interface 402 and from the scoreboard logic 418. The primitive accumulation buffers 404 provide an output to edge walker logic 422 which in turn provides an output to span fill logic 424. The span fill logic 424 provides an output to a texture pixel processor 426. The span fill logic 424 also provides an output to the direct port unit 416. The primitive accumulation buffers 404 also provide an output to texture expander logic 428. The texture expander logic 428 couples to texture memory 430. The texture memory 430 provides data to the texture pixel processor 426. The texture memory 430 also provides data to the direct port unit 416. The texture pixel processor 426 and the direct port unit 416 each provide data to the pixel data multiplexer 432. The pixel data multiplexer 432 provides its output to a pixel processor 434. The pixel processor 434 provides its output to the frame buffer interface 436, and also provides output to the direct port unit 416.

The primitive accumulation buffers 404 are used to accumulate primitive data until a complete primitive has been received. Thus, as data is collected from the six floating point processors 152A-152F, the data eventually forms complete primitives. The primitive accumulation buffers 404 include enough room to hold one complete primitive, plus sufficient storage to hold a portion of a second primitive to maintain the pipeline flowing smoothly. The six Primitive Accumulation buffers 404 are filled as data comes in from each of the six floating point processors 152A-152F. As soon as the primitive has been fully received, in general the next one will be coming behind it. Thus, the primitive accumulation buffers 404 include sufficient extra buffering to transfer the completed primitive out of the primitive accumulation buffer 404 to the edge walker logic 422 before the data gets full from the data coming in from the next primitive. In the preferred embodiment, the primitive accumulation buffers 404 are several words larger than the largest primitive (triangle) that will be processed. The primitive accumulation buffers 404 provide a 64-bit output to the edge walker logic 422. The primitives are removed from the primitive accumulation buffers 404 one at a time based on the contents of the scoreboard logic 418.

The edge walker logic 422 partitions primitives into pieces that may easily be handled by the span fill unit 424. For triangles, the edge walker logic 422 walks along the two current edges and generates a pair of vertical spans adjusted to the nearest pixel sample point, which are then sent to the span fill unit 424. The edge walker unit 422 also performs similar adjustment for lines, sending a line description to the span field unit 424 that is very similar to a triangle span. The edge walker logic 422 comprises two 16.times.24 multipliers used to perform these adjustments. The edge walker logic 422 further includes several adders which keep track of counts used to make other computations. Primitives other than triangles and lines are split up depending on the most efficient use of resources. Both jaggy and anti-aliased dots are sent straight through the logic with a minimum of adjustments, such as adding 0.5 to jaggy dots. Big dots are provided through the edge walker logic 422 as individual pixels. The edge walker logic 422 converts polygons and rectangles to horizontal spans. The edge walker logic 422 does not modify Bresenham lines in any way before being sent onto the span fill unit 424.

The span fill unit 424 performs an interpolation of values across arbitrarily oriented spans, usually for triangles and lines, and also performs filter weight table look ups for anti-aliased lines. For optimized primitives, including triangle span pairs, rectangle and polygon spans, and anti-aliased lines and dots, two pixels are generated per cycle. All other primitives generate one pixel per cycle. The final stage of the span fill unit 424 also performs dithering, converting 12-bit colors to 8-bit values using a 4.times.4 screen space dither pattern. The span fill logic 424 provides output to the texture pixel processor 426.

The texture pixel processor 426 performs texture calculations and controls the look up of texels in the texture memory 430. The texture pixel processor 426 produces a color to be merged in to the pixel by the pixel processor 434. The texture pixel processor 426 passes data onto pixel data multiplexer 432 for all other primitives except for textured triangles.

As mentioned above, the primitive accumulation buffers 404 provide an output to the texture expander 428. The texture expander 428 operates to expand received textures for storage in the texture memory 430. The texture memory 430 is thus loaded directly from the primitive accumulation buffers 404 and is connected to the texture pixel processor for texel look-ups. The texture memory 430 is designed to hold enough data to texture map a 16.times.16 texel region, including all of the smaller mipmaps. The texture memory 430 is preferably double buffered so than one buffer can be loaded while the current buffer is in use. It is noted that the 16.times.16 texel region is actually stored as a 17.times.17 array to enable the interpolation to operate correctly.

As mentioned above, the pixel data multiplexer 432 receives input data from the texture pixel processor 426 and the direct port unit 416. The pixel data mux logic 432 arbitrates between pixels coming from the span fill unit 424 and those coming from the CD bus. Pixels from the CD bus are always given priority. The pixel data multiplexer 432 provides its output to the pixel processor 434.

The pixel processor 434 performs blending, anti-aliasing, depth cueing and sets up for logical operations in the 3DRAM 192 and 194. The pixel processor 434 also comprises logic which is operable to prevent a pixel write for operations such as line patternings, stencil patterning, V port clipping, and so forth. The pixel processor 434 provides an output to the frame buffer interface 436.

The frame buffer interface 436 comprises logic necessary to read and write pixels from the 3DRAM memories 192 and 194. The frame buffer interface 436 manages the level 1 (L1) and level 2 (L2) caches in the 3DRAM chips. This is performed by looking ahead to the pixels to be written and paging in the needed cache while other pixel accesses are occurring. The frame buffer interface 436 in turn couples to each of the 3DRAM memories 192 and 194 as shown.

Referring now to FIG. 8, a block diagram is shown illustrating the CF-bus as well as the relevant buffers inside the command block 142 and respective floating point processors 152A-152F. As described above, the command processor 142 is coupled to the respective floating point blocks 152A-152F. As shown in FIG. 8, as data leaves the vertex buffers 344 in the command block (FIG. 5), the data is separated into six separate CF-bus Output FIFOs 144A-144F. The CF-bus output FIFOs 144A-144F are collectively referred to as FIFOs 144 in FIG. 5. Each CF-bus output FIFO 144A-144F is connected to a respective floating point block 152, and each CF-bus output FIFO 144A-144F operates independently while sending data to the floating point block 152 to which it is connected. All data transfers on the CF-bus are 48-bit words plus a 6-bit code. Each word is transmitted as six 8-bit pieces, most significant bits first, and the code is transmitted as six 1-bit pieces.

The 48-bit words are synchronized among the six separate paths. The first 8-bit piece of a 48-bit word is transferred on the same cycle for all six paths. If one of the paths does not have data ready when a 48-bit transfer beings, it must wait until the next 48-bit word transfer cycle. There is no synchronization relative to the start of primitives, however. The words of a primitive may be transferred whenever they are available to be transferred.

As the data pieces are received by the respective floating point processor 152, they are reassembled into a 48-bit word. The 6-bit code is also assembled and informs the floating point processor 152 what to do with the data. Floating point data, such as for passthrough data, is pulled from the lower 32 bits and stored into the FI-buffer 372 for processing by the F-core 352. Normals, sent as three 16-bit numbers packed into a 48-bit word, are stored into the LI-buffer 376 for processing by L-core 354. Combined colors and vertices are unpacked with 16 bits going to the LI-buffer 376 and 32 bits going to the FI-buffer 372.

As shown in FIG. 8, the CF-bus includes extra wires labeled as the CD-bus. Logically, the CD bus is independent from the CF-bus. However, the CD bus shares or "borrows" the data lines from the CF bus and uses the floating point processors 152 as buffer chips. As shown, three of the CF-bus output FIFOs 144A-144C provide data to respective multiplexers 502A-502C. These multiplexers also receive 8-bit data comprising the CD-bus. A 3-bit portion of the CD-bus is also provided on the final output stage of the command block 142.

When a 32-bit word is to be transferred from the command block 142 to the draw processor 172, one cycle is "borrowed" from the CF-bus. The transfer from the CF-bus output FIFOs 144 is halted for one cycle and the CD-bus data is directed onto the bus. To match up with the 11-bit data path from the floating point processors 152 to the draw processors 172, three more lines are added to each of the first three command to float (CF) data paths. This provides 33 bits for transferring the 32-bit word, using three of the six floating point processors 152.

The data transferred across the CD-bus is inserted after the last stage of a command processor output and is pulled back out of the data stream in the floating point processor 152 before any processing stages. The only disruption of CF-bus data transfers is the one cycle borrowed to transfer the data through. In the preferred embodiment, all six floating point processors 152 have this one cycle "hiccup", even though three of them take in no special data. More detail about CD-bus transfers at the floating point processor outputs is contained below.

FIG. 9 illustrates the FD-bus, which is the bus from the floating point processors 152 to the draw processors 172. FIG. 9 is a block diagram of the FD-bus showing the relevant buffers inside a respective floating point processor 152 and a draw processor 172. It is noted that, physically, there are separate wires from each the floating point processor 152 to each of the two draw processors 172, as shown in FIGS. 3 and 4, even though FIG. 9 only shows the wires to one of the draw processors 172. Logically the wires are the same going to both draw processors 172, since they always have the same data on them.

As data is produced by the setup unit (S-core), it is written to the SO-buffer 158. Each word in this buffer is 32 bits. Each word is taken from the SO-Buffer 158 in three 11-bit pieces, most significant bits first, and sent across the FB-Bus 11 bits at a time. The data words are then reassembled back into 32-bit words in the draw processor 172. The 33.sup.rd bit is set to "1" for the last word of the primitive. This eliminates the need for any word counts sent across the bus.

As shown, each SO-buffer 158 provides its output to a multiplexer 522. The multiplexer 522 also receives an 11-bit input from the CD-bus. As with the CF-bus, the FD-bus also loans out some of its data lines for the CD-bus. Logically, the CD-bus is independent from the FD-bus, but the CD-bus may borrow one cycle at any time to transfer a 32-bit data word. When a CD-bus transfer takes place, the FD-bus is halted for one cycle and the CD-bus data is directed onto the bus. The 32-bit data transfer uses three sets of 11 data lines from floating point processors 152A-152C. The data lines from floating point processors 152D-152F are ignored during this transfer. When the data enters the draw processors 172, it is immediately redirected to the internal CD-bus, instead of going into the primitive accumulation buffer 404 as does all other data.

FIG. 10 illustrates the CDC-bus, which was discussed above. Logically, the CDC-bus can be thought of as a 32-bit wide bi-directional data bus between the command processor 142 and the draw processor 172. Actually, the CD-bus is comprised of two unidirectional buses: the CD-bus going from the command processor 142 to each of the draw processors 172A and 172B, and the DC-bus going from each of the draw processors 172A and 172B to the command processor 142.

The CDC bus is the "direct port" path from the command processor 142 into the frame buffer, i.e., the 3DRAM memories 192 and 194. The CDC bus is used for writing pixels into the frame buffer. The CDC bus is also used for reading back registers and pixels as well as for reading back the contents of the floating point block SRAM. As discussed below, the CD-bus borrows some wires from the CF-bus and the FD-bus and uses the floating point processors 152A-152F as a two-stage buffer. Cycles are borrowed from these two buses one word at a time on demand.

As shown in FIG. 10, the CD-bus is carried over the CF-bus and is provided to the input buffer 362 of three respective floating block chips 152A-152C. If the data transfer is a CF-bus transfer, the data is provided to the float logic, as shown. However, if the data transfer is a CD-bus transfer, the data is provided from the respective FIFO or bus interface directly to the respective multiplexers 532A-532C in the respective floating point processors 152A-152C. The output from each of the multiplexers 532A-532C is provided through respective output buffers 366 to the FD-bus and then to the respective draw processors 172A and 172B.

Data transferred along the CD bus or bypass bus interrupts the normal CF-bus transfer cycle and is sent back out of the respective floating point blocks 152 as quickly as possible. The transfer latency through the floating point blocks 152 is two cycles over this bypass bus. The bypass bus data path 364 is 11 bits wide. As described above, three of the respective floating point processors, preferably the processors 152A, 152B and 152C, are collectively used to transfer a 32-bit word. As also noted above, the 33.sup.rd bit of these three 11 bit buses is used to indicate an end of transfer condition. As shown, the bypass bus 364 receives data from the CF-bus interface 362 and is coupled to provide the data to the FD bus interface 366. Thus the CD bus utilizes a portion of the CF bus, a portion of the FD bus, and an internal data path to three of the floating point blocks 152A-152C.

In the majority of cases, the command block 142 provides data to each of the draw blocks 172A and 172B provided through the floating point logic in the floating point blocks 152A-152F as described above. However, in some instances, the command block 142 desires to provide data directly to the draw blocks 172A and 172B quickly without requiring passage through the floating point logic. In this instance, the command block 142 uses the CD bus. The CD bus is primarily used to enable the command block 142 to provide data directly to the frame buffer, bypassing the floating point logic in the floating point processors 152. As described above, a substantial portion of the CD bus is provided "on chip" in three of the floating point blocks 152A-152C. This reduces the required board space.

In one embodiment, during the time that the CD bus or bypass channel 364 is being used to transmit data directly from the command block 142 to the draw blocks 172A and 172B, each of the respective floating point blocks 152 may be processing other data during this time. This thus allows concurrent operations to occur, providing greater system efficiency.

As also shown in FIG. 10, each of the draw processors 172A and 172B include a direct data path, referred to as the DC bus 173, which is coupled to the Command block 142. The DC-bus is the data path back from each of the draw processors 172A and 172B to the command processor 142. The DC bus comprises two 16-bit unidirectional point-to-point buses. Data sent across the DC-bus always comprises pairs of 16-bit words which are collected into 32-bit words in the command block 142. When pixels are being read back, the data will be different from the two draw processors 172. The command processor 142 sorts this data back into the sequence needed by the host CPU 102. When a single pixel is read from the draw processors 172A and 172B, only one draw processor 172 sends the data back and half of the total 32-bit wide data path remains idle.

The DC bus provides a return path for pixels from each of the draw blocks 172A and 172B back to the command block 142. Thus, when the command block 142 requests to read pixels in the draw blocks 172A and 172B, the draw blocks 172A and 172B provide this pixel data on the DC bus to the command block 142. As shown, the command block 142 includes buffers which receive the data from the DC bus. The DC bus enables the command block 142 to read pixels from respective frame buffer. The DC bus also enables the draw blocks 172A and 172B to provide status back to the command block 142, such as during context switches.

The DC bus is used primarily to enable the command block 142 to read pixels back out of the respective 3DRAM memories 192 and 194. For example, when a window of pixel data is stored in the memories 192 and/or 194, and this window is partially or totally occluded by another window, the CPU 102 desires to read the occluded data from storage so that this data may be reapplied later when this windows is no longer occluded. In this instance, the CPU 102 provides a request to read the pixel data to the command block 142, and in response to a request from the command block 142, each of the draw blocks 172A and 172B read the pixel data from the memories 192 and 194 and provide this data back on the DC bus return path to the command block 142. The command block 142 then in turn provides the data back to the CPU 102 for storage.

The command block 142 controls the sequencing of transfers into the respective floating point blocks 152A-152F as described above. The command block 142 also operates to control all of the operations within the graphics accelerator system. Each of the floating point blocks 152A-152F are required to ask and receive permission from the command block 142 before a respective transfer to the drawing blocks 172A and 172B. Although not shown in the Figures, each of the output FIFO buffers 158A-158F in the respective floating point blocks 152A-152F include control lines which are coupled back to the command block 142. These control lines are used by the respective output FIFO buffers 158A-158F to ask permission of the command block 142 for a transfer to respective drawing blocks 172A and 172B. Each of the input FIFO buffers 155A-155F in the respective floating point blocks 152A-152F also use their respective control lines on the respective 12-bit channels 154A-154F to provide status information to the command block 142, including a signal which includes that the buffer is full and/or requires data, etc.

When the respective FIFO buffer 158A-158F asks for and receives permission from the command block 142, then the respective output FIFO buffer 158 then transmits primitive to each of the drawing blocks 172A and 172B. The command block 142 preferably includes counters for each of the input queues 155A-F and each of the output queues 158A-F and operates to increment these respective counters as data is received by or transferred from, respectively, the respective buffers. The command block 142 also provides control lines to each of the draw blocks 172A and 172B to indicate an order for execution for each of their received primitives.

Referring now to FIG. 11, a block diagram illustrating the F-Core block 352 in each of the floating point processors 152 is shown. As shown, the F-core processor 352 receives geometry primitive data and performs floating point operations on the received geometry data. The F-core processor 352 performs operations such as transforming vertex positions from model space to view space, performing clipping operations on received geometry data, performing perspective division to convert received vertex information to screen space, and determining if a triangle is front-facing or back-facing. The F-core processor also performs some lighting operations.

As shown, the F-core processor 352 includes FR registers 512 which store constants and intermediate values. The FR register file 512 preferably includes 160 registers and also includes three read ports and one write port. The FR register file 512 couples to three buses referred to as the FA-bus, the FB-bus and the FC-bus. The F-core processor 352 includes three buses to allow multiply accumulate operations to occur once per clock cycle.

The F-core processor 352 includes a floating point multiplier (FMUL) 514, a floating point adder (FADD) 516, a clip compare block 518, a reciprocal unit 522, and an integer arithmetic-logic unit (IALU) 522. Each of these math units are coupled to one or more of the FA, FB, and FC buses.

The floating point multiplier (FMUL) 514 receives inputs from the FA and FB buses and outputs either directly to the FD-bus or to a floating point adder (FADD) 516. The floating point adder 516 receives two inputs. One side of the floating point adder 516 receives its input from either the FC-Bus or from the floating-point multiplier 514. The other input of the adder 516 is coupled to receive data from either the FC-Bus or from the output of the adder 516. Thus the output of the adder 516 is fed back into one of its inputs. This loop back or feedback feature allows values to be accumulated from several multiples without having to pass back through the FR registers 512. The adder 516 is thus designed to feed a value back through after four cycles, which exactly matches the matrix multiple operation used to transform vertices.

The clip compare block 518 is optimized for clip testing. The inclusion of dedicated clip compare circuitry obviates the necessity of the floating point adder 516 having to perform this function. The inclusion of dedicated clip compare circuitry also saves the extra cycles that would have been needed to perform clip testing. The clip compare block 518 compares against both the positive and negative clip boundary and also performs a limited precision guard-band test at the same time. The clip compare block 518 thus actually allows four comparisons in one instruction cycle.

The guard-band clip compare is hard-wired to be 33/32 for a 3% guard band. An extra 8-bit adder and 8-bit comparator are all that is required. The guard-band test is not as accurate as the regular clip compare, but provides consistent results. The guard-band clip compare is able to determine the whether a triangle is outside of the view-port by a small amount or a large amount. Triangles that are outside of the view-port by only a small amount are preferably drawn instead of bothering to clip them. Triangles that are outside of the view-port by a larger amount are preferably clipped to the window boundary. It is noted that for adjacent triangles, where one is clipped and the other is not, the result may yield different vertices for adjacent edges. These different vertices may produce small cracks occasionally, although rarely enough to escape common notice.

The reciprocal unit 522 receives its input from either the FB-Bus or the result of the floating-point add unit 516. Math units other than the reciprocal unit 520 require a fixed number of cycles to produce a result, and then the result is put onto the FD-Bus. The reciprocal unit 520 holds its result until an instruction is issued to read the reciprocal result.

The integer arithmetic-logic unit (IALU) 522 performs addition, subtraction, boolean operations, bit test/set/clear/ operations, and barrel shifts. It also performs an inverse square root function (which is a floating-point operation).

Although not shown in FIG. 11, the F-core processor 352 also includes additional logic for instruction sequencing and decoding, as well as registers containing state bits.

As discussed above, the F-core processor 352 includes five different buffers that are used for inter-chip communication. The FI registers 372 are input only and contain data received from the command block 142 across the CF-Bus. The FI registers 372 appear as 32 entries in the overall register address space. Data appears in the FI registers after executing a "need.sub.-- FI" instruction, which halts instruction sequencing if a complete primitive is not available in the input buffer. For primitives which are smaller than 32 words (i.e. most primitives), not all 32 entries are valid. When a "free.sub.-- FI" instruction is executed, the buffer is immediately able to receive more data. This buffer is double-buffered so that under normal circumstances data may be read into one buffer while data in the other buffer is being used. Then, when "free.sub.-- FI" and "need.sub.-- FI" are executed, the next buffer full of data will be available.

The FL buffer 374 is normally used to send an XYZ direction vector to L-Core 354 for each vertex. When triangles are clipped, the FL buffer 374 is used to send the clipped RGB color values as well as the clipped alpha value. All values stored into the FL buffer 374 are 32-bit fixed-point, but only 16 bits are kept in the buffer, aligned to match the 16-bit fixed-point format of the L-Core block 354. When L-core 354 removes data from the other side of the FL buffer 374, the L-core block 354 pulls each set of three words out as one 48-bit word. Like the FI buffer 372, the FL buffer 374 is also double buffered and controlled by "need" and "free" instructions.

The FLL FIFO 378 is used for passing the attenuation factors for local light sources (both point and spot lights). Because the FLL FIFO 378 is a FIFO, the FLL FIFO 378 passes data using reads and writes rather than by directly using "need" and "free" instructions. The FLL FIFO 378 also appears as only one single register to both F-Core 352 and L-Core 354. It should be noted that when F-Core 352 issues a "need FLL" instruction, there must be at least three empty locations in the FLL buffer 378 before it is available.

The FLF Buffer 380 is used for transferring data both directions between F-Core 352 and L-Core 354. Values are written to specific addresses in the buffer 380 and read on the other side from corresponding addresses. Synchronization is achieved using two flag registers, one for passing data from F-Core 352 to L-core 354 and the other for the opposite direction. Microcode guarantees that the FLF buffer 380 is only used in one direction at a time.

The color and alpha values computed during the lighting calculations are stored in the FLF buffer 380 as well as the LS buffer 386 when lighting is completed. If F-Core 352 sets the clip-pending mode, the values in the FLF buffer 380 are read back by F-Core 352 and the values in the LS buffer 386 are ignored. In the normal case where no clipping occurs, the FLF buffer 378 is ignored and the LS buffer values are sent on to S-Core 356.

When F-Core 352 needs to "borrow" the L-Core functions unit for spot light exponent computations, the three values are sent using the FLF buffer 378. Later, the three result values are sent back in the FLF buffer 378. In both cases, only the least significant 16 bits of the 48-bit word are used for transferring data.

The FS registers 384 are output only and are used to send data to S-Core for setup computations. All data to be processed by S-Core 356 is in one of the two fixed-point formats: s1.30 or s11.20. One primitive may have up to 32 words of data in the FS registers 384 plus one word containing header information, consisting of an op-code and several control bits. Rather than being double-buffered like many of the other buffers, there are five buffers in the FS registers 384 to account for the two FL buffers 374, the two LS buffers 386 (out of L-Core), plus one primitive that is being processed in L-Core 354. The FS registers 384 are switched using "need" and "free" instructions.

Referring now to FIG. 12, a block diagram illustrating the L-Core block 354 in each of the floating point processors 152 is shown. The L-core processor 354 comprises a fixed point computational unit for performing lighting computations. The lighting core 354 is coupled to receive output data from the floating point core and is also coupled to receive primitive data directly from the bus interface. The L-core processor 354 is designed specifically to perform lighting calculations. In the preferred embodiment, the L-core processor 354 performs most of the lighting operations. The F-core block 352 performs lighting computations for more complex light sources which require the use of a general purpose floating point processor, such as point and spot light sources.

The L-core 354 is designed specifically to perform lighting calculations. All calculations are performed using 16-bit fixed-point math, three at a time. The three values in a 48-bit word may either represent one triple such as XYZ or RGB, or may represent one value for three different vertices of a triangle, like the alpha values. It is noted that FIG. 12 does not illustrate all control registers or data paths, but contains sufficient detail to describe how the L-core block 354 is used to perform lighting calculations.

The lighting computation performed by L-core does not use pre-multiplied material color with other lighting attribute's cached values. This allows the graphics accelerator to support RGB per vertex color triangle meshes as a high quality alternative to texture and bump mapping. In general, most lighting operations are expected to include a per vertex color change. While this requires some increased computation in the L-Core 354, it is completely overlapped by other units (i.e. L-Core is still faster than both F-Core and S-Core). This change also makes it much easier to support OpenGL's semantics, in which colors might change at any vertex without warning and without any effective way of caching.

The L-Core 354 has efficient 16-bit function units and also performs the model space to world space transformation on vertex normals. The command block 142 delivers normal data to the floating point processor 152 as 48-bit values (3 16-bit components), already normalized. The L-Core registers include two 2.times.3 normal transformation matrices, store as three 48-bit values each. There are two transformation matrices because of the dual matrix semantics of the render pipeline.

Colors and normals are transferred from the command block 142 to L-Core 354 by way of the LI-Buffer 376. The lighting calculations are performed based on the contents of the light registers and a dispatch word passed in from F-Core 352. The L-Core instruction set preferably does not include branch instructions, so each step of the lighting calculation runs to completion, then the next step is started based on the contents of the dispatch word.

The L-Core 354 includes three different register files in addition to the input and output buffers. The LL registers 562 contain the values for each of up to 32 lights. A register specifies which light to access, since only one light may be accessed at a time. The light values are loaded by F-Core 352 and may not be modified by L-Core 354. The LR registers 564 are the general purpose registers used for storing intermediate values from the computations. The LCC registers 566 hold the material properties or "current color" values. Special registers are used here instead of using the LR registers 564, because incoming colors are stored into the LCC registers 566 using special logic. OpenGL allows the current color to be used for emission, ambient, diffuse, specular, or ambient and diffuse. A mode setting specified by F-Core 352 determines which value gets replaced and a special L-Core instruction causes the transfer from the LI buffer 376 to the appropriate LCC register(s) 566.

The L-Core 354 includes three multiply-accumulate units 572A-572C, one for each of the three 16-bit values in the 48-bit word. Standard operation of each of the multiply-accumulate units is 48 bits in and 48 bits out. For the dot product calculation, there is only a 16-bit result, so this result is replicated into each of the three 16-bit fields.

The L-Core 354 includes an inverse square root (ISQRT) block 582 which is used in normalizing the viewpoint vector. The ISQRT block 582 receives 16 bits from a dot product calculation and produces a 16-bit result, replicated to three values in the 48-bit word.

The L-Core 354 also includes a power function unit 584 which is used for computing specular highlights. The power function unit 584 also takes in 16 bits from a dot product calculation and produces a 16-bit result, replicated to three values in the 48-bit word. The power function unit 584 performs two table lookups and performs other calculations to produce an accurate value. The result is accurate to 0.5%, or accurate to a least significant bit of an 8-bit color.

The L-Core 354 includes five different buffers for communicating with other parts of the chip. The LI Buffer 376 corresponds to the FI buffer 372 in F-Core. The LI Buffer 376 is used for accessing incoming data from command block 142 coming across the CF-Bus. The LI Buffer 376 appears as seven 48-bit registers and contains three colors, three normals, and one word containing the three alpha values. Like the FS registers 384 in F-Core 352, the LI buffer 376 comprises five buffers to match up with the two FI Buffers 372, the two FL buffers 374, plus the one primitive that is being processed in F-Core 352.

The FL Buffer 374 is used to transfer the XYZ viewpoint vector from F-Core 352. The FL Buffer 374 is also used to transfer clipped RGB color and alpha values when a triangle is clipped. The FLL FIFO 378 is used for passing attenuation values for logical lights. These values require floating-point computations that may only be performed in F-Core 352. When the lighting calculations get to the point where the attenuation factor is needed for a light, L-Core 354 pauses until the data is available in the FLL FIFO 378.

The FLF Buffer 380 is for communication between L-Core and F-Core and is not intended for normal operation. One runtime use of the FLF buffer 380 is to send lighting values back to L-Core 354 during clipping and for F-Core to "borrow" the power function logic from L-Core 354 for use with spot lights. To do this, F-Core writes the two power function parameters to the FLF buffer 380, halts L-Core 354, then directly executes instructions to perform the power function. When computations are complete, the result is stuffed back into the FLF buffer 380 and L-Core 354 is allowed to continue. F-Core 352 then reads the result out of its side of the FLF buffer 380. The FLF buffer 380 is also preferably used for diagnostic purposes.

The LS Buffer 386 comprises the write-only output registers used to send data to S-Core 356 for setup computations. Only colors and alpha values are sent across this interface. For standard triangles, three colors and one alpha word (containing three values) are sent to S-Core 356, but in the special case of textured lighting two sets of three colors, plus alpha, are sent, so the buffer requires at least seven entries. In the preferred embodiment, the LS Buffer 386 comprises eight entries, which are double-buffered.

The power function block 584 is used to raise some number between 0.0 and 1.0 to a power between 0.0 and 128.0. In some prior art architectures, this is done using a table lookup, which is almost good enough for specular highlights, but resulted in serious rendering artifacts when used for spot light beam spread. The biggest problems with a table lookup are the size of the table and the fact that there are steps between values instead of a smooth function.

The Power Function Unit 584 in L-Core 354 computes a much more accurate value using a complex mathematical equation. The function is approximated as the antilog of: Log.sub.2 (D.sup.P) =P Log.sub.2 (D).

This is then partitioned into three parts comprising the number of bits to shift the binary value to get the first "1", an exponent table lookup, and a fractional value computed using a series expansion.

The inverse square root function is defined as: F(X)=X.sup.1/2. Using the Newton-Raphson method, this function can be approximated as: 0.5.multidot.(S.multidot.(3.0-S.multidot.(S.multidot.X)))) where S represents an approximate inverse square root value looked up in a table. The same hardware used for the power function generates an inverse square root with three passes through the multiply/add unit. The lookup table ROM only requires 96 entries (for initial inputs between 1.0 and 0.25) of 10 bits accuracy. The result is accurate to a least significant bit.

Referring now to FIG. 13, a block diagram illustrating the S-Core block 356 in each of the floating point processors 152 is shown. The set-up core 356 comprises a fixed point computational unit for performing set-up calculations for geometric primitives. The set-up calculations include sorting the three vertices of a triangle in ascending y order for draw processing. The set-up core 356 receives an output from the lighting core 354 and the floating point core 352 and provides outputs to the draw processors 172A and 172B.

The S-Core block 356 performs setup calculations. In the preferred embodiment, data is processed using a 28-bit block floating-point format. Extensive numerical analysis of the accuracy requirements of setup and screen space rendering has shown that pure fixed-point is insufficient to handle the dynamic range of slopes possible during DDA setup computations. Indeed, the setup data itself is not completely fixed-point in nature. Some of the slopes are sent down to the draw processors 172 still in a special floating-point format, where they are used in this form. The value stored into the depth buffer r Z buffer uses a special floating-point representation.

The S-Core processor 356 includes three buses referred to as the SA, SB and SC buses. A multiplier 614 couples to the SA and SB buses and provides an output through a multiplexer to an adder 616. The other input of the adder 616 is coupled to the SC bus. The adder 616, the multiplier 614, the SA bus and two reciprocal units 618 and 620 provide outputs to a multiplexer 630 which provides an output through an SD bus to the SO buffer 158.

The S-Core processor 356 includes SR Registers 612 which store constants and intermediate data values. The SR register file 612 includes 64 32-bit registers with three read ports and one write port. All three read ports are used when performing multiply-accumulate operations with the SA and SB busses going to the multiplier 614 and the SC-Bus going to the adder 616.

The setup calculations involve computing the distances in multiple dimensions from one vertex to another and calculating slopes along that edge. For triangles the slopes of Z, color and UV (for texture) are also computed in the direction of a scan line. The fixed-point multiplier 614 takes inputs from the SA and SB busses and outputs either to the SD-Bus or to the fixed-point adder 616. One side of the adder 616 receives its input from either the SA-Bus or from the output of the multiplier 614 and the other side gets its input from the SC-Bus.

The S-Core processor 356 includes two reciprocal units 618 and 620 because reciprocals require a large number of cycles and two of them are needed for triangles. The reciprocal units 618 and 620 are connected to the SC-Bus to more quickly start working on the results coming out of the adder 616. It is noted that there is a data path directly from the SA-Bus to the SD-Bus, used to transfer passthrough data directly from the FS buffer 384 to the SO buffer 158.

The S-Core 356 includes three different buffers that uses for communicating with other parts of the chip. The LS buffer 386 is input only and contains data from L-Core 354. Only colors and alpha values come through this buffer. The LS buffer 386 appears as 24 32-bit words with each word containing a fixed-point number derived from the 16-bit fixed-point stored unto the buffer by L-Core 354.

The FS buffer 384 is input only and contains data from L-Core 354. Everything else that is to be sent to the draw processors 172 chips comes in through this path. For geometric primitives, the X, Y, and Z coordinates come through this path. For passthrough packets, 32-bit data comes through this path. The FS buffer 384 may also be used for diagnostics transmission, as desired.

The SO Buffer 158 is output only and is used to send data to the draw processors 172 across the FD-Bus. The SO Buffer 158 is double-buffered and holds 32 32-bit words.

Although the system and method of the present invention has been described in connection with the described embodiments, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.