Patent Publication Number: US-6989835-B2

Title: Flexible video architecture for generating video streams

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
   This application claims benefit of priority to U.S. Provisional Application Ser. No. 60/214,713 filed on Jun. 28, 2000 titled “Flexible Video Architecture for Generating Video Streams”. 

   BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   This invention relates generally to the field of computer graphics and, more particularly, to a flexible system architecture for generating video signals in a graphics environment. 
   2. Description of the Related Art 
   A computer system may be used to drive one or more display devices (such as monitors or projectors). The computer system may provide analog or digital video signals to drive the display devices. The computer system may include a graphics system for the rendering and display of 2D graphics and/or 3D graphics. The graphics system may supply the video signals which drive the display devices. In addition, the computer system may include a system unit, and input devices such as a keyboard, mouse, etc. 
   In general, prior art graphics systems do not have a scalable video architecture, i.e. they are not able to flexibly allocate hardware resources in proportion to the number of video signals to be generated and the respective pixel bandwidths of the video signals. Thus, graphics consumers are often forced to use a more powerful, and thus, more expensive graphics system than would be optimal for a given graphics scenario. Thus, there exists a need for a graphics system which can flexibly allocate hardware resources to video signals in proportion to their respective pixel bandwidths. 
   Furthermore, prior art graphics systems typically do not provide a mechanism enabling multiple hardware devices (e.g. graphics boards) to collaborate in generating one or more video signals. Thus, graphics consumers may be forced into the inefficient mode of using one hardware device (e.g. one graphics board) per video signal. In this case, some or all of the graphics boards may operate at significantly less than maximum capacity. Therefore, there exists a need for a graphics system and methodology which would enable multiple hardware devices to collaborate in the generation of one or more video signals. 
   SUMMARY OF THE INVENTION 
   The problems described above may be addressed in some embodiments by a graphics system according to the present invention. In one embodiment, the graphics system comprises a plurality of calculation units coupled together in a linear array (i.e. a series). The plurality of calculation units may include a first subset and a second subset. The first subset of calculation units includes a lead calculation unit which is configured to generate a first digital video stream. Similarly, the second subset of calculation units includes a lead calculation unit configured to generate a second digital video stream. Each calculation unit of the first subset is configured to compute pixel values for a corresponding column in a first display area, and to contribute (e.g. to blend or inject) the computed pixel values to the first digital video stream. Furthermore, each calculation unit of the second subset is configured to compute pixel values for a corresponding column in a second display area, and to contribute the computed pixel values to the second digital video stream. A last calculation unit in the linear array is configured to provide the first digital video stream and the second digital video stream to a first digital-to-analog conversion (DAC) unit and a second DAC unit respectively. The first DAC unit converts the first digital video stream into a first video signal for presentation to a first display device. The second DAC unit converts the second digital video stream into a second video signal for presentation to a second display device. 
   In some embodiments, the calculation units comprising the linear array are contained within a graphics board. The graphics board may also include rendering hardware and a sample buffer. The rendering hardware is configured to receive graphics data (e.g. graphics primitives such as triangles), and to render samples corresponding to the graphics data. The rendering hardware stores the rendered samples into the sample buffer. Each calculation unit of the linear array is configured to read samples from a corresponding region of the sample buffer, and to compute pixel values in response to the samples of the corresponding region. 
   In a second embodiment, the calculation units of the linear array are comprised within (i.e. distributed among) a plurality of graphics boards. Each graphics board comprises rendering hardware and a sample buffer, and is configured to render samples into the corresponding sample buffer in response to received graphics data. Each calculation unit in a given subset is configured to compute pixel values based on samples from the sample buffer of the graphics board in which it resides. It is noted that a subset of calculation units may span more than one graphics board. 
   Each calculation unit of the linear array comprises a local horizontal counter, a local vertical counter, local horizontal boundary registers and local vertical boundary registers. Each calculation unit of the first subset is configured to contribute its locally-computed pixel values to the first digital video stream in response to (a) a horizontal count value of the local horizontal counter falling between horizontal limits indicated by the local horizontal boundary registers, and (b) a vertical count value of the local vertical counter falling between vertical limits indicated by the local vertical boundary registers. The local horizontal boundary registers of each calculation unit of the first subset may be programmed with integer values corresponding to the left and right boundaries of the corresponding column of the first display area. The local vertical boundary registers of each calculation unit of the first subset may be programmed with integer values corresponding to the upper and lower boundaries of the corresponding column of the first display area. Similarly, each calculation unit of the second subset may use its local horizontal counter and local vertical counter to selectively contribute locally-computed pixel values to the second digital video stream. 
   The lead calculation unit of the first subset is configured to transmit dummy pixels into the first digital video stream in response to the horizontal count value of the local horizontal counter falling outside the horizontal limits indicated by the local horizontal boundary registers, or (i.e. logical OR), the vertical count value of the local vertical counter falling outside the vertical limits indicated by the local vertical boundary registers. These dummy pixels serve as timing place holders for the contribution of pixels by down-stream calculation units. In other words, the dummy pixels provide definite time-slots in which a down-stream calculation can contribute (i.e. blend or substitute) its locally computed image pixels to the gradually emerging video stream. Any dummy pixels which are not replaced by a down-stream calculation unit become pixels in a letter box region of the video display since the dummy pixels may be assigned a predefined color. 
   Each calculation unit of the second subset is configured to contribute the second locally-computed pixel values to the second digital video stream in response to (c) a horizontal count value of the local horizontal counter falling between the horizontal limits indicated by the local horizontal boundary registers, and (d) a vertical count value of the local vertical counter falling between vertical limits indicated by the local vertical boundary registers. 
   Each calculation unit of the second subset is further configured to receive and forward the second digital video stream without modifying pixel values of the second digital video stream in response to the horizontal count value of the local horizontal counter falling outside the horizontal limits indicated by the local horizontal boundary registers, or the vertical count value of the local vertical counter falling outside the vertical limits indicated by the local vertical boundary registers. 
   It is noted that the principles described herein for the generation of two simultaneous video streams in a series of calculation units naturally generalize to an arbitrary number L of simultaneous video streams, where L is any positive integer. Thus, each calculation unit may be configured to receive L video streams, and to conditionally contribute locally computed pixels to a selected one of the L video streams. 
   In a third embodiment, the graphics system comprises at least a first video router and a second video router. The first video router comprises a first local video buffer, a first color unit, a first blend unit, a first horizontal counter, and a first vertical counter. The second video router couples to the first video router, and comprises a thru-video buffer, a second local video buffer, a second blend unit, a second horizontal counter, and a second vertical counter. 
   The first local video buffer is configured to receive and store first local pixels computed for a first column of a display area. Similarly, the second local video buffer is configured to receive and store second local pixels computed for a second column of the display area. The first blend unit is configured to receive a first stream of dummy pixels having a predefined color from the first color unit, to conditionally replace the dummy pixels in the first video stream with first local pixels from the first local video buffer, thereby generating a second stream of second pixels, and to transmit the second stream to the second video router. In particular, the first blend unit is configured to contribute the first local pixels to the second stream in place of dummy pixels in the first stream in response to (a) a first horizontal count value of the first horizontal counter falling within the left and right boundaries of the first column, and (b) a first vertical count value of the first vertical counter falling within the top and bottom boundaries of the first column. The thru-video buffer in the second video router is configured to receive and temporarily store the second stream of second pixels. 
   The second blend unit is configured to receive the second stream of second pixels from the thru-video buffer, to conditionally contribute the second local pixels in place of the second pixels of the second stream, thereby generating a third stream of third pixels, and to transmit the third stream of third pixels. In particular, the second blend unit is configured to contribute the second local pixels to the third stream in place of the second pixels of the second stream in response to (c) a second horizontal count value of the second horizontal counter falling within the left and right boundaries of the second column and (b) a second vertical count value of the second vertical counter falling within the top and bottom boundaries of the second column. 
   The first blend unit is further configured to transmit the dummy pixels of the first stream so that the second pixels of the second stream correspond to the dummy pixels of the first stream in response to the first horizontal count value of the first horizontal counter falling outside the left and right boundaries of the first column, or the first vertical count value of the first vertical counter falling outside the top and bottom boundaries of the first column. 
   Similarly, the second blend unit is further configured to transmit the second pixels of the second stream so that the third pixels of the third stream correspond to the second pixels in response to the second horizontal count value of the second horizontal counter falling outside the left and right boundaries of the second column, or the second vertical count value of the second vertical counter falling outside the top and bottom boundaries of the second column. 
   The graphics system further comprises a first clock generator configured to generate a first pixel clock. The first local video buffer receives the first pixel clock and transmits the first local pixels to the first blend unit in response to transitions (e.g. rising edge transitions) of the first pixel clock and in response to conditions (a) and (b) being true. In addition, the first color unit receives the first pixel clock and transmits each of the dummy pixels comprising the first stream to the first blend unit in response to the transitions of the first pixel clock. 
   The first blend unit may embed a synchronous version of the first pixel clock into the second stream of second pixels. The thru-video buffer of the second video router stores the second pixels of the second stream in response to transitions of the synchronous embedded pixel clock. In addition, thru-video buffer transmits the second stream of second pixels in response to transitions of the first pixel clock. Because the synchronous embedded pixel clock and the first pixel clock have the same frequency, the thru-video buffer never underflows or overflows. 
   The first pixel clock drives the first horizontal counter and second horizontal counter. The first vertical counter increments in response to the first horizontal count value attaining a first maximum value corresponding to the right edge of the display area. Similarly, the second vertical counter increments in response to the second horizontal count value attaining a second maximum value corresponding to the right edge of the display area. 
   In another embodiment, the first blend unit is configured to embed a horizontal reset indication in the second stream in response to the first horizontal count value corresponding to the left edge of the display area. The second horizontal counter is configured to reset to a predefined value (e.g. zero) in response to receiving the horizontal reset indication from the thru-video buffer. Furthermore, the first blend unit is configured to embed a vertical reset indication in the second stream in response to the first vertical count value and the first horizontal count value corresponding to the top-left corner of the display area. The second vertical counter is configured to reset to a second predefined value (e.g. zero) in response to receiving the vertical reset indication from the thru-video buffer. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The foregoing, as well as other objects, features, and advantages of this invention may be more completely understood by reference to the following detailed description when read together with the accompanying drawings in which: 
       FIG. 1  illustrates one embodiment of a computer system which includes a graphics system  112  according to the present invention for driving one or more display devices; 
       FIG. 2A  is a simplified block diagram of the computer system of  FIG. 1 ; 
       FIG. 2B  illustrates one embodiment of graphics system  112  in which multiple graphics boards couple together in a linear chain and cooperatively generate two video streams for two display devices respectively; 
       FIG. 3  illustrates one embodiment of a graphics board according to the present invention; 
       FIG. 4  illustrates a collection of samples representing a virtual image and populating a two-dimensional viewport  420 ; 
       FIG. 5A  illustrates an embodiment of critical sampling, i.e. where one sample is assigned to each pixel area in virtual screen space X-Y; 
       FIG. 5B  illustrates an embodiment of regular super-sampling, where two samples are assigned to each pixel area in virtual screen space X-Y; 
       FIG. 5C  illustrates a random distribution of samples in virtual screen space X-Y; 
       FIG. 6  illustrates one embodiment for the flow of data through generic graphics board GB(K); 
       FIG. 7  illustrates a second embodiment for the flow of data through generic graphics board GB(K); 
       FIG. 8  illustrates one embodiment of a method for filtering samples values to generate pixel values using multiple sample-to-pixel calculation units (also referred to as convolve units); 
       FIG. 9A  illustrates one embodiment for the traversal of a filter kernel  400  across a generic Column I of  FIG. 8 ; 
       FIG. 9B  illustrates one embodiment for a distorted traversal of filter kernel  400  across a generic Column I of  FIG. 8 ; 
       FIG. 10  illustrates one embodiment of a method for drawing samples into a super-sampled sample buffer; 
       FIG. 11  illustrates one embodiment of a method for calculating pixel values from sample values; 
       FIG. 12  illustrates one embodiment of a convolution computation for an example set of samples at a virtual pixel center in the 2-D viewport  420 ; 
       FIG. 13  illustrates one embodiment of a linear array of sample-to-pixel calculation unit CU(I,J) comprised within two graphics boards GB( 0 ) and GB( 1 ); 
       FIG. 14A  illustrates one embodiment for a global managed area partitioned by channel A and channel B subregions; 
       FIG. 14B  illustrates a situation where the channel A and channel B subregions overlap; 
       FIG. 14C  illustrates a situation where the channel B subregion is entirely contained within the channel B subregion; 
       FIG. 14D  illustrates a situation where the channel A subregion extends outside the global managed area; 
       FIG. 14E  illustrates a situation where the channel A subregion and channel B subregion are assigned to separate managed areas; 
       FIG. 15  illustrates one embodiment of a video router VR(I,J) in generic sample-to-pixel calculation unit CU(I,J); 
       FIG. 16  illustrates a second embodiment of video router VR(I,J) in generic sample-to-pixel calculation unit CU(I,J); 
       FIG. 17  illustrates one embodiment of a graphics board having six sample-to-pixel calculation units; 
       FIG. 18  illustrates one embodiment of a graphics board denoted GB×4 having N sample-to-pixel calculation units and configured to generate and/or operate on four simultaneous video streams; 
       FIG. 19  illustrates one embodiment for the assignment of columns (I,J) to each sample-to-pixel calculation unit CU(I,J) for collaborative generation of two video streams corresponding to channel A and channel B respectively; 
       FIG. 20  illustrates one embodiment of a chain of graphics boards cooperating to generate a video signal for display device  84 A; 
       FIG. 21  illustrates one embodiment for the partitioning of channel A into regions R 0 –R 5  corresponding to graphics boards GB( 0 ) through GB( 5 ) respectively; 
       FIG. 22A  illustrates the successive contribution of pixel values to video stream A by sample-to-pixel calculation units CU( 0 ), CU( 1 ) and CU( 2 ) for scan line  620  of  FIG. 21 ; 
       FIG. 22B  illustrates the successive contribution of pixel values to video stream A by sample-to-pixel calculation units CU( 0 ), CU( 1 ), CU( 2 ) and CU( 3 ) for scan line  622  of  FIG. 21 ; 
       FIG. 22C  illustrates the action of sample-to-pixel calculation units CU( 0 ) through CU( 5 ) on video stream A for scan line  624  of  FIG. 21 ; 
       FIGS. 23A and 23B  illustrate one embodiment for the mixing (or injection) of locally-computed pixels into video stream B in a generic sample-to-pixel calculation unit CU(I,J); 
       FIGS. 24A and 24B  illustrate one embodiment for the mixing (or injection) of locally-computed pixels into video stream A in a generic sample-to-pixel calculation unit CU(I,J); 
       FIG. 25  is a circuit diagram for one embodiment of video router VR(I,J) in generic sample-to-pixel calculation unit CU(I,J); 
       FIG. 26  is a circuit diagram for generic thru-video FIFO  503 ; and 
       FIG. 27A  illustrates one embodiment for a pixel line buffer which integrates two video streams into a single output video stream; 
       FIG. 27B  illustrates one embodiment for the partitioning of a display field into video streams A, B, C and D which are assigned to video groups A, B, C and D respectively; 
       FIG. 28  illustrates a series of timing diagrams which illustrate the input and output behavior for one embodiment of pixel line buffer PLB. 
   

   While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. Note, the headings are for organizational purposes only and are not meant to be used to limit or interpret the description or claims. Furthermore, note that the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not a mandatory sense (i.e., must). The term “include”, and derivations thereof, mean “including, but not limited to”. The term “connected” means “directly or indirectly connected”, and the term “coupled” means “directly or indirectly connected”. 
   DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS 
     FIG. 1  illustrates one embodiment of a computer system  80  which performs three-dimensional (3-D) graphics according to the present invention. Computer system  80  comprises a system unit  82  which may couple to one or more display devices such as display devices  84 A and  84 B. The display devices may be realized by any of a variety of display technologies. For example, the display devices may be CRT displays, LCD displays, gas-plasma displays, digital micromirror displays, LCOS displays, etc., or any combination thereof. System unit  82  may control an arbitrary number of display devices. However, only two display devices are shown for convenience. The display devices may include projection devices, head mounted displays, monitors, etc. 
   System unit  82  may also couple to various input devices such as a keyboard  86 , a mouse  88 , a video camera, a trackball, a digitizing tablet, a six-degree of freedom input device, a head tracker, an eye tracker, a data glove, body sensors, etc. Application software may be executed by computer system  80  to display 3-D graphical objects on display devices  84 A and/or  84 B. 
     FIG. 2A  presents a simplified block diagram for one embodiment of computer system  80 . Computer system  80  comprises a host central processing unit (CPU)  102  and a 3-D graphics system  112  coupled to system bus  104 . A system memory  106  may also be coupled to system bus  104 . Other memory media devices such as disk drives, CD-ROMs, tape drives, etc. may be coupled to system bus  104 . 
   Host CPU  102  may be realized by any of a variety of processor technologies. For example, host CPU  102  may comprise one or more general purpose microprocessors, parallel processors, vector processors, digital signal processors, etc., or any combination thereof. System memory  106  may include one or more memory subsystems representing different types of memory technology. For example, system memory  106  may include read-only memory (ROM) and/or random access memory (RAM)—such as static random access memory (SRAM), synchronous dynamic random access memory (SDRAM) and/or Rambus dynamic access memory (RDRAM). 
   System bus  104  may comprise one or more communication buses or host computer buses (for communication between host processors and memory subsystems). In addition, various peripheral devices and peripheral buses may be connected to system bus  104 . 
   In one set of embodiments, graphics system  112  is configured to generate up to two video signals. Graphics system  112  may comprise one or more graphics boards (also referred to herein as graphics pipelines) configured according to the principles of the present invention. The graphics boards may be coupled together in a linear chain as suggested by  FIG. 2B , and may collaborate in the generation of video signals V A  and V B . Video signals V A  and V B  drive display devices  84 A and  84 B respectively. The number R of graphics boards comprising graphics system  112  may be chosen to match the combined pixel input bandwidth required by display devices  84 A and  84 B. The graphics boards may also couple to system bus  104  (e.g. by crossbar switches or any other type of bus connectivity logic). The first graphics board in the linear chain is denoted GB( 0 ), and the generic K th  graphics board in the linear chain is denoted GB(K). 
   It is noted the graphics boards may be programmed to allocate all their processing resources to the generation of a single video signal when needed or desired. For example, some users/customers may have a single high bandwidth display device. In this situation, all the graphics boards in graphics system  112  may be dedicated to one video channel, e.g. the channel which drives video signal V A . 
   In one embodiment, host CPU  102  may transfer data to and/or receive data from each graphics board GB(K) according to a programmed input/output (I/O) protocol over system bus  104 . In a second embodiment, each graphics board GB(K) may access system memory  106  according to a direct memory access (DMA) protocol or through intelligent bus-mastering. In yet another embodiment, the graphics boards may be coupled to system memory  106  through a direct port, such as an Advanced Graphics Port (AGP) promulgated by Intel Corporation. 
   One or more graphics applications conforming to an application programming interface (API) such as OpenGL™ or Java 3D® may execute on host CPU  102 . The graphics application(s) may control a scene composed of geometric objects in a world coordinate system. Each object may comprise a collection of graphics primitives (e.g. triangles). The graphics application may compress the graphics primitives, and transfer the compressed graphics data to one or more of the graphics boards GB( 0 ), GB( 1 ), GB( 2 ), . . . , GB(R- 1 ). 
   The first graphics board GB( 0 ) generates digital video streams X 0  and Y 0 . The second graphics board GB( 1 ) receives digital video streams X 0  and Y 0  from the first graphics board GB( 0 ), and transmits digital video streams X 1  and Y 1  to the third graphics board GB( 2 ). In general, graphics board GB(K), for K between  1  and (R- 2 ) inclusive, receives digital video streams X K−1  and Y K−1  from a previous graphics board GB(K−1), and transmits digital video streams X K  and Y K  to a next graphics board GB(K+1). 
   Each graphics board is responsible for filling in a portion of first video signal V A  and/or the second video signal V B . Thus, each digital video stream X K  may be more “filled in” than its predecessor X K−1 . The same observation holds for the digital video streams Y 0 , Y 1 , . . . , Y R-1 . The last graphics board GB(R- 1 ) receives digital video streams X R-2  and Y R-2  from the next-to-last graphics board GB(R- 2 ), and generates digital video streams X R-1  and Y R-1 . In addition to filling in the pixels for which it is responsible, the last graphics board GB(R- 1 ) converts the digital video streams X R-1  and Y R-1  into analog video signals V A  and V B  respectively for presentation to display devices  84 A and  84 B respectively. Thus, the last graphics board GB(R- 1 ) includes D/A conversion hardware. In one embodiment, the graphics boards are interchangeable, and thus, each of the graphics boards includes D/A conversion hardware. It is noted that display device  84 A and/or  84 B may be configured to receive digital video data, in which case the D/A conversion may be bypassed. 
   It is noted that the graphics boards comprising 3-D graphics system  112  may couple to one or more busses of various types in addition to system bus  104 . Furthermore, some or all of the graphics boards may couple to a communication port, and thereby, directly receive graphics data from an external source such as the Internet or a local area network. 
   Graphics boards may receive graphics data from any of various sources including: host CPU  102 , system memory  106  or any other memory, external sources such as a local area network, or a broadcast medium (e.g. television). While graphics system  112  is depicted as part of computer system  80 , graphics system  112  may also be configured as a stand-alone device. 
   Graphics system  112  may be comprised in any of various systems, including a network PC, a gaming play-station, an Internet appliance, a television (including an HDTV system or an interactive television system), or other devices which display 2D and/or 3D graphics. 
     FIG. 3 : Graphics Board GB(K) 
     FIG. 3  presents a block diagram for one embodiment of generic graphics board GB(K) for K=0, 1, 2, . . . , R- 1 . Graphics board GB(K) may comprise a graphics processing unit (GPU)  90 , a super-sampled sample buffer  162 , and one or more sample-to-pixel calculation units CU( 0 ) through CU(V- 1 ). Graphics board GB(K) may also comprise two digital-to-analog converters (DACs)  178 A and  178 B. 
   Graphics processing unit  90  may comprise any combination of processor technologies. For example, graphics processing unit  90  may comprise specialized graphics processors or calculation units, multimedia processors, DSPs, general purpose processors, programmable logic, reconfigurable logic, discrete logic, or any combination thereof. Graphics processing unit  90  may comprise one or more rendering units such as rendering units  150 A–D. Graphics processing unit  90  may also comprise one or more control units such as control unit  140 , one or more data memories such as data memories  152 A–D, and one or more schedule units such as schedule unit  154 . Sample buffer  162  may comprise one or more sample memories  160 A– 160 N. 
   Graphics board GB(K) may include two digital video input ports for receiving digital video streams X K−1  and Y K−1  (e.g. from a previous graphics board GB(K−1) in the linear chain of graphics boards). Similarly, graphics board GB(K) may include two digital video output ports for transmitting digital video streams X K  and Y K  to the next graphics board GB(K+1) in cases where graphics board GB(K) is not the last graphics board in the linear chain. 
   The principles described herein for the configuration of a two-channel graphics board naturally generalize to an arbitrary number of video channels. The present invention contemplates a graphics board GB(K) which supports L video channels, where L is any positive integer. Thus, graphics board GB(K) may have L input ports and L output ports, L digital-to-analog converters, etc. The parameter L is limited by fundamental design constraints such as cost, maximum power consumption, maximum board area, etc. 
   A. Control Unit  140   
   Control unit  140  operates as the interface between graphics board GB(K) and computer system  80  by controlling the transfer of data between graphics board GB(K) and computer system  80 . In embodiments of graphics board GB(K) that comprise two or more rendering units  150 A–D, control unit  140  may also partition the stream of data received from computer system  80  into a corresponding number of parallel streams that are routed to the individual rendering units  150 A–D. The graphics data may be received from computer system  80  in a compressed form. Graphics data compression may advantageously reduce the data traffic between computer system  80  and graphics board GB(K). In one embodiment, control unit  140  may be configured to split and route the received data stream to rendering units  150 A–D in compressed form. 
   The graphics data may comprise one or more graphics primitives. As used herein, the term graphics primitive includes polygons, parametric surfaces, splines, NURBS (non-uniform rational B-splines), sub-division surfaces, fractals, volume primitives, and particle systems. These graphics primitives are described in detail in the text book entitled “Computer Graphics: Principles and Practice” by James D. Foley, et al., published by Addison-Wesley Publishing Co., Inc., 1996. 
   It is noted that the embodiments and examples of the invention presented herein are described in terms of polygons for the sake of simplicity. However, any type of graphics primitive may be used instead of or in addition to polygons in these embodiments and examples. 
   B. Rendering Units 
   Rendering units  150 A–D (also referred to herein as draw units) are configured to receive graphics instructions and data from control unit  140  and then perform a number of functions which depend on the exact implementation. For example, rendering units  150 A–D may be configured to perform decompression (if the received graphics data is presented in compressed form), transformation, clipping, lighting, texturing, depth cueing, transparency processing, set-up, visible object determination, and virtual screen rendering of various graphics primitives occurring within the graphics data. Rendering units  150 A–D are intended to represent an arbitrary number of rendering units. 
   The graphics data received by each rendering unit  150  may be decompressed into one or more graphics “primitives” which may then be rendered. The term primitive refers to components of objects that define its shape (e.g., points, lines, triangles, polygons in two or three dimensions, polyhedra, or free-form surfaces in three dimensions). Each rendering unit  150  may be any suitable type of high performance processor (e.g., a specialized graphics processor or calculation unit, a multimedia processor, a digital signal processor, or a general purpose processor). 
   Graphics primitives or portions of primitives which survive a clipping computation may be projected onto a 2-D viewport. Instead of clipping in 3-D, graphics primitives may be projected onto a 2-D view plane (which includes the 2-D viewport) and then clipped with respect to the 2-D viewport. 
   Virtual screen rendering refers to calculations that are performed to generate samples for projected graphics primitives. For example, the vertices of a triangle in 3-D may be projected onto the 2-D viewport. The projected triangle may be populated with samples, and values (e.g. red, green, blue and z values) may be assigned to the samples based on the corresponding values already determined for the projected vertices. (For example, the red value for each sample in the projected triangle may be interpolated from the known red values of the vertices.) These sample values for the projected triangle may be stored in sample buffer  162 . A virtual image accumulates in sample buffer  162  as successive primitives are rendered. Thus, the 2-D viewport is said to be a virtual screen on which the virtual image is rendered. The sample values comprising the virtual image are stored into sample buffer  162 . Points in the 2-D viewport are described in terms of virtual screen coordinates x and y, and are said to reside in “virtual screen space”. See  FIG. 4  for an illustration of the two-dimensional viewport  420  populated with samples. 
   When the virtual image is complete, e.g., when all graphics primitives corresponding to a frame have been rendered, sample-to-pixel calculation units CU( 0 ) through CU(V- 1 ) may read the rendered samples from sample buffer  162 , and filter the samples to generate pixel values. Each sample-to-pixel calculation unit CU(J) may be assigned a region of the virtual screen space, and may operate on samples corresponding to the assigned region. It is generally advantageous for the union of these regions to cover 2-D viewport  420  to minimize waste of rendering bandwidth. Sample-to-pixel calculation units CU( 0 ) through CU(V- 1 ) may operate in parallel. 
   In the embodiment of graphics board GB(K) shown in  FIG. 3 , rendering units  150 A–D calculate sample values instead of pixel values. This allows rendering units  150 A–D to perform super-sampling, i.e. to calculate more than one sample per pixel. Super-sampling in the context of the present invention is discussed more thoroughly below. More details on super-sampling are discussed in the following books:
         “Principles of Digital Image Synthesis” by Andrew S. Glassner, 1995, Morgan Kaufmnan Publishing (Volume 1);   “The Renderman Companion” by Steve Upstill, 1990, Addison Wesley Publishing; and   “Advanced Renderman: Beyond the Companion” by Anthony A. Apodaca.       

   Sample buffer  162  may be double-buffered so that rendering units  150 A–D may write samples for a first virtual image into a first portion of sample buffer  162 , while a second virtual image is simultaneously read from a second portion of sample buffer  162  by sample-to-pixel calculation units CU. 
   C. Data Memories 
   Each of rendering units  150 A–D may be coupled to a corresponding one of instruction and data memories  152 A–D. In one embodiment, each of memories  152 A–D may be configured to store both data and instructions for a corresponding one of rendering units  150 A–D. While implementations may vary, in one embodiment, each data memory  152 A–D may comprise two 8 MByte SDRAMs, providing a total of 16 MBytes of storage for each of rendering units  150 A–D. In another embodiment, RDRAMs (Ram-bus DRAMs) may be used to support the decompression and set-up operations of each rendering unit, while SDRAMs may be used to support the draw functions of each rendering unit. Data memories  152 A–D may also be referred to as texture and render memories  152 A–D. 
   D. Schedule Unit 
   Schedule unit  154  may be coupled between rendering units  150 A–D and sample memories  160 A–N. Schedule unit  154  is configured to sequence the completed samples and store them in sample memories  160 A–N. Note in larger configurations, multiple schedule units  154  may be used in parallel. In one embodiment, schedule unit  154  may be implemented as a crossbar switch. 
   E. Sample Memories 
   Super-sampled sample buffer  162  comprises sample memories  160 A– 160 N, which are configured to store the plurality of samples generated by rendering units  150 A–D. As used herein, the term “sample buffer” refers to one or more memories which store samples. As previously noted, samples may be filtered to form each output pixel value. Output pixel values may be provided to display device  84 A and/or display device  84 B. 
   Sample buffer  162  may be configured to support super-sampling, critical sampling, or sub–sampling with respect to pixel resolution. In other words, the average distance between samples (X k ,Y k ) may be smaller than, equal to, or larger than the average distance between pixel centers in virtual screen space. Furthermore, because the convolution kernel C(X,Y) may take non-zero functional values over a neighborhood which spans several pixel centers, a single sample may contribute to several output pixel values. 
   Sample memories  160 A– 160 N may comprise any of various types of memories (e.g., SDRAMs, SRAMs, RDRAMs, 3DRAMs, or next-generation 3DRAMs) in varying sizes. In one embodiment, each schedule unit  154  is coupled to four banks of sample memories, where each bank comprises four 3DRAM-64 memories. Together, the 3DRAM-64 memories may form a 116-bit deep super-sampled sample buffer that stores multiple samples per pixel. For example, in one embodiment, each sample memory  160 A– 160 N may store up to sixteen samples per pixel. 3DRAM-64 memories are specialized memories configured to support full internal double buffering with single buffered Z in one chip. The double buffered portion comprises two RGBX buffers, where X. is a fourth channel that can be used to store other information (e.g., alpha). 3DRAM-64 memories also have a lookup table that takes in window ID information and controls an internal 2-1 or 3-1 multiplexer that selects which buffer&#39;s contents will be output. 3DRAM-64 memories are next-generation 3DRAM memories that may soon be available from Mitsubishi Electric Corporation&#39;s Semiconductor Group. In one embodiment, 32 chips used in combination are sufficient to create a double-buffered 1280×1024 super-sampled sample buffer with eight samples per pixel. 
   Since the 3DRAM-64 memories are internally double-buffered, the input pins for each of the two frame buffers in the double-buffered system are time multiplexed (using multiplexers within the memories). The output pins may be similarly time multiplexed. This allows reduced pin count while still providing the benefits of double buffering. 3DRAM-64 memories further reduce pin count by not having z output pins. Since z comparison and memory buffer selection are dealt with internally, use of the 3DRAM-64 memories may simplify the configuration of sample buffer  162 . For example, sample buffer  162  may require little or no selection logic on the output side of the 3DRAM-64 memories. The 3DRAM-64 memories also reduce memory bandwidth since information may be written into a 3DRAM-64 memory without the traditional process of reading data out, performing a z comparison or blend operation, and then writing data back in. Instead, the data may be simply written into the 3DRAM-64 memory, with the memory performing the steps described above internally. 
   However, in other embodiments of graphics board GB(K), other memories (e.g., SDRAMs, SRAMs, RDRAMs, or current generation 3DRAMs) may be used to form sample buffer  162 . 
   Graphics processing unit  90  may be configured to generate a plurality of sample positions according to a particular sample positioning scheme (e.g., a regular grid, a perturbed regular grid, etc.). Alternatively, the sample positions (or offsets that are added to regular grid positions to form the sample positions) may be read from a sample position memory (e.g., a RAM/ROM table). Upon receiving a polygon that is to be rendered, graphics processing unit  90  determines which samples fall within the polygon based upon the sample positions. Graphics processing unit  90  renders the samples that fall within the polygon and stores rendered samples in sample memories  160 A–N. Red, green, blue, alpha, z depth, and other per-sample values may also be calculated in the rendering process. 
   F. Sample-to-pixel Calculation Units 
   Sample-to-pixel calculation units CU( 0 ) through CU(V- 1 ) (collectively referred to as sample-to-pixel calculation units CU) may be coupled together in a linear succession as shown in  FIG. 3 . The first sample-to-pixel calculation unit CU( 0 ) in the linear succession may be programmed to receive digital video streams X K−1  and Y K−1  from a previous graphics board GB(K−1), and the last sample-to-pixel calculation unit CU(V- 1 ) in the linear succession may be programmed to transmit digital video streams X K  and Y K  to the next graphics board GB(K+1). 
   If graphics board GB(K) is the first graphics board in the linear chain of graphics boards shown in  FIG. 2B , first sample-to-pixel calculation unit CU( 0 ) may be programmed to disable its input FIFOs since there is no previous board driving input signals X K−1  and Y K−1 . If graphics board GB(K) is the last graphics board in the linear chain, the last sample-to-pixel calculation unit CU(V- 1 ) may be programmed to provide the digital video streams X K  and Y K  to digital-to-analog conversion units  178 A and  178 B respectively. 
   In one alternative embodiment, the first graphics board in the linear chain of graphics boards may be configured to receive one or more video streams from one or more digital cameras. The video streams may be provided to input ports X K−1  and Y K−1    
   In cases where J takes a value between 1 and V-2 inclusive, sample-to-pixel calculation unit CU(J) is configured to receive digital video input streams A J−1  and B J−1  from a previous sample-to-pixel calculation unit CU(J−1), and to transmit digital video output streams A J  and B J  to the next sample-to-pixel calculation unit CU(J+1). The first sample-to-pixel calculation CU( 0 ) is configured to receive digital video streams X K−1  and Y K−1  from a previous graphics board GB(K−1), and to transmit digital video stream A 0  and B 0  to the second sample-to-pixel calculation unit CU( 1 ). For notational uniformity, the digital video streams X K−1  and Y K−1  are also referred to as digital video streams A -1  and B -1  respectively. The last sample-to-pixel calculation unit CU(V- 1 ) receives digital video streams A V-2  and B V-2  from the previous sample-to-pixel calculation unit CU(V- 2 ), and generates digital video streams X K  and Y K  (which are also referred to herein as video streams A V-1  and B V-1 ). Sample-to-pixel calculation unit CU(V- 1 ) may be programmed to supply the digital video streams X K  and Y K  to a next graphics board GB(K+1) and/or to DAC units  178 A/ 178 B. 
   Video streams X 0 , X 1 , . . . , X R-1  generated by the linear chain of graphics boards, and video streams A 0 , A 1 , . . . , A V-1  generated by the sample-to-pixel calculation units in each of the graphics boards are said to belong to video stream A. Similarly, video streams Y 0 , Y 1 , . . . , Y R-1  generated by the linear chain of graphics boards, and video streams B 0 , B 1 , . . . , B V-1  generated by the sample-to-pixel calculation units in each of the graphics boards are said to belong to video stream B. 
   As described above, rendering units  150 A–D are configured to generate samples for graphics primitives, and to store the samples into sample buffer  162 . As successive graphics primitives are rendered, a sampled virtual image accumulates in sample buffer  162 . When the sampled virtual image is complete, i.e., when all graphics primitives comprising the virtual image have been rendered, each sample-to-pixel calculation unit CU(J) may access samples of the virtual image from sample buffer  162 , and may filter the samples to generate pixel values. Each sample-to-pixel calculation unit CU(J) may operate on samples residing in a corresponding region of the virtual screen space. The region assigned to each sample-to-pixel calculation unit CU(J) may be programmed at system initialization time. Often, it is desirable for the union of the regions to cover 2-D viewport  420 . Thus, the sample-to-pixel calculation units may partition the labor of transforming sample values into pixel values. 
   Sample-to-pixel calculation unit CU(J) may perform a spatial convolution of a portion of the sampled virtual image with respect to a convolution kernel C(x,y) to generate pixel values. For example, a red value R p  for a pixel P may be computed at a location (x p ,y p ) in virtual screen space based on the relation 
           R   p     =       1   E     ⁢     ∑       C   ⁡     (         x   k     -     x   p       ,       y   k     -     y   p         )       ⁢     R   ⁡     (       x   k     ,     y   k       )               ,       
 
where the summation is evaluated at samples (x k ,y k ) in the vicinity of location (x p ,y p ). Since convolution kernel C(x,y) is non-zero only in a neighborhood of the origin, the displaced kernel C(x−x p , y−y p ) may take non-zero values only in a neighborhood of location (x p ,y p ).
 
   The value E is a normalization value that may be computed according to the relation
 
 E=ΣC ( x   k   −x   p   , y   k   −y   p ),
 
where the summation is evaluated for the same samples (x k ,y k ) as in the red pixel value summation above. The summation for the normalization value E may be performed in parallel with the red pixel value summation. The location (x p ,y p ) may be referred to herein as a virtual pixel center or virtual pixel origin.  FIG. 4  shows the support  72  (i.e. footprint) of a convolution kernel. In this case, the virtual pixel center (x p ,y p ) corresponds to the center of the support disk  72 .
 
   Similar summations may be performed to compute green, blue and alpha pixel values in terms of the green, blue and alpha sample values respectively. An adder tree may be employed to speed up the computation of such summations. Two or more adder trees may be employed in a parallel fashion, i.e. to concurrently perform two or more of the red, green, blue, alpha and normalization constant summations. 
   Sample-to-pixel calculation unit CU(J) mixes (e.g. blends or injects) the pixel values it computes into either video stream A or video stream B. The assignment of sample-to-pixel calculation unit CU(J) to video stream A or video stream B may be performed at system initialization time. For example, if sample-to-pixel calculation unit CU(J) has been assigned to video stream A, sample-to-pixel calculation unit CU(J) mixes its computed pixel values into video stream A, and passes video stream B unmodified to the next sample-to-pixel calculation unit CU(J+1), or next graphics board. In other words, sample-to-pixel calculation unit CU(J) mixes at least a subset of the dummy pixel values present in video stream A J−1  with its locally computed pixel values. The resultant video stream A J  is transmitted to the next sample-to-pixel calculation unit or graphics board. 
   In one embodiment, sample-to-pixel calculation units CU(J) may implement a super-sampled reconstruction band-pass filter to compute pixel values from samples stored in sample buffer  162 . The support of the band-pass filter may cover a rectangular area in virtual screen space which is M p  pixels high and N p  pixels wide. Thus, the number of samples covered by the band-pass filter is approximately equal to M p N p S, where S is the number of samples per pixel region. A variety of values for M p , N p  and S are contemplated. For example, in one embodiment of the band-pass filter M p =N p =5. It is noted that with certain sample positioning schemes (see the discussion attending  FIGS. 5A ,  5 B and  5 C), the number of samples that fall within the filter support may vary as the filter center (i.e. the virtual pixel center) is moved in the virtual screen space. 
   In other embodiments, sample-to-pixel calculation units CU(J) may filter a selected number of samples to calculate an output pixel value. The selected samples may be multiplied by a spatial weighting function that gives weights to samples based on their position with respect to the filter center (i.e. the virtual pixel center). 
   Any of a variety of filters may be used either alone or in combination, e.g., the box filter, the tent filter, the cone filter, the cylinder filter, the Gaussian filter, the Catmull-Rom filter, the Mitchell-Netravali filter, the windowed sinc filter, or in general, any form of bandpass filter or any of various approximations to the sinc filter. Furthermore, the support of the filters used by sample-to-pixel calculation unit CU(J) may be circular, elliptical, rectangular (e.g. square), triangular, hexagonal, etc. 
   Sample-to-pixel calculation unit CU(J) may also be configured with one or more of the following features: color look-up using pseudo color tables, direct color, inverse gamma correction, and conversion of pixels to non-linear light space. Other features of sample-to-pixel calculation unit CU(J) may include programmable video timing generators, programmable pixel clock synthesizers, cursor generators, and crossbar functions. 
   G. Digital-to-Analog Converters 
   Digital-to-analog converter (DAC)  178 A receives digital video stream X K  from last sample-to-pixel calculation unit CU(V- 1 ), and converts digital video stream X K  into an analog video signal V A  for transmission to display device  84 A. Similarly, DAC  178 B receives digital video stream Y K  from last sample-to-pixel calculation unit CU(V- 1 ), and converts digital video stream Y K  into an analog video signal V B  for transmission to display device  84 B. Digital-to-Analog Converters (DACs)  178 A and  178 B are collectively referred to herein as DACs  178 . It is noted that DACs  178  may be disabled in all graphics boards except for the last graphics board GB(R- 1 ) which is physically coupled to display devices  84 A and  84 B. See  FIG. 2B . 
   In the preferred embodiment, last sample-to-pixel calculation unit CU(V- 1 ) provides digital video stream X K  to DAC  178 A without an intervening frame buffer. Similarly, last sample-to-pixel calculation unit CU(V- 1 ) provides digital video stream Y K  to DAC  178 B without an intervening frame buffer. However, in one alternative embodiment, one or more frame buffers and/or line buffers intervene between last sample-to-pixel calculation unit CU(V- 1 ) and DAC  178 A and/or DAC  178 B. 
   DAC  178 A and/or DAC  178 B may be bypassed or omitted completely in order to output digital pixel data in lieu of analog video signals. This may be useful where display devices  84 A and/or  84 B are based on a digital technology (e.g., an LCD-type display, an LCOS display, or a digital micro-mirror display). 
   It is noted that various embodiments of graphics board GB(K) are contemplated with varying numbers of render units  150 , and varying numbers of sample-to-pixel calculation units CU. Furthermore, alternative embodiments of graphics board GB(K) are contemplated for generating more than (or less than) two simultaneous video streams. 
     FIGS. 5A–C : Super-Sampling 
     FIG. 5A  illustrates a portion of virtual screen space in a non-super-sampled example. The small circles denote sample locations, and the rectangular boxes superimposed on virtual screen space define pixels regions (i.e. regions of virtual screen space whose width and height correspond respectively to the horizontal distance and vertical distance between pixels.) One sample is located in each pixel region. For example, sample  74  is located in pixel region  70  which is denoted in cross hatch. Rendering units  150  compute values such as red, green, blue, and alpha for each sample. Although one sample location populates each pixel region, sample-to-pixel calculation units CU may still compute output pixel values (e.g. red, green, blue, and alpha) based on multiple samples, e.g. by using a convolution filter whose support spans several pixel regions. 
   Turning now to  FIG. 5B , an example of one embodiment of super-sampling is illustrated. In this embodiment, two samples are computed per pixel region. For example, samples  74 A and  74 B are located in pixel region  70  which is denoted in cross hatch. The samples are distributed according to a regular grid. Even though there are more samples than pixels in  FIG. 5B , output pixel values could be computed using one sample per pixel, e.g. by throwing out all but the sample nearest to the center of each pixel. However, a number of advantages arise from computing pixel values based on multiple samples. 
   A support region  72  is superimposed over the center pixel (corresponding to the center square) of  FIG. 5B , and illustrates the support (i.e. the domain of definition) of a convolution filter. The support of a filter is the set of locations over which the filter is defined. In this example, the support region  72  is a circular disc. The output pixel values (e.g. red, green, blue and alpha values) for the center pixel are determined only by samples  74 C and  74 D, because these are the only samples which fall within support region  72 . This filtering operation may advantageously improve the realism of a displayed image by smoothing abrupt edges in the displayed image (i.e., by performing anti-aliasing). The filtering operation may simply average the values of samples  74 C and  74 D to form the corresponding output values for the center pixel. More generally, the filtering operation may generate a weighted sum of the values of samples  74 C and  74 D, where the contribution of each sample is weighted according to some function of the sample&#39;s position (or distance) with respect to the center of support region  72 . The filter, and thus support region  72 , may be repositioned for each output pixel being calculated. For example, the filter center may visit the center of each pixel region for which pixel values are to be computed. Other filters and filter positioning schemes are also possible and contemplated. 
   In the example of  FIG. 5B , there are two samples per pixel. In general, however, there is no requirement that the number of samples be related to the number of pixels. The number of samples may be completely independent of the number of pixels. For example, the number of samples may be smaller than the number of pixels. 
   Turning now to  FIG. 5C , another embodiment of super-sampling is illustrated. In this embodiment, the samples are positioned randomly. Thus, the number of samples used to calculate output pixel values may vary from pixel to pixel. Render units  150 A–D calculate color information at each sample position. 
     FIGS. 6–12 : Super-Sampled Sample Buffer with Real-Time Convolution 
     FIG. 6  illustrates one possible configuration for the flow of data through one embodiment of generic graphics board GB(K). As the figure shows, geometry data  350  is received by graphics board GB(K) and used to perform draw process  352 . The draw process  352  may be implemented by one or more of control unit  140 , rendering units  150 , data memories  152 , and schedule unit  154 . Geometry data  350  comprises data for one or more polygons. Each polygon comprises a plurality of vertices (e.g., three vertices in the case of a triangle), some of which may be shared among multiple polygons. Data such as spatial coordinates, color data and normal vector data may be included for each vertex. 
   In addition to the vertex data, draw process  352  (which may be performed by rendering units  150 A–D) also receives sample position information from a sample position memory  354 . The sample position information defines the location of samples in virtual screen space, i.e. in the 2-D viewport. Draw process  352  selects the samples that fall within the polygon currently being rendered, calculates a set of values (e.g. red, green, blue, z, alpha, and/or depth of field information) for each of these samples based on their respective positions within the polygon. For example, the z value of a sample that falls within a triangle may be interpolated from the known z values of the three vertices. Each set of computed sample values are stored into sample buffer  162 . 
   In one embodiment, sample position memory  354  is embodied within rendering units  150 A–D. In another embodiment, sample position memory  354  may be realized as part of data memories  152 A– 152 D, or as a separate memory. 
   Sample position memory  354  may store sample positions in terms of their virtual screen coordinates (x,y). Alternatively, sample position memory  354  may be configured to store only offsets dx and dy for the samples with respect to positions on a regular grid. Storing only the offsets may use less storage space than storing the entire coordinates (x,y) for each sample. The sample position information stored in sample position memory  354  may be read by a dedicated sample position calculation unit (not shown) and processed to calculate sample positions for graphics processing unit  90 . More detailed information on the computation of sample positions is included below. 
   In another embodiment, sample position memory  354  may be configured to store a table of random numbers. Sample position memory  354  may also comprise dedicated hardware to generate one or more different types of regular grids. This hardware may be programmable. The stored random numbers may be added as offsets to the regular grid positions generated by the hardware. In one embodiment, sample position memory  354  may be programmable to access or “unfold” the random number table in a number of different ways, and thus, may deliver more apparent randomness for a given length of the random number table. Thus, a smaller table may be used without generating the visual artifacts caused by simple repetition of sample position offsets. 
   Sample-to-pixel calculation process  360  uses the same sample positions as draw process  352 . Thus, in one embodiment, sample position memory  354  may generate a sequence of random offsets to compute sample positions for draw process  352 , and may subsequently regenerate the same sequence of random offsets to compute the same sample positions for sample-to-pixel calculation process  360 . In other words, the unfolding of the random number table may be repeatable. Thus, it may not be necessary to store sample positions at the time of their generation for draw process  352 . 
   As shown in  FIG. 6 , sample position memory  354  may be configured to store sample offsets generated according to a number of different schemes such as a regular grid (e.g. a rectangular grid, hexagonal grid, etc.), a perturbed regular grid, or a random (stochastic) distribution. Graphics board GB(K) may receive an indication from the operating system, device driver, or the geometry data  350  that indicates which type of sample positioning scheme is to be used. Thus, sample position memory  354  may be configurable or programmable to generate position information according to one or more different schemes. 
   In one embodiment, sample position memory  354  may comprise a RAM/ROM that contains stochastically determined sample points or sample offsets. Thus, the density of samples in virtual screen space may not be uniform when observed at small scale. Two regions with equal area centered at different locations in virtual screen space may contain different numbers of samples. 
   An array of bins may be superimposed over the 2-D viewport  420  of  FIG. 4 , and the storage of samples in sample buffer  162  may be organized in terms of bins. Sample buffer  162  may comprise an array of memory blocks which correspond to the bins. Each memory block may store the sample values (e.g. red, green, blue, z, alpha, etc.) for the samples that fall within the corresponding bin. (See the exploded view of Bin #I in  FIG. 6 .) The approximate location of a sample is given by the bin in which it resides. The memory blocks may have addresses which are easily computable from the corresponding bin locations in virtual screen space, and vice versa. Thus, the use of bins may simplify the storage and access of sample values in sample buffer  162 . 
   Suppose (for the sake of discussion) that the 2-D viewport  420  ranges from (0000,0000) to (FFFF,FFFF) in hexadecimal virtual screen coordinates. Also suppose that 2-D viewport  420  is overlaid with a rectangular array of bins whose lower-left corners reside at the locations (XX00,YY00) where XX and YY independently run from 0×00 to 0×FF. Thus, there are 256 bins in each of the vertical and horizontal directions with each bin spanning a square in virtual screen space with side length of 256. Suppose that each memory block is configured to store sample values for up to 16 samples, and that the set of sample values for each sample comprises 4 bytes. In this case, the address of the memory block corresponding to the bin located at (XX00,YY00) may be simply computed by the relation BinAddr=(XX+YY*256)*16*4. For example, the sample S=(1C3B,23A7) resides in the bin located at (1C00,2300). The sample value set for sample S is then stored in the memory block residing at address 0×8C700=(0×231C)(0×40) in sample buffer  162 . 
   The bins may tile the 2-D viewport in a regular array, e.g. in a square array, rectangular array, triangular array, hexagonal array, etc., or in an irregular array. Bins may occur in a variety of sizes and shapes. The sizes and shapes may be programmable. The maximum number of samples that may populate a bin is determined by the storage space allocated to the corresponding memory block. This maximum number of samples is referred to herein as the bin sample capacity, or simply, the bin capacity. The bin capacity may take any of a variety of values. The bin capacity value may be programmable. Henceforth, the memory blocks in sample buffer  162  which correspond to the bins in virtual screen space will be referred to as memory bins. 
   The specific position of each sample within a bin may be determined by looking up the sample&#39;s offset in the RAM/ROM table, i.e., the sample&#39;s offset with respect to the bin position (e.g. the lower-left corner or center of the bin, etc.). However, depending upon the implementation, not all choices for the bin capacity may have a unique set of offsets stored in the RAM/ROM table. Offsets for a first bin capacity value may be determined by accessing a subset of the offsets stored for a second larger bin capacity value. In one embodiment, each bin capacity value supports at least four different sample positioning schemes. 
   In one embodiment, sample position memory  354  may store pairs of 8-bit numbers, each pair comprising an x-offset and a y-offset. (Other offsets are also possible, e.g., a time offset, a z-offset, etc.) When added to a bin position, each pair defines a particular position in virtual screen space, i.e. in 2-D viewport  420 . To improve read access times, sample position memory  354  may be constructed in a wide/parallel manner so as to allow the memory to output more than one sample location per read cycle. 
   Once the sample positions have been read from sample position memory  354 , draw process  352  selects the samples that fall within the polygon currently being rendered. Draw process  352  may then calculate per-sample values such as color, z depth and alpha for each of these interior samples and stores the per-sample values into sample buffer  162 . In one embodiment, sample buffer  162  may only single-buffer z values (and perhaps alpha values) while double-buffering other sample components such as color. Unlike prior art systems, graphics system  112  may use double-buffering for all samples (although not all components of each sample may be double-buffered, i.e., the samples may have some components that are not double-buffered). In one embodiment, the samples are stored into sample buffer  162  in bins. In some embodiments, the bin capacity may vary from frame to frame. In addition, the bin capacity may vary spatially for bins within a single frame rendered into sample buffer  162 . For example, bins on the edge of 2-D viewport  420  may have a smaller bin capacity than bins corresponding to the center of 2-D viewport  420 . Since viewers are likely to focus their attention mostly on the center of a displayed image, more processing bandwidth may be dedicated to providing enhanced image quality in the center of 2-D viewport  420 . Note that the size and shape of bins may also vary from region to region, or from frame to frame. The use of bins will be described in greater detail below in connection with  FIG. 8 . 
   For additional information on generating sample positions according to various sample positioning scheme, please refer to U.S. patent application Ser. No. 09/251,840 filed on Feb. 17, 1999 entitled “A Graphics System With A Variable-Resolution Sampler Buffer” which is hereby incorporated by reference. 
   Filter process  360  represents the action of sample-to-pixel calculation units CU in generating digital video streams X K  and Y K  which are transmitted to the next graphics board GB(K+1), or converted into video signals V A  and V B  for presentation to display devices  84 A and  84 B. Thus, any description of sample-to-pixel calculation units CU may be interpreted as a description of filter process  360 . Filter process  360  operates in parallel with draw process  352 . 
   Generic sample-to-pixel calculation unit CU(J) is configured to (a) read sample positions from sample position memory  354 , (b) read corresponding sample values from sample buffer  162 , (c) filter the sample values, and (d) mix (e.g. blend or multiplex) the resulting pixel values into video stream A or B. Sample-to-pixel calculation unit CU(J) generates the red, green, blue and alpha values for an output pixel based on a spatial filtering of the corresponding data for a selected plurality of samples, e.g. samples falling in a neighborhood of a pixel center. In one set of embodiments, sample-to-pixel calculation unit CU(J) is configured to: (i) determine the distance of each sample from the pixel center; (ii) multiply each sample&#39;s attribute values (e.g., red, green, blue, alpha) by a filter weight that is a specific (programmable) function of the sample&#39;s distance; (iii) generate sums of the weighted attribute values, one sum per attribute (e.g. a sum for red, a sum for green, . . . ), and (iv) normalize the sums to generate the corresponding pixel attribute values. 
   In the set of embodiments just described, the filter kernel is a function of distance from the pixel center. However, in alternative embodiments, the filter kernel may be a more general function of x and y displacements from the pixel center. Also, the support of the filter, i.e. the domain of definition of the filter kernel, may not be a circular disk. 
     FIG. 7  illustrates an alternate embodiment of graphics board GB(K). In this embodiment, two or more sample position memories  354 A and  354 B are utilized. Sample position memories  354 A–B may be used to implement double-buffering of sample position data. If the sample positions remain the same from frame to frame, the sample positions may be single-buffered. However, if the sample positions vary from frame to frame, then graphics board GB(K) may be advantageously configured to double-buffer the sample positions. The sample positions may be double-buffered on the rendering side (i.e., memory  354 A may be double-buffered) and/or the filter side (i.e., memory  354 B may be double-buffered). Other combinations are also possible. For example, memory  354 A may be single-buffered, while memory  354 B is doubled-buffered. This configuration may allow one side of memory  354 B to be updated by sample position memory  354 A while the other side of memory  354 B is accessed by filter process  360 . In this configuration, graphics board GB(K) may change sample positioning schemes on a per-frame basis by transferring the sample positions (or offsets) from memory  354 A to double-buffered memory  354 B as each frame is rendered. Thus, the sample positions which are stored in memory  354 A and used by draw process  352  to render sample values may be copied to memory  354 B for use by filter process  360 . Once the sample position information has been copied to memory  354 B, position memory  354 A may then be loaded with new sample positions (or offsets) to be used for a second frame to be rendered. In this way the sample position information follows the sample values from the draw process  352  to the filter process  360 . 
   Yet another alternative embodiment may store tags with the sample values in super-sampled sample buffer  162 . These tags may be used to look-up the offsets (i.e. perturbations) dx and dy associated with each particular sample. 
   FIG.  8 —Converting Samples into Pixels 
   As discussed earlier, 2-D viewport  420  may be covered with an array of spatial bins. Each spatial bin may be populated with samples whose positions are determined by sample position memory  354 . Each spatial bin corresponds to a memory bin in sample buffer  162 . A memory bin stores the sample values (e.g. red, green, blue, z, alpha, etc.) for the samples that reside in the corresponding spatial bin. Sample-to-pixel calculation units CU (also referred to as convolve units CU) are configured to read memory bins from sample buffer  162  and to generate pixel values from the sample values contained within the memory bins. 
     FIG. 8  illustrates one embodiment of graphics board GB(K) which provides for rapid computation of pixel values from sample values. Elements on the rendering side of graphics graphic board GB(K) have been suppressed in  FIG. 8  for simplicity of illustration. The spatial bins which cover 2-D viewport  420  may be organized into columns (e.g., Cols.  0 ,  1 ,  2 ,  3 ). Each column comprises a two-dimensional subarray of spatial bins. The columns may be configured to horizontally overlap (e.g., by one or more spatial bins). Each of sample-to-pixel calculation units CU( 0 ) through CU( 3 ) may be configured to access memory bins corresponding to one of the columns. For example, sample-to-pixel calculation unit CU( 1 ) may be configured to access memory bins that correspond to the spatial bins of Column  1 . The data pathways between sample buffer  162  Band sample-to-pixel calculations unit CU may be optimized to support this column-wise correspondence. 
     FIG. 8  shows four sample-to-pixel calculation units for the sake of discussion. However, the inventive principles disclosed in the embodiment of  FIG. 8  naturally generalize to any number of sample-to-pixel calculation units. 
   The amount of the overlap between columns may depend upon the horizontal diameter of the filter support for the filter kernel being used. The example shown in  FIG. 8  illustrates an overlap of two bins. Each square (such as square  188 ) represents a single bin comprising one or more samples. Advantageously, this configuration may allow sample-to-pixel calculation units CU to work independently and in parallel, with each sample-to-pixel calculation units CU(J) receiving and convolving samples residing in the memory bins of the corresponding column. Overlapping the columns will prevent visual bands or other artifacts from appearing at the column boundaries for any operators larger than a pixel in extent. 
   Furthermore, the embodiment of  FIG. 8  may include a plurality of bin caches  176  which couple to sample buffer  162 . In addition, each of bin caches  176  couples to a corresponding one of sample-to-pixel calculation units CU. Bin cache  176 -I (where I takes any value from zero to three) stores a collection of memory bins from Column I, and serves as a cache for sample-to-pixel calculation unit CU(I). Bin cache  176 -I may have an optimized coupling to sample buffer  162  which facilitates access to the memory bins for Column I. Since the convolution calculation for two adjacent convolution centers may involve many of the same memory bins, bin caches  176  may increase the overall access bandwidth to sample buffer  162 . 
     FIG. 9A  illustrates more details of one embodiment of a method for reading sample values from super-sampled sample buffer  162 . As the figure illustrates, the convolution filter kernel  400  travels across Column I (in the direction of arrow  406 ) to generate output pixel values, where index I takes any value in the range from one to four. Sample-to-pixel calculation unit CU(I) may implement the convolution filter kernel  400 . Bin cache  176 -I may be used to provide fast access to the memory bins corresponding to Column I. Column I comprises a plurality of bin rows. Each bin row is a horizontal line of spatial bins which stretches from the left column boundary  402  to the right column boundary  404  and spans one bin vertically. In one embodiment, bin cache  176 -I has sufficient capacity to store N L  bin rows of memory bins. The cache line-depth parameter N L  may be chosen to accommodate the support of filter kernel  400 . If the support of filter kernel  400  is expected to span no more than N V  bins vertically (i.e. in the Y direction), the cache line-depth parameter N L  may be set equal to N V  or larger. 
   After completing convolution computations at a convolution center, convolution filter kernel  400  shifts to the next convolution center. Kernel  400  may be visualized as proceeding horizontally within Column I in the direction indicated by arrow  406 . When kernel  400  reaches the right boundary  404  of Column I, it may shift down one or more bin rows, and then, proceed horizontally starting from the left column boundary  402 . Thus the convolution operation proceeds in a scan line fashion, generating successive rows of output pixels for display. 
   In one embodiment, the cache line-depth parameter N L  is set equal to N v +1. In the example of  FIG. 9A , the filter support covers N V =5 bins vertically. Thus, the cache line-depth parameter N L =6=5+1. The additional bin row in bin cache  176 -I allows the processing of memory bins (accessed from bin cache  176 -I) to be more substantially out of synchronization with the loading of memory bins (into bin cache  176 -I) than if the cache line-depth parameter N L  were set at the minimum value N V . 
   In one embodiment, sample buffer  162  and bin cache  176 -I may be configured for row-oriented burst transfers. If a request for a memory bin misses in bin cache  176 -I, the entire bin row containing the requested memory bin may be fetched from sample buffer  162  in a burst transfer. Thus, the first convolution of a scan line may fill the bin cache  176 -I with all the memory bins necessary for all subsequent convolutions in the scan line. For example, in performing the first convolution in the current scan line at the first convolution center  405 , sample-to-pixel calculation unit CU(I) may assert a series of requests for memory bins, i.e. for the memory bins corresponding to those spatial bins (rendered in shade) which intersect the support of filter kernel  400 . Because the filter support  400  intersects five bin rows, in a worst case scenario, five of these memory bin requests will miss bin cache  176 -I and induce loading of all five bin rows from sample buffer  162 . Thus, after the first convolution of the current scan line is complete, bin cache  176 -I may contain the memory bins indicated by the heavily outlined rectangle  407 . Memory bin requests asserted by all subsequent convolutions in the current scan line may hit in bin cache  176 -I, and thus, may experience significantly decreased bin access time. 
   In general, the first convolution in a given scan line may experience fewer than the worst case number of misses to bin cache  176 -I because bin cache  176 -I may already contain some or all of the bin rows necessary for the current scan line. For example, if convolution centers are located at the center of each spatial bin, the vertical distance between successive scan lines (of convolution centers) corresponds to the distance between successive bin rows, and thus, the first convolution of a scan line may induce loading of a single bin row, the remaining four bin rows having already been loaded in bin cache  176 -I in response to convolutions in previous scan lines. 
   If the successive convolution centers in a scan line are expected to depart from a purely horizontal trajectory across Column I, the cache line-depth parameter N L  may be set to accommodate the maximum expected vertical deviation of the convolution centers. For example, in  FIG. 9B , the convolution centers follow a curved path across Column I. The curved path deviates from a horizontal path by approximately two bins vertically. Since the support of the filter kernel covers a 3 by 3 array of spatial bins, bin cache  176 -I may advantageously have a cache line-depth N L  of at least five (i.e. two plus three). 
   As mentioned above, Columns 0 through 3 of 2-D viewport  420  may be configured to overlap horizontally. The size of the overlap between adjacent Columns may be configured to accommodate the maximum expected horizontal deviation of convolution centers from nominal convolution centers on a rectangular grid. 
     FIG. 10  Rendering Samples into a Super-Sampled Sample Buffer 
     FIG. 10  is a flowchart of one embodiment of a method for drawing or rendering samples into a sample buffer. Certain of the steps of  FIG. 10  may occur concurrently or in different orders. In step  200 , graphics board GB(K) receives graphics commands and graphics data from the host CPU  102  or directly from system memory  106 . In step  202 , the graphics instructions and data are routed to one or more of rendering units  150 A–D. In step  204 , rendering units  150 A–D determine if the graphics data is compressed. If the graphics data is compressed, rendering units  150 A–D decompress the graphics data into a useable format, e.g., triangles, as shown in step  206 . Next, the triangles are processed and converted to an appropriate space for lighting and clipping prior to the perspective divide and transform to screen space (as indicated in step  208 A). 
   If graphics board GB(K) implements variable resolution super-sampling, then the triangles may be compared with a set of sample-density region boundaries (step  208 B). In variable-resolution super-sampling, different regions of 2-D viewport  420  may be allocated different sample densities based upon a number of factors (e.g., the center of the attention of an observer as determined by eye or head tracking). If the triangle crosses a sample-density region boundary (step  210 ), then the triangle may be divided into two smaller polygons along the region boundary (step  212 ). The polygons may be further subdivided into triangles if necessary (since the generic slicing of a triangle gives a triangle and a quadrilateral). Thus, each newly formed triangle may be assigned a single sample density. In one embodiment, graphics board GB(K) may be configured to render the original triangle twice, i.e. once with each sample density, and then, to clip the two versions to fit into the two respective sample density regions. 
   In step  214 , one of the sample positioning schemes (e.g., regular, perturbed regular, or stochastic) is selected from sample position memory  354 . The sample positioning scheme will generally have been pre-programmed into the sample position memory  354 , but may also be selected “on the fly”. In step  216 , rendering units  150 A–D may determine which spatial bins contain samples located within the triangle&#39;s boundaries, based upon the selected sample positioning scheme and the size and shape of the spatial bins. In step  218 , the offsets dx and dy for the samples within these spatial bins are then read from sample position memory  354 . In step  220 , each sample&#39;s position is then calculated using the offsets dx and dy and the coordinates of the corresponding bin origin, and is compared with the triangle&#39;s edges to determine if the sample is within the triangle. 
   For each sample that is determined to be within the triangle, one of rendering units  150 A–D draws the sample by calculating the sample&#39;s color, alpha and other attributes. This may involve a lighting calculation and an interpolation based upon the color and texture map information associated with the vertices of the triangle. Once the sample is rendered, it may be forwarded to schedule unit  154 , which then stores the sample in sample buffer  162  (as indicated in step  224 ). 
   The embodiment of the rendering method described above is used for explanatory purposes only and is not meant to be limiting. For example, in some embodiments, the steps shown in  FIG. 10  as occurring serially may be implemented in parallel. Furthermore, some steps may be reduced or eliminated in certain embodiments of the graphics system (e.g., steps  204 – 206  in embodiments that do not implement geometry compression, or steps  210 – 212  in embodiments that do not implement a variable resolution super-sampled sample buffer). 
   FIG.  11 —Generating Output Pixel Values from Sample Values 
     FIG. 11  is a flowchart of one embodiment of a method for selecting and filtering samples stored in sample buffer  162  to generate output pixel values. In step  250 , a stream of memory bins are read from sample buffer  162 . In step  252 , these memory bins may be stored in one or more of bin caches  176  to allow sample-to-pixel calculation units CU easy access to sample values during the convolution operation. In step  254 , the memory bins are examined to determine which of the memory bins may contain samples that contribute to the output pixel value currently being generated. The support (i.e. foot-print) of the filter kernel  400  (see  FIG. 9A ) intersects a collection of spatial bins. The memory bins corresponding to these spatial bins may contain sample values that contribute to the current output pixel. 
   Each sample in the selected bins (i.e. bins that have been identified in step  254 ) is then individually examined to determine if the sample does indeed contribute (as indicated in steps  256 – 258 ) to the current output pixel. This determination may be based upon the distance (or position) of the sample from (with respect to) the filter center. 
   In one embodiment, sample-to-pixel calculation units CU may be configured to calculate this sample distance (i.e., the distance of the sample from the filter center) and then use it to index into a table storing filter weight values (as indicated in step  260 ). In another embodiment, however, the potentially expensive calculation for determining the distance from the center of the pixel to the sample (which typically involves a square root function) may be avoided by using distance squared to index into the table of filter weights. In one embodiment, this squared-distance indexing scheme may be facilitated by using a floating point format for the squared distance (e.g., four or five bits of mantissa and three bits of exponent), thereby allowing much of the accuracy to be maintained while compensating for the increased range in values. In one embodiment, the table of filter weights may be implemented in ROM. However, RAM tables may also be used. Advantageously, RAM tables may, in some embodiments, allow sample-to-pixel calculation unit CU(J) to vary the filter coefficients on a per-frame or per-session basis. For example, the filter coefficients may be varied to compensate for known shortcomings of display devices  84 A/ 84 B or to accommodate the user&#39;s personal preferences. 
   The filter coefficients may also vary as a function of filter center position within the 2-D viewport  420 , or on a per-output pixel basis. In one embodiment, specialized hardware (e.g., multipliers and adders) may be used to compute filter weights for each sample. Samples which fall outside the support of filter kernel  400  may be assigned a filter weight of zero (step  262 ), or they may be excluded from the calculation entirely. 
   In one alternative embodiment, the filter kernel may not be expressible as a function of distance with respect to the filter center. For example, a pyramidal tent filter is not expressible as a function of Euclidean distance from the filter center. Thus, filter weights may be tabulated (or computed) in terms of x and y sample-displacements with respect to the filter center, or with respect to a non-Euclidean distance from the filter center. 
   Once the filter weight for a sample has been determined, the attribute values (e.g. red, green, blue, alpha, etc.) for the sample may then be multiplied by the filter weight (as indicated in step  264 ). Each of the weighted attribute values may then be added to a corresponding cumulative sum—one cumulative sum for each attribute—as indicated in step  266 . The filter weight itself may be added to a cumulative sum of filter weights (as indicated in step  268 ). Step  268  may be performed in parallel with step  264  and/or  266 . 
   After all samples residing in the support of the filter have been processed, the cumulative sums of the weighted attribute values may be divided by the cumulative sum of filter weights (as indicated in step  270 ). It is noted that the number of samples which fall within the filter support may vary as the filter center moves within the 2-D viewport. The normalization step  270  compensates for the variable gain which is introduced by this nonuniformity in the number of included samples, and thus, prevents the computed pixel values from appearing too bright or too dark due to the sample number variation. Finally, the normalized output pixels may be gamma corrected, and mixed (e.g. blended or multiplexed) into video stream A or video stream B as indicated by step  274 . 
   FIG.  12 —Example Output Pixel Convolution 
     FIG. 12  illustrates a simplified example of an output pixel convolution with a filter kernel which is radially symmetric and piecewise constant. As the figure shows, four bins  288 A–D contain samples that contribute to the output pixel convolution. In this example, the center of the output pixel is located at the shared corner of bins  288 A– 288 D. Each bin comprises sixteen samples, and an array of four bins (2×2) is filtered to generate the attribute values (red, green, blue, alpha) for the output pixel. Since the filter kernel is radially symmetric, the distance of each sample from the pixel center determines the filter value which will be applied to the sample. For example, sample  296  is relatively close to the pixel center, and thus falls within the region of the filter having a filter value of 8. Similarly, samples  294  and  292  fall within the regions of the filter having filter values of 4 and 2, respectively. Sample  290 , however, falls outside the maximum filter radius, and thus receives a filter value of 0. Thus, sample  290  will not contribute to the computed attribute values for the output pixel. Because the filter kernel is a decreasing function of distance from the pixel center, samples close to the pixel center contribute more to the computed attribute values than samples farther from the pixel center. This type of filtering may be used to perform image smoothing or anti-aliasing. 
   Example attribute values for samples  290 – 296  are illustrated in boxes  300 – 306 . In this example, each sample comprises red, green, blue and alpha values, in addition to the sample&#39;s positional data. Block  310  illustrates the calculation of each pixel attribute value prior to normalization. As previously noted, the filter values may be summed to obtain a normalization value  308 . Normalization value  308  is used to divide out the unwanted gain arising from the non-constancy of the number of samples captured by the filter support. Block  312  illustrates the normalization process and the final normalized pixel attribute values. 
   The filter presented in  FIG. 12  has been chosen for descriptive purposes only and is not meant to be limiting. A wide variety of filters may be used for pixel value computations depending upon the desired filtering effect(s), e.g., filters such as a box filter, a tent filter, a cylinder filter, a cone filter, a Gaussian filter, a Catmull-Rom filter, a Mitchell-Netravali filter, or any windowed approximation of a sinc filter. It is a well known fact that the sinc filter realizes an ideal band-pass filter. However, the sinc filter takes non-zero values over the whole of the x-y plane. Thus, various windowed approximations of the sinc filter have been developed. Some of these approximations such as the cone filter or Gaussian filter approximate only the central lobe of the sinc filter, and thus, achieve a smoothing effect on the sampled image. Better approximations such as the Mitchell-Netravali filter (including the Catmull-Rom filter as a special case) are obtained by modeling the negative lobes which surround the central positive lobe of the sinc filter. The negative lobes allows a filter to more effectively retain spatial frequencies up to the cutoff frequency and reject spatial frequencies beyond the cutoff frequency. A negative lobe is a portion of a filter where the filter values are negative. Thus, some of the samples residing in the support of a filter may be assigned negative filter values (i.e. filter weights). In addition, the support of the filters used for the pixel value convolutions may be circular, elliptical, rectangular (e.g. square), triangular, hexagonal, etc. 
   The piecewise constant filter function shown in  FIG. 12  with four constant regions is not meant to be limiting. For example, in one embodiment the convolution filter may have a large number of regions each with an assigned filter value (which may be positive, negative or zero). In another embodiment, the convolution filter may be a continuous function that is evaluated for each sample based on the sample&#39;s distance (or x and y displacements) from the pixel center. Also note that floating point values may be used for increased precision. 
   As mentioned above (see  FIG. 2B  and attending description) graphics system  112  may comprise one or more graphics boards (also referred to herein as graphics pipe-lines) coupled together in a linear chain. Each graphics board GB(K) includes a number V K  of sample-to-pixel calculation units CU which form a linear succession. The union of all sample-to-pixel calculation units CU comprised within all graphics boards form a linear array. For example, in  FIG. 13 , the eight sample-to-pixel calculation units comprised within graphics board GB( 0 ) and GB( 1 ) form a linear array. The J th  sample-to-pixel calculation unit on graphics board GB(I) is denoted CU(I,J). As described above, the graphics boards contain components other than the sample-to-pixel calculation units. However, in  FIG. 13 , these other components have been suppressed for the sake of diagrammatical simplicity. 
   The linear array of sample-to-pixel calculation units generates one or more video signals for presentation to a collection of one or more display devices. For example, the linear array of sample-to-pixel calculation units may generate two video signals V A  and V B  for presentation to display devices  84 A and  84 B respectively. Each sample-to-pixel calculation unit CU(I,J) in the linear array may be assigned to either video stream A or video stream B. The sample-to-pixel calculation units assigned to a video stream are referred to as a video group. For example, in the example of  FIG. 13 , sample-to-pixel calculation units CU( 0 , 0 ) and CU( 0 , 1 ) belong to video group A, and sample-to-pixel calculation units CU( 0 , 2 ), CU( 0 , 3 ), CU( 1 , 0 ), CU( 1 , 1 ), CU( 1 , 2 ), CU( 1 , 3 ) belong to video group B. Such an assignment of resources may be appropriate when video signal V B  has a pixel bandwidth that is approximately three times larger than video signal V A . 
   Sample-to-pixel calculation units CU(I,J) in video group A generate pixel values for video signal V A . Similarly, sample-to-pixel calculation units CU(I,J) in video group B generate pixel values for video signal V B . The two video streams are independent in their resolution and timing because they are driven by independent pixel clocks. Each sample-to-pixel calculation unit CU(I,J) in the linear array is configured to receive both pixel clocks, and may be programmed to respond to either of the pixel clocks. 
   Sample-to-pixel calculation unit CU(I,J) generates video stream A I,J  and B I,J , and passes these video streams on to the next sample-to-pixel calculation unit on the same graphics board or the next graphics board. Video streams A I,J  may be interpreted as video stream A in varying stages of completion. Similarly, video streams B I,J  may be interpreted as video stream B in varying stages of completion. 
   The first sample-to-pixel calculation unit in a video group is referred to as the lead sample-to-pixel calculation unit. Second and subsequent sample-to-pixel calculation units in a video group are referred to herein as slave units. The sample-to-pixel calculation units in the video group cooperatively generate a video stream S (i.e. where S equals A or B). The video stream may originate inside the lead sample-to-pixel calculation unit as a stream of dummy pixels. The dummy pixels serve as timing place-holders, and may have a default color. Each sample-to-pixel calculation unit in the video group (including the lead unit) modifies the video stream, i.e. contributes locally generated image pixels to the video stream at appropriate times, and synchronously forwards the modified video stream to the next sample-to-pixel calculation unit in the video group. Each sample-to-pixel calculation unit in the video group receives a common pixel clock signal, and transmits a synchronous version of the pixel clock, embedded in the modified video stream, to the next sample-to-pixel calculation unit. Thus, the video signal S matures, in successive stages, from a signal comprising all dummy pixels to a signal comprising all (or mostly) image pixels as it passes through the sample-to-pixel calculation units of the video group. 
   Each sample-to-pixel calculation unit in the video group contributes its locally generated pixels to the video signal at times determined by a set of counters, boundary registers and boundary comparators internal to the sample-to-pixel calculation unit. The internal counters include a horizontal pixel counter and a vertical line counter. Each sample-to-pixel calculation unit (a) counts successive pixels and lines in the video stream in response to the synchronous pixel clock received in the video stream from the previous sample-to-pixel calculation unit, and (b) contributes locally generated pixels to the video stream when the local pixel count and line count reside within a predefined region as determined by the local boundary registers and boundary comparators. The regions assigned to the sample-to-pixel calculation units in the video group may be configured to tile a two-dimensional managed area. 
   In addition, the lead sample-to-pixel calculation unit (a) embeds a vertical reset pulse into the video stream when its local counters indicate the beginning of a frame, and (b) embeds a horizontal reset pulse into the video stream when its local counters indicate the beginning of a line. The reset pulses are treated like pixel data and passed from one sample-to-pixel calculation unit to the next with the video stream. Each slave unit may reset its horizontal pixel counter when it receives the horizontal reset pulse, and may reset both its horizontal pixel counter and its vertical line counter when it receives the vertical reset pulse. Thus, the lead unit controls video timing for the whole group. 
   A software program (e.g. a graphics application program) running on host CPU  102  may control a global managed area as shown in  FIG. 14A . Each video group is assigned a corresponding subregion of the global managed area. The subregion assigned to video group A is referred to as channel A, and the subregion assigned to video group B is referred to as channel B. The situation of channel A in the global managed area determines the video contents of video signal V A . Similarly, the situation of channel B in the global managed area determines the video contents of video signal V B . Often, channel A and channel B are chosen so that their union covers the global managed area. 
     FIG. 14B  illustrates an example where channel A and channel B intersect in the region denoted “A and B”. Thus, the region “A and B” appears on both display devices  84 A and  84 B. Regions of the global managed area outside the union of channel A and channel B are denoted “Not (A union B)”. These regions do not appear on either display device  84 A or  84 B. Generally, such regions represent wasted computational effort, and thus, are undesirable. 
     FIG. 14C  illustrates an example where channel B is entirely contained in channel A. Thus, display device  84 B displays a portion of the video image displayed by display device  84 A. 
   It is not required that a video channel be contained within the global managed area as suggested by  FIG. 14D . In this example, channel A extends outside the global managed area. The portion of channel A which lies inside the global managed area may be assigned image content. Portions of channel A which lie outside the global managed area (i.e. the left and right margins) are assigned dummy pixel values, e.g., pixel values having a predefined background color. This arrangement of channel A with respect to the global managed area illustrates one mechanism for performing “letter boxing”. 
   One or more software programs running on host computer  102  may set up two global managed areas as shown in  FIG. 14E . Typically, channel A is assigned so as to cover global managed area A, and channel B is assigned so as to cover global managed area B. The two global managed areas may contain independent video information. 
   To maximize the flexibility of the graphics system  112 , it is desirable to assign sample-to-pixel calculation units CU(I,J) to video group A or video group B on a persession basis, rather than fixing the allocation in hard wiring. To facilitate such dynamic allocation, both video stream A and video stream B flow through all the sample-to-pixel calculation units comprising the linear array. In this fashion, it is easy to derive the local video timing, i.e. the video timing for each sample-to-pixel calculation unit CU(I,J), from either video stream, and to assign a particular sample-to-pixel calculation unit CU(I,J) to either video stream. Each calculation unit may include a configuration register. The state of the configuration register may determine whether a calculation unit belongs to video group A or video group B. An external processor may write to the configuration registers to initialize or modify the allocation of calculation units to video groups. For example, a configuration routine executing on host CPU  102  may write to the configuration registers at system initialization time. In one embodiment, the configuration registers may be modified dynamically, i.e. during operational mode of the graphics system. For example, the configuration routine may write the configuration registers to update the allocation of calculation units to video groups in response to a user turning on a new video stream or turning off an existing video stream. 
     FIG. 15  illustrates one embodiment of a video router unit VR(I,J) in generic sample-to-pixel calculation unit CU(I,J). Video router unit VR(I,J) comprises a thru-video FIFO  502 , a thru-video FIFO  504 , a letterbox color unit  506  (also referred to herein as a pixel source unit), a video timing generator VTG(I,J), a local video FIFO  510 , a pixel integration unit  512  (also referred to herein as a blend unit), a readback FIFO  514 , and multiplexors  516 ,  518 ,  520 ,  522 ,  524 ,  526  and  530 . 
   Thru-video FIFO  502  stores the digital data presented in video stream A J−1 . Video stream A J−1  is transmitted from a previous sample-to-pixel calculation unit (situated in the same graphics board or a previous graphics board). Similarly, thru-video FIFO  504  stores the digital data presented in video stream B J−1 . Video stream B J−1  is transmitted from the previous sample-to-pixel calculation unit. Local video FIFO  510  temporarily stores the pixel values computed by earlier computational stages of sample-to-pixel calculation unit CU(I,J), e.g., the stages associated with steps  250 – 270  of  FIG. 11 . 
   The output of multiplexor  524  which comprises video stream A J  is transmitted to the next sample-to-pixel calculation unit (situated on the same graphics board or the next graphics board). The output of multiplexor  524  equals the output of blend unit  512  or the output of multiplexor  522 . 
   The output of multiplexor  526  which comprises video stream B J  is similarly transmitted to the next sample-to-pixel calculation unit. The output of multiplexor  526  equals the output of blend unit  512  or the output of multiplexor  522 . 
   Blend unit  512  is configured to mix (i.e. to blend or multiplex) the video output of multiplexor  520  and the locally generated pixels provided by local video FIFO  510 . The term mixing as used herein includes alpha blending and/or multiplexing. In the later case, blend unit  512  may be realized by a multiplexor which selects between the output of local video FIFO  510  and the output of multiplexor  520 . 
   Blend unit  512  is controlled by video timing generator VTG(I,J). The output of multiplexor  520  may equal the output of multiplexor  516  if the multiplexor  520  resides in a slave sample-to-pixel calculation unit, or, the output of letterbox color unit  506  if multiplexor  520  resides in a lead sample-to-pixel calculation unit of a video group. The output of multiplexor  516  may equal the output of thru-Video FIFO  502  or the output of thru-Video FIFO  504 . Thus, blend unit  512  may mix (or inject) locally computed pixel values into video stream A or video stream B in response to control signal(s) asserted by VTG(I,J). For the lead sample-to-pixel calculation unit in a video group, the blend unit  512  mixes (or injects) locally computed pixel values into the stream of dummy pixels originating from the letterbox unit  506 . The term “inject” as used herein refers to the selective multiplexing of locally computed pixels into a video stream, i.e. the replacement of selected dummy pixels in the video stream with the locally computed pixels. The dummy pixels serve as timing place holders in the video stream. Each sample-to-pixel calculation unit in a video group mixes or replaces a subset of the dummy pixels with corresponding locally computed image pixels. 
   The output of multiplexor  522  may equal the output of letterbox color unit  506  or the output of multiplexor  518 . The output of multiplexor  518  may equal the output of thru-Video FIFO  502  or the output of thru-Video FIFO  504 . 
   Local video FIFO  510  stores pixel values (e.g. red, green, blue and alpha values) provided on input bus  509  by previous computational stages of sample-to-pixel calculation unit CU(I,J). 
   Video router VR(I,J) includes a vertical counter and a horizontal counter. In the preferred embodiment, these counters may be conveniently located inside video timing generator VTG(I,J). However, in an alternative embodiment, these counters may be located outside the video timing generator. Video router VR(I,J) may contain a second pair of counters which regenerate the values of the first set of counters at a second locality in the video router. 
   Video timing generator VTG(I,J) provides all timing and control signals necessary to support video routing in sample-to-pixel calculation unit CU(I,J). It may be programmed via the MCv-bus. 
   All the video timing generators VTG(I,J) for the sample-to-pixel calculation units CU(I,J) in a video group run in synchrony with one another. This is accomplished by programming them to respond to the same clock, and resetting their horizontal counters and vertical counters upon receipt of a horizontal reset pulse and vertical reset pulse respectively. For maximum flexibility in meeting video sync specifications, the horizontal sync (Hsync), vertical sync (Vsync) and Blank signals presented to DACs  178 A and  178 B (see  FIG. 3 ) are not the same as the horizontal reset (Hreset) signal and vertical reset (Vreset) signal which flow from one sample-to-pixel calculation unit to the next to accomplish the synchronization of the video timing generators. This allows the zero point of horizontal and vertical timing to be chosen independently of the placement of sync and blank edges in the video signal presented to external devices. 
   The blend units within the video routers of a video group do not alter the timing of the video stream which is established by the video timing generator in the lead calculation unit. Each blend unit waits until the current pixel position falls within a given column of the managed area, and initiates multiplexing or blending of locally computed image pixels into the received video stream. Thus, pixels in the received stream may be modified or replaced by the locally-computed image pixels. 
     FIG. 16  shows a more detailed embodiment of video router unit VR(I,J) in generic sample-to-pixel calculation unit CU(I,J).  FIG. 16  shows that video router VR(I,J) may further comprise: 
   color field-sequential multiplexor  528  (at the output of local video FIFO  510 ); 
   drawing synchronizer  532 ; 
   cursor generator  534  (which feeds local video FIFO  510 ); 
   one or more bus interfaces  536 ; 
   multiplexor  540  (which receives Hreset — A and Vreset — A inputs from thru-video FIFO  502 , and Hreset — B and Vreset — B inputs from thru-video FIFO  504 ); 
   frame detector  541 ; 
   multiplexor  542  (which couples to the outputs of multiplexor  540 , frame detector  541  and gate  556 ); 
   buffers  544  and  546 ; 
   multiplexor  548  at the output of the buffers; 
   flip-flops  550 ,  552 ,  554 ; and 
   and gate  556 . 
   Assigning sample-to-pixel calculation unit CU(I,J) to a video group implies that its video timing generator VTG(I,J) uses the pixel clock, horizontal reset and vertical reset signals of corresponding video stream. For example, if sample-to-pixel calculation unit CU(I,J) has been assigned to video group A, then video timing generator VTG(I,J) drives A/B selection signal  557  to a first state which indicates that video stream A is chosen. Thus, multiplexor  540  selects the horizontal reset (Hreset) and vertical reset (Vreset) from video stream A instead of video stream B. Also, multiplexor  548  selects pixel clock A instead of pixel clock B. 
     FIG. 17  shows an embodiment of a graphics board denoted GB-VI having six sample-to-pixel calculation units CU( 0 ) through CU( 5 ), genlocking pixel clocks  180 A and  180 B, and DACs  178 A and  178 B. Genlocking pixel clock  180 A provides a pixel clock signal A to each of sample-to-pixel calculation units CU( 0 ) through CU( 5 ). Similarly, genlocking pixel clock  180 B provides a pixel clock signal B to each of sample-to-pixel calculation units CU( 0 ) through CU( 5 ). 
     FIG. 18  illustrates one embodiment of a graphics board denoted GB×4 which may be configured to generate up to four simultaneous video streams. Graphics board GB×4 may comprise N sample-to-pixel calculation units denoted CU( 0 ) through CU(N- 1 ), digital-to-analog converters  178 A–D, and genlocking pixel clocks  180 A–D. 
   Sample-to-pixel calculation unit CU( 0 ) may be configured to receive video streams W K−1 , X K−1 , Y K−1  and Z K−1  from a previous graphics board GB(K− 1 ). Each of sample-to-pixel calculation units CU( 0 ) through CU(N- 1 ) may be programmed to contribute its locally generated image pixels to one of the four video streams. Last sample-to-pixel calculation unit CU(N- 1 ) passes the modified video streams W K , X K , Y K  and Z K  to the next graphics board and/or to DACs  178 . 
   As described in the various embodiments above, the sample-to-pixel calculation units CU comprised within the graphics boards of graphic system  112  form a linear array. In addition, the sample-to-pixel calculation units in a video group comprise a chain. The sample-to-pixel calculation unit at the head of the chain is the leader of the video timing for the chain. All other sample-to-pixel calculation units in the chain (i.e. in the video group) synchronize themselves to the timing of the lead sample-to-pixel calculation unit (using synchronous horizontal and vertical resets), and thus, are referred to as slave units. For example, in  FIG. 13  sample-to-pixel calculation unit CU( 0 , 0 ) is the head of the A chain, and sample-to-pixel calculation unit CU( 0 , 2 ) is the head of the B chain. 
   Video router VR(I,J) may be programmed to operate in leader mode or in slave mode. A software configuration routine may program each of the video routers in the linear chain with their corresponding group assignment and lead/slave mode assignment. 
   In one alternative embodiment, specialized lead routers and slave routers are contemplated. Lead routers may be implemented without the thru-video FIFOs, and slave routers may be implemented without the letterbox color unit. 
   Video router VR(I,J) in sample-to-pixel calculation unit CU(I,J) is the basic building block of a scalable video architecture. The horizontal counters and vertical counters in the video timing generators VTG(I,J) of video group A may cover the extent of channel A as shown in any of  FIGS. 14A–E . The horizontal counters and vertical counters in the video timing generators VTG(I,J) of video group B may cover the extent of channel B as shown in any of  FIGS. 14A–D . The horizontal and vertical size in pixel dimensions of channel X may be programmed into each sample-to-pixel calculation unit of video group X at system initialization time, where X equals A or B. 
   Each sample-to-pixel calculation unit CU(I,J) of video group A is assigned a corresponding column of channel A, and each sample-to-pixel calculation unit CU(I,J) of video group B is assigned a corresponding column of channel B. Sample-to-pixel calculation unit CU(I,J) generates pixel values for its assigned column. Thus, video router VR(I,J) in sample-to-pixel calculation unit CU(I,J) contains boundary registers which define the left, right, top and bottom boundary values for the assigned column. The horizontal pixel count generated by the horizontal counter is compared to the left and right boundary values of the assigned column, and the vertical line count generated by the vertical counter is compared to the top and bottom boundary values of the assigned column. 
   When (a) the horizontal pixel count is between the left and right column boundaries, and (b) the vertical line count is between the top and bottom column boundaries, video router VR(I,J) of sample-to-pixel calculation unit CU(I,J) will route pixels from the local video FIFO  510  to blend unit  512 , and blend unit  512  will mix the locally computed pixels with corresponding pixels (typically dummy pixels) presented in video stream S, where S equals A or B depending on the video group assignment of the video router. As used herein the term “mix” is intended to include alpha blending and pixel replacement. Thus, blend unit  512  may replace dummy pixels in video stream S with locally generated pixels when (a) and (b) are true. Additionally, video router VR(I,J) may sense whether or not the current field is the correct field of a video frame. 
   In the preferred embodiment, each sample-to-pixel calculation unit CU(I,J) includes boundary checking circuitry comprising one or more comparators. The boundary checking circuitry compares the horizontal pixel count CH to the left column boundary N left  and right column boundary N right , and the vertical line count C V  to the top column boundary N top  and bottom column boundary N bottom . Sample-to-pixel calculation unit CU(I,J) may be configured to declare the current pixel as interior to the assigned column when its horizontal pixel count C H  and vertical line count C V  obey the constraints
 
N left ≦C H &lt;N right , and
 
N top ≦C V &lt;N bottom .
 
Because each sample-to-pixel calculation unit applies boundary checking in this fashion, with strict and permissive inequalities at opposing boundaries of the corresponding column, it is easy to configure the sample-to-pixel calculation units of a video group to tile (i.e. to completely cover without overlapping) a desired region of the managed area. For example, two columns which meet side by side without an intervening gap may be configured by writing the left and right boundary registers of a first video router with the values A and B respectively, and the writing the left and right boundary registers of the next video router with the values B and C respectively. If strict (or permissive inequalities) were used for both horizontal boundaries (or both vertical boundaries) the process of initializing the boundary registers would be more complicated.
 
   Of course, it is not necessary that the strict inequality be used for the right and bottom boundaries as long as all the sample-to-pixel calculation units apply a consistent system of inequalities with the strict and permissive inequalities at opposing boundaries in each direction. Thus, any of the three following systems would equally suffice:
 
N left &lt;C H &lt;I right ,
 
N top &lt;C V ≦N bottom ;  (1)
 
N left &lt;C H ≦I right ,
 
N top ≦C V &lt;N bottom ;  (2)
 
N left &lt;C H ≦I right ,
 
N top &lt;C V &lt;N bottom .  (3)
 
The horizontal and vertical counts are said to “reside within” or “fall within” the assigned column for a given sample-to-pixel calculation unit (and its associated video timing generator) when the horizontal and vertical counts obey the corresponding local set of inequalities. The horizontal and vertical counts are said to “reside outside” or “fall outside” the assigned column when any of the inequalities (left, right, top or bottom) of the local set fails to be satisfied. Furthermore, the horizontal count is said to “fall between”, “fall within”, or “reside within” the left and right column boundaries when the left and right inequalities of the local set are satisfied. Likewise, the vertical count is said to “fall between”, “fall within”, or “reside within” the top and bottom column boundaries when the top and bottom inequalities of the local set are satisfied. The term “vertical count” may be equivalently referred to as the vertical pixel count or the vertical line count.
 
   The columns assigned to the sample-to-pixel calculation units CU(I,J) of video group A may tile channel A vertically and/or horizontally. Similarly, the columns assigned to the sample-to-pixel calculation units CU(I,J) of video group B may tile channel B vertically and/or horizontally. In one alternative embodiment, two or more of the columns assigned to the sample-to-pixel calculation units of a video group may overlap partially or completely. Thus, it is possible for a downstream calculation unit to mix its locally computed image pixels with pixel images contributed by one or more upstream calculations units. 
   Graphics board GB(K) may be able to synchronize its video timing to a wide variety of external video timing formats. To attain such flexibility has been expensive in the past, and most computer graphics systems have not attempted it at all, or have simply provided an asynchronous frame-reset feature. The asynchronous frame reset may be sufficient for some applications, but it fails to adequately address the requirements of many emerging application areas such as virtual reality, multimedia authoring, many simulation applications, and video post-production. True line-rate genlock may be a requirement for these markets. Thus, graphics system  112  may, in some embodiments, provide improved performance relative to prior art graphics systems in these application areas. Furthermore, there are many applications which are not seen as traditional genlock applications, where, nevertheless, genlock capability is quite beneficial. 
   In video post-production, graphics system  112  synchronizes to one or more video sources in a production facility. A user-specified horizontal phase offset during genlock may be required for this application. 
   As described above in connection with  FIG. 13 , the sample-to-pixel calculation units CU(I,J) of video group A contribute pixel values to video stream A. The sample-to-pixel calculation units of video group B pass video stream A without modification, i.e. without modification of pixel values contained in video stream A. Thus, video stream A is routed digitally through the linear array, i.e. from first sample-to-pixel calculation unit CU( 0 , 0 ) in the first graphics board GB( 0 ) through the last sample-to-pixel calculation unit CU(R- 1 , V- 1 ) in the last graphics board GB(R- 1 ). Video stream B is routed digitally through the sample-to-pixel calculation units CU(I,J) comprising video group B. 
   For example, in  FIG. 13 , video stream A is routed from sample-to-pixel calculation unit CU( 0 , 0 ) through sample-to-pixel calculation unit CU( 1 , 3 ), and video stream B is routed from sample-to-pixel calculation unit CU( 0 , 2 ) through sample-to-pixel calculation unit CU( 1 , 3 ). The video timing generator VTG( 0 , 0 ) in sample-to-pixel calculation unit CU( 0 , 0 ) is the lead video timing generator for video stream A. The video timing generator VTG( 0 , 2 ) in sample-to-pixel calculation unit CU( 0 , 2 ) is the lead VTG for video stream B. 
   Typical scanlines L A  and L B  for channel A and channel B respectively are shown in  FIG. 19 . Sample-to-pixel calculation unit CU( 0 , 0 ) generates video stream A 0,0  as shown in  FIG. 13 . Pixels computed by sample-to-pixel calculation unit CU( 0 , 0 ) are mixed (or injected) into video stream A 0,0  when the horizontal count and vertical count of video router VR( 0 , 0 ) reside within the boundaries of column ( 0 , 0 ) which may comprise a rectangular area of pixels. When the horizontal or vertical counts of video router VR( 0 , 0 ) reside outside of column ( 0 , 0 ), video router VR( 0 , 0 ) transmits dummy pixel values from its letterbox color unit  506  into video stream A 0,0 . Video router VR( 0 , 0 ), because it is the lead video router for video group A, embeds:
         (1) a horizontal reset pulse into video stream A 0,0  when its horizontal pixel counter corresponds to the left boundary of Channel A as exemplified by point  604 ; and   (2) a vertical reset pulse into video stream A 0,0  when its vertical line counter and horizontal pixel counter correspond to the top left corner  602  of video channel A.
 
Furthermore, video router VR( 0 , 0 ) transmits words out of local video FIFO  510  and letterbox color unit  506  using pixel clock signal A generated by genlocking pixel clock  180 A. Video router VR( 0 , 0 ) may embed a synchronous copy of pixel clock signal A along with the data words into video stream A 0,0 . (See  FIG. 25 ).
       

   Video router VR( 0 , 1 ) in the next sample-to-pixel calculation unit CU( 0 , 1 ) uses the embedded clock signal to clock video stream A 0,0  into its thru-video FIFO  502 . Because the embedded clock signal travels along with the data in video stream A 0,0 , the setup and hold relationships between clock and data signals are preserved unlike systems which clock all FIFOs with a clock distributed from a central source. 
   Video router VR( 0 , 1 ) uses pixel clock signal A distributed from pixel clock  180 A to clock data out of its thru-video FIFO  502 . Because the embedded clock signal (in the received video stream) and the centrally distributed clock signal A have the same frequency, and because thru-video FIFO  502  is written on every clock and read on every clock, thru-video FIFO  502  never overflows or underflows. Thus, the flow of video data through the video routers is insensitive to the delays induced by the buffers in the chain. 
   Video router VR( 0 , 1 ) may use the centrally distributed pixel clock signal A to drive its horizontal counter. Video router VR( 0 , 1 ) may use the vertical reset pulse and horizontal reset pulse from video stream A 0,0  (as they emerge from thru-video FIFO  502 ) to reset its vertical counter and horizontal counter respectively. The vertical counter in video router VR( 0 , 1 ) may increment once per horizontal scan line of channel A. In one embodiment, the vertical counter may increment in response to the horizontal reset. In another embodiment, the vertical counter may increment in response to the horizontal count value attaining a maximum value which corresponds to the right boundary of channel A. 
   When the horizontal and vertical counts of video router VR( 0 , 1 ) reside within Column ( 0 , 1 ) of channel A as shown in  FIG. 19 , video router VR( 0 , 1 ) clocks locally computed pixel values out of its local video FIFO  510 , and mixes (or injects) the locally computed pixel values into the stream of dummy pixel values emerging from thru-video FIFO  502 . The mixing is performed in blend unit  512 . Blend unit  512  may use alpha values provided by the local pixel stream or alpha values provided in the thru-video pixel stream depending on a local/thru selection signal provided by video timing generator VTG( 0 , 1 ). The mixed output of blend unit  512  comprises the output video stream A 0,1 . 
   When the horizontal or vertical counts of video router VR( 0 , 1 ) reside outside of Column ( 0 , 1 ) of channel A, video timing generator VTG( 0 , 1 ) commands the local blend unit  512  to pass the video stream emerging from thru-video FIFO  502  to the channel A output unmodified. In other words, the output of thru-video FIFO  502  is transmitted as output video stream A 0,1 . 
   Because sample-to-pixel calculation unit CU( 0 , 1 ) is the last sample-to-pixel calculation unit in video group A, the pixel values comprised in video stream A 0,1  pass unmodified through sample-to-pixel calculation units CU( 0 , 2 ) through CU( 1 , 3 ). Sample-to-pixel calculation unit CU( 1 , 3 ) in graphics board GB( 1 ) may provide the completed video stream A to display device  84 A (perhaps through a D/A converter). Since video stream A is complete at the output of sample-to-pixel calculation unit CU( 0 , 1 ), sample-to-pixel calculation unit CU( 0 , 3 ), which is the last sample-to-pixel calculation unit in graphics board GB( 0 ), may present the completed video stream A to display device  84 A. In other words, a video stream may be “harvested” from the first graphics board in which it has reached a completed state. 
   Sample-to-pixel calculation unit CU( 0 , 2 ) generates video stream B 0,2  as shown in  FIG. 13 . Pixels computed by sample-to-pixel calculation unit CU( 0 , 2 ) are mixed (or injected) into video stream B 0,2  when the horizontal and vertical counts of video router VR( 0 , 2 ) reside within the boundaries of Column ( 0 , 2 ) of channel B as shown in  FIG. 19 . When the horizontal or vertical counts of video router VR( 0 , 2 ) reside outside of column ( 0 , 2 ), video router VR( 0 , 2 ) transmits dummy pixel values from its letterbox color unit  506  into video stream B 0,2 . Video router VR( 0 , 2 ), because it is the lead video router of video group B, embeds:
         (1) a horizontal reset pulse into video stream B 0,2  when its horizontal pixel counter corresponds to the left boundary of Channel B as exemplified by point  612 ; and   (2) a vertical reset pulse into video stream B 0,2  when its vertical line counter and horizontal pixel counter correspond to the top left corner  610  of video channel B.
 
Furthermore, video router VR( 0 , 2 ) transmits words out of its local video FIFO  510  and letterbox color unit  506  using pixel clock signal B generated by genlocking pixel clock  180 B. Video router VR( 0 , 2 ) may embed a synchronous copy of pixel clock signal B along with the data words into video stream B 0,2 . Video router VR( 0 , 3 ) in the next sample-to-pixel calculation unit CU( 0 , 3 ) uses the embedded clock signal to clock video stream B 0,2  into its thru-video FIFO  504 .
       

   Video router VR( 0 , 3 ) uses pixel clock signal B distributed from pixel clock  180 B to clock data out of the thru-video FIFO  504 . Because the embedded clock signal (received with the video stream B 0,2 ) and the centrally distributed clock signal B have the same frequency, and because thru-video FIFO  504  is written on every clock and read on every clock, thru-video FIFO  504  never overflows or underflows. Thus, the flow of video data through the video routers of video group B is insensitive to the delays induced by the thru-video FIFOs. 
   Video router VR( 0 , 3 ) uses the centrally distributed pixel clock signal B to drive its horizontal counter. The vertical counter in video router VR( 0 , 3 ) may increment once per horizontal scan line of channel B. In one embodiment, the vertical counter may increment in response to the horizontal reset received from thru-video FIFO  504 . In another embodiment, the vertical counter may increment in response to the horizontal count value attaining a maximum value which corresponds to the right boundary of channel B. Also, video router VR( 0 , 3 ) uses the vertical reset pulse and horizontal reset pulse from video stream B 0,2  as they emerge from thru-video FIFO  504  to reset its vertical counter and horizontal counter respectively. 
   When the horizontal and vertical counts of video router VR( 0 , 3 ) reside within Column ( 0 , 3 ) of channel B, video router VR( 0 , 3 ) clocks locally computed pixel values out of its local video FIFO  510 , and mixes (or injects) the locally computed pixel values into the stream of pixel values emerging from its thru-video FIFO  504 . The mixing is performed in blend unit  512 . The blend unit  512  may use alpha values provided by the local pixel stream or alpha value provided by the thru-video pixel stream depending on a local/thru selection signal provided by video timing generator VTG( 0 , 3 ). The mixed output of blend unit  512  is transmitted as the output video stream B 0,3 . 
   When the horizontal or vertical counts of video router VR( 0 , 3 ) reside outside of Column ( 0 , 3 ) of channel B, video timing generator VTG( 0 , 3 ) commands the local blend unit  512  to pass the video stream emerging from thru-video FIFO  502  to the channel B output unmodified. Thus, the output of thru-video FIFO  504  becomes the output video stream B 0,3 . 
   Each slave sample-to-pixel calculation unit CU(I,J) in video group B mixes (or injects) locally computed pixels into video stream B when its horizontal and vertical counter values reside within the corresponding column (I,J) of channel B. When its horizontal or vertical counter values reside outside the corresponding column (I,J), sample-to-pixel calculation unit CU(I,J) passes video stream B unmodified from its thru-video FIFO  504  to the next sample-to-pixel calculation unit in video stream B I,J . 
   In general, each sample-to-pixel calculation unit CU(I,J) in a video group mixes (or injects) locally computed pixels into the corresponding video stream when its local horizontal and vertical count values reside in the corresponding column (I,J). Each slave sample-to-pixel calculation unit in a video group passes the corresponding video stream unmodified to its output when its local horizontal and vertical count values reside outside the corresponding column (I,J). The lead sample-to-pixel calculation unit in a video group sources dummy pixels (i.e. timing “place-holder” pixels) when it is not sourcing locally generated pixels from its local video FIFO  510 , i.e. when its local horizontal or vertical count values reside outside the corresponding column (I,J). These dummy pixels may be replaced by one of the slave sample-to-pixel calculation units CU(I,J) of the same video group before the video stream is finally displayed, after having passed through the final sample-to-pixel calculation unit in the linear array. Note that “letterboxing” occurs in those regions for which none of the sample-to-pixel calculation units contribute pixels. This is suggested in  FIG. 14D . In order to have well-defined colors in letterboxed areas, the lead sample-to-pixel calculation unit (at the head of each video chain) may send out its dummy pixels from a programmable RGB register in letterbox color unit  506  instead of from a thru-Video FIFO. 
   As noted above, the video router VR(I,J) contains a vertical counter. The vertical counter is compared with vertical limit registers (also referred to herein as vertical boundary registers) indicating the vertical extent of the assigned column (I,J). This is useful in multi-board collaborative video applications, where it is desirable to tile a single screen (i.e. channel) vertically as well as horizontally with the video output from multiple graphics boards GB(I). 
     FIG. 20  shows an example of multi-board collaboration where all six graphics boards GB( 0 ) through GB( 5 ) are assigned to video channel A, and none are assigned to channel B. Video stream A is daisy-chained digitally from graphics board GB( 0 ) through GB( 5 ), and displayed through display device  84 A. Because the video timing generators VTG(I,J) in the sample-to-pixel calculation units CU(I,J) perform vertical bounds checking as well as horizontal bounds checking as described above, the graphics boards GB(I) contribute their locally computed pixel values to video stream A in an orderly fashion. 
     FIG. 21  shows one possible mapping of regions to the graphics boards of  FIG. 20 . Regions R 0 –R 5  of channel A are assigned respectively to graphics boards GB( 0 ) through GB( 5 ). Region RI is assigned to graphics board GB(I). Each sample-to-pixel calculation unit CU(I,J) in graphics board GB(I) operates on a column (I,J) within region RI. Four representative scan lines are illustrated and labeled  620 ,  622 ,  624  and  626  respectively. 
     FIG. 22A  illustrates the contribution of pixels to video stream A by graphics boards GB( 0 ), GB( 1 ) and GB( 2 ) for scan line  620 . Graphics board GB( 0 ) contributes pixels to video stream X 0  during scan line  620 , i.e. image pixels corresponding to region R 0  during a first time segment and dummy pixels thereafter. Graphics board GB( 1 ) receives video stream X 0 , and mixes (or replaces) some of the dummy pixels in video stream X 0  with image pixels corresponding to region R 1 , thus generating video stream X 1 . Graphics board GB( 2 ) receives video stream X 1  and mixes (or replaces) dummy pixels in video stream X 1  with image pixels corresponding to region R 2 , thus generating video stream X 2 . The pixel values comprising video stream X 2  pass through graphics boards GB( 3 ), GB( 4 ) and GB( 5 ) without modification, and are displayed by display device  84 A. 
     FIG. 22B  illustrates the contribution of pixels to video stream A by graphics boards GB( 0 ), GB( 1 ), GB( 2 ) and GB( 3 ) for scan line  622 . Graphics board GB( 0 ) generates video stream X 0  with only dummy pixels because region R 0  never intersects scan line  622 . Graphics board GB( 1 ) receives video stream X 0  and mixes (or replaces) a middle segment of the dummy pixels, corresponding to region R 1 , with locally computed pixels corresponding to region R 1  as shown in video stream X 1 . Graphics board GB( 2 ) receives video stream X 1  and mixes (or replaces) a last segment of dummy pixels, corresponding to region R 2 , with locally computed pixels corresponding to region R 2  as shown in video stream X 2 . Graphics board GB( 3 ) receives the video stream X 2  and mixes (or replaces) a first segment of dummy pixels, corresponding to region R 3 , with locally computed pixels corresponding to region R 3  as shown in video stream X 3 . Video stream X 3  passes through graphics boards GB( 4 ) and GB( 5 ) without modification because regions R 5  and R 5  do not intersect scan line  622 . 
     FIG. 22C  illustrates the contribution of pixels to video stream A by graphics boards GB( 0 ), GB( 1 ), GB( 3 ) and GB( 5 ) for scan line  624 . Graphics board GB( 0 ) generates video stream X 0  with only dummy pixels because region R 0  never intersects scan line  624 . Graphics board GB( 1 ) receives video stream X 0  and mixes (or replaces) a middle segment of the dummy pixels, corresponding to region R 1 , with locally computed pixels corresponding to region R 1  as shown in video stream X 1 . Graphics board GB( 2 ) receives video stream X 1  and passes it unmodified to graphics board GB( 3 ) in video stream X 2  because region R 2  does not intersect scan line  624 . Graphics board GB( 3 ) receives video stream X 2  and mixes (or replaces) a first segment of the dummy pixels, corresponding to region R 3 , with locally computed pixels corresponding to region R 3  as shown in video stream X 3 . Graphics board GB( 4 ) receives video stream X 3  and passes it unmodified to graphics board GB( 5 ) in video stream X 4  because region R 4  does not intersect scan line  624 . Graphics board GB( 5 ) receives video stream X 4  and mixes (or replaces) a last segment of dummy pixels, corresponding to region R 5 , with locally computed pixels corresponding to region R 5  as shown in video stream X 5 . Video stream X 5  is presented to DAC  178 A for transmission to display device  84 A. 
   For scan line  626 , graphics board GB( 0 ) generates video stream X 0  comprising dummy pixels. Graphics boards GB( 1 ) and GB( 2 ) pass the pixels of video stream X 0  unmodified because regions R 1  and R 2  do not intersect scan line  626 . Graphics boards GB( 3 ), GB( 4 ) and GB( 5 ) mix (or replace) corresponding segments of the dummy pixels with their locally computed dummy pixels. 
   As shown in  FIGS. 15 and 16 , video router VR(I,J) in sample-to-pixel calculation unit CU(I,J) includes a blend unit  512 , a first set of multiplexors (i.e. multiplexors  516 ,  518 ,  520  and  522 ), and a second set of multiplexors (i.e. multiplexors  524  and  526 ). These components support a very flexible video environment for video signal generation.  FIGS. 23A–B  and  FIGS. 24A–B  illustrate various ways video can be made to flow through video router VR(I,J). Video router VR(I,J) comprises an upper pathway and lower pathway. Blend unit  512  resides on the upper pathway. The first set of multiplexors allow video streams to exchange pathways prior to blending. Thus, either input video stream may experience blending. The second set of multiplexors allow video streams to exchange pathways after blending. Thus, the blended stream may be presented at either the upper or lower output port. The terms upper and lower are used for convenience of discussion. 
   In  FIG. 23A , video stream A is presented to thru-video FIFO  502  and video stream B is presented to thru-video FIFO  504 . Video streams A and B exchange (upper and lower) pathway position through the first set of multiplexors. Thus, video stream B gets sent to blend unit  512 . Blend unit  512  optionally (a) passes the video stream B through to its output, (b) mixes (i.e. blends) the video stream B with local pixel data from local video FIFO  510 , or (c) replaces pixels from video stream B with local pixels data from local video FIFO  510 . It is noted that (c) may be considered a subset of (b) because replacement is equivalent to mixing with alpha equal to zero. As shown, the optionally modified video stream B generated by blend unit  512  and the unmodified video stream A may be presented to the upper and lower output ports respectively. 
   The second set of multiplexors (i.e. multiplexors  524  and  526 ) allow the optionally modified video stream B (generated by blend unit  512 ) and unmodified video stream A to exchange up/down pathway position, and thus, to be presented to the lower and upper output ports respectively. The flexibility of being able to present the video streams at either output port implies that a user may connect cables to display device  84 A and  84 B in an arbitrary fashion. 
   In  FIG. 24A , video stream A is presented to thru-video FIFO  502 , and video stream B is presented to thru-video FIFO  504 . The first set of multiplexors  516  and  518  pass the video streams without positional exchange. Thus, video stream A gets sent to blend unit  512 , and optionally mixed with local pixel data. The second set of multiplexors  524  and  526  pass the optionally modified stream A and unmodified stream B to the upper and lower output ports respectively. Alternatively, the second set of multiplexors  524  and  526  may perform a positional exchange so that the optionally modified stream A is presented at the lower output port and the unmodified stream B is presented to the upper output port as shown in  FIG. 24B . 
   In one embodiment, the video router may be configured to support the generation of L video streams, where L is any desired positive integer value. The structure of such a video router may described in terms of a series of modifications of the video router of  FIG. 15  as follows.
         (A) The 2-to-2 crossbar switch comprised by multiplexors  516  and  518  may be replaced by a crossbar switch with L inputs and L outputs. The L inputs may couple to the output ports of L corresponding thru-video FIFOs. This crossbar switch may be referred to as the pre-blend crossbar switch.   (B) In one embodiment, the two multiplexors  520  and  522  may be replaced by a system of L multiplexors. Each of the L multiplexors may have two inputs. The first input of each of the L multiplexors may couple to a corresponding output of the pre-blend crossbar switch. The second input of each of the L multiplexors may couple to the letterbox unit  506 . The topmost of the L multiplexors may send its output to the blend unit  512 . The remaining (L- 1 ) multiplexors may send their outputs to a “post-blend” crossbar switch to be described below. In another embodiment, the two multiplexors  520  and  522  may be replaced by a single multiplexor. The first input of the single multiplexor may couple to the topmost output of the pre-blend crossbar switch. The second input of the single multiplexor may couple to the letter box color unit. The output of the single multiplexor may couple to the blend unit  512 .   (C) The 2-to-2 crossbar switch comprised by multiplexors  524  and  526  may be replaced by another L-to-L crossbar switch. This crossbar switch may be referred to as the post-blend crossbar switch. The topmost input of the post-blend crossbar switch may couple to the output of the blend unit  512 . In the first embodiment of (B) above, the (L- 1 ) remaining inputs of the post-blend crossbar switch may couple respectively to the outputs of the (L- 1 ) multiplexors below the topmost multiplexor. In the second embodiment of (B) above, the (L- 1 ) remaining inputs of the post-blend crossbar switch may couple respectively to the (L- 1 ) remaining outputs of the pre-blend crossbar switch.       

   The pre-blend crossbar switch, the system of one or more multiplexors, and the post-blend crossbar switch allow the video router to flexibly route up to L simultaneous video streams. The pre-blend crossbar switch allows the video router to switch its topmost input (received from the topmost thru-video FIFO) to any one of its lower outputs (i.e. outputs other than the topmost output). Thus, a lead video router in a given video group may send a “completed” video stream from a previous video group from the topmost thru-video FIFO to one of its lower output paths. This action effectively “saves” the completed video stream since video streams in the lower output paths do not interact with the blend unit, and thus, remain stable until they are output to a DAC or display device. 
   It is noted that a completed video stream may also be transmitted to system memory  106  through the readback FIFO  514 . Thus, video streams may be stored in system memory as they are being displayed on display devices. The time-lag between display and capture of video frames in system memory may be substantially reduced or eliminated. 
   The system of one or more multiplexors allows the video router to send the stream of dummy pixels from the letterbox unit  506  to the upper output path to experience the mixing operation of blend unit  512 . This occurs when the video router is the lead video router of a video group. 
   The post-blend crossbar switch allows the video router to permute the order of the output video streams after the blend unit  512 . Thus, any of the video streams may appear at any output. This may be particular useful at the final output stage where the completed video streams are presented to display devices. 
   Digital video streams A and B may be passed from one sample-to-pixel calculation unit to the next using source-synchronous signaling. In other words, a pixel clock is sent along with the data from one video router to the next, so that the setup-hold relationships between data and clock are maintained as the signals propagate. All signals are received with first-in first-out buffers (i.e. thru-video FIFOs  502  and  504 ) whose inputs are clocked using the source-synchronous clock which came with the data, and whose outputs are clocked with a version of the clock which is supplied in parallel to all sample-to-pixel calculation units CU(I,J) (i.e. one clock per video group). See  FIG. 17 . 
   Several benefits are derived from source-synchronous clocking. First, input and output from the thru-video FIFOs  502 / 504  are insensitive to clock-skew, tolerating a full 360 degree phase shift between input and output clocks. Second, board-level lock distribution of a parallel clock (e.g. pixel clock A or B) to all sample-to-pixel calculation units CU(I,J) need not be phase-matched, i.e., propagation delays may be unmatched. Third, all clocking is point-to-point and unidirectional. Thus, termination is simplified and high-speed operation is assured. Fourth, the clock distribution method is insensitive to buffer delays. Thus, point-of-use clock phase locked loops (PLLs) are not needed. 
   Video router VR(I,J) in sample-to-pixel calculation unit CU(I,J) receives video stream A from a previous sample-to-pixel calculation unit. Video stream A comprises data signals denoted Data — In — A, and an embedded version of pixel clock A denoted Clk — In — A as shown in  FIG. 25 . The clock signal Clk — In — A is used to clock data signals Data — In — A into thru-video FIFO  502 . 
   Similarly, video stream B comprises data signals denoted Data — In — B, and an embedded version of pixel clock B denoted Clk — In — B. The clock signal Clk — In — B is used to clock data signals Data — In — B into thru-video FIFO  504 . 
   The embodiment of video router VR(I,J) shown in  FIG. 25  does not include blend unit  512 . Instead multiplexor  560  is used to selectively transmit pixels from either thru-video FIFO  502  or local video FIFO  510 . Similarly, multiplexor  562  is used to selectively transmit pixels from either thru-video FIFO  504  or local video FIFO  510 . However, the embodiment of  FIG. 25  may be modified to use a blend unit in place of multiplexors  560  and  562 . 
   Video router VR(I,J) receives pixel clock signals A and B (denoted PixClk — A and PixClk — B in the figure) which originate from genlocking pixel clocks  180 A and  180 B respectively. The pixel clock signals are provided to a 2-to-2 crossbar switch  501 . A first output of the crossbar switch drives thru-video FIFO  502  and a corresponding output unit  561 . The second output of the crossbar switch drives thru-video FIFO  504  and a corresponding output unit  563 . The crossbar switch  501  allows either pixel clock to drive either data path. A multiplexor  564  receives the two clock outputs from the crossbar switch  501 . The output of multiplexor  564 , denoted Oclk, is presented to the video timing generator and local video FIFO  510 . Multiplexor  564  selects one of the two pixel clock signals based on the video group assignment of the video router. The signal Oclk is used to clock data out of local video FIFO  510 . 
   Multiplexor  560  couples to thru-video FIFO  502  and local video FIFO  510 , and multiplexes the data streams received from these two sources into a single data stream in response to a selection signal controlled by the video timing generator. Output unit  561  receives and transmits the single data stream denoted Data — Out — A in response to one of the pixel clock signals. Observe that the output unit  561  transmits a synchronous version of the clock signal which is used to transmit data stream Data — Out — A. This synchronous clock is denoted Clk — Out — A. 
   Multiplexor  562  couples to thru-video FIFO  504  and local video FIFO  510 , and multiplexes the data streams received from these two sources into a single data stream in response to another selection signal controlled by the video timing generator. Output unit  563  receives and transmits the single data stream denoted Data-Out — B in response to one of the pixel clock signals. Again, observe that the output unit  563  transmits a synchronous version of the clock signal which is used to transmit data stream Data — Out — B. This synchronous clock is denoted Clk — Out — B. 
   A detailed diagram of a thru-video FIFO  503  (which is intended to be one possible embodiment of thru-video FIFOs  502  and  504 ) is shown in  FIG. 26 . Thru-video FIFO  503  is designed to be insensitive to phase difference between ICLK and OCLK as long as the read pointer counter  630  and write pointer counter  632  are initialized far enough apart that their values cannot become equal during the time-skew, if any, between the removal of reset from the read pointer counter  630  and write pointer counter  632 . This time-skew corresponds to the delay through synchronizer  636 . 
   The output of the read pointer counter  630  comprises a read pointer which addresses a read location in register file  634 . The output of write pointer counter  632  comprises a write pointer which addresses a write location in register file  634 . In one embodiment, register file  634  may be a 8×40 2-port asynchronous register file. Thus, the read pointer and write pointer may be 3 bit quantities to address the eight locations of register file  634 . Input data signals DataIn are clocked into register file  634  using ICLK, and data signals DataOut are clocked out of register file  634  using OCLK. Write pointer counter  632  is driven by ICLK, and read pointer counter  630  is driven by OCLK. 
   In the embodiment shown, the synchronizer delay is nominally 2 clocks. Therefore, initializing read pointer counter  630  to 0×0and write pointer counter  632  to 0×6 should result, after both pointer counters are running, in a difference of about 4, i.e. approximately half the depth of the register file  634 . In other words, the depth of register file  634  is chosen to be more than twice the worst-case synchronizer delay for synchronizing reset with ICLK. 
   In one embodiment, the reset signal provided to thru-video FIFO  503  is the logical OR of a chip reset and a software reset. The software reset is programmable via the MCv-bus, is activated by a chip reset, and remains active after the chip reset. The reset signal is synchronized with OCLK before being presented to the reset port of the thru-video FIFO  503 . 
   Reset clears any horizontal reset (Hreset) and vertical reset (Vreset) bits in register file  634 , so that when reset is removed, register file  634  should be approximately half-full of “safe” data. This ensures that the horizontal and vertical counters of the local Video Timing Generator VTG(I,J) will not be affected by “garbage” in the thru-video FIFO  503  during or after reset. 
   Because ICLK and OCLK are distributed from a common source on the board, they have the same frequency. (Preferably, the distribution is done through buffers, and not via phase-locked loops.) Therefore, thru-video FIFO  503  will remain approximately half-full forever. Thru-video FIFO  503  is written and read each cycle. Hreset and Vreset are always valid in thru-video FIFO  503 , as long as the video timing generator upstream is running. Hreset and Vreset will always be valid in the thru-video FIFO  503 , even at times when there is no active video data flowing through thru-video FIFO  503 , such as during horizontal and vertical retrace. 
   To guarantee ICLK/OCLK phase insensitivity, the thru-video FIFOs in a video group (e.g. the thru-video FIFOs  502  in video group A) may be set running so as to preserve the half-full state of each thru-video FIFO and the integrity of the Hreset and Vreset stream in all thru-video FIFOs during every clock subsequent to the removal of reset from the thru-video FIFOs. A software configuration routine should program all video timing generators VTG(I,J) in a video group with the same video timing parameters, and the pixel clock generator (e.g. genlocking pixel clock  180 A) for that video group. The pixel clock (e.g. pixel clock A) is set running, and the software configuration routine waits to ensure that the pixel clock is stable. Then, the software configuration routine may enable the video timing generators VTG(I,J) of the video group to run. Then, beginning at the lead sample-to-pixel calculation unit CU(I,J) and working down the chain to the last sample-to-pixel calculation unit in the video group, the software configuration routine removes reset from each thru-video FIFO, one at a time. This ensures that a valid stream of Hreset and Vreset is available at the input to each thru-video FIFO from the instant reset is removed from its write pointer counter. Note that, if the MCv-bus routing between sample-to-pixel calculation units is the same as that of the digital video routing between sample-to-pixel calculation units, it should be possible to remove reset “simultaneously” from all thru-video FIFOs by writing to the global address space associated with the video stream to which they belong. Because of the way global writes propagate on the MCv-bus, reset will be removed from each thru-video FIFO sequentially, beginning at the head of the video chain. 
   For safety, it may be preferable to make the video timing generator VTG(I,J) on the lead sample-to-pixel calculation unit CU(I,J) ignore any Hreset and Vreset from the thru-video FIFO. This feature is what differentiates leader and slave video timing modes in the video timing generators VTG(I,J). 
   The video timing generators VTG(I,J) in the video chain may be started in an asynchronous manner, and may initially have random horizontal and vertical phase with respect to one another. They will, within a video frame time, become correctly synchronized with one another, as their horizontal and vertical counters are reset by the receipt of Hreset and Vreset signals from the head of the video chain. 
   In the preferred embodiment, a software configuration routine waits for the pixel clock A to stabilize and for the video routers VR(I,J) of previous graphics boards GB( 0 ), GB( 1 ), . . . , GB(I- 1 ) to be completely initialized before removing reset from the thru-video FIFOs  502  on graphics board GB(I). This ensures a valid stream of horizontal reset and vertical reset flows into thru-video FIFO  502  in the first sample-to-pixel calculation unit CU(I, 0 ) of graphics board GB(I) when reset is removed from the thru-video FIFOs  502  on graphics board GB(I). 
   The present invention also contemplates a video signal integration system comprising a linear chain of video routers as described above. Each video router of the linear chain receives a corresponding stream of pixel values computed for a corresponding column of a global managed area. Each stream of pixel values may be computed by filtering hardware operating super-samples stored in one or more sample buffers. Alternatively, each stream of pixel values may arise from pixel rendering hardware which computes pixels values from graphics primitives without intervening super-samples. 
   It is noted that the method of integrating computed image pixels into a video stream through successive video router stages is independent of the method used to originate the video stream. In one application scenario, one or more of the video streams received by a graphics board (e.g. see input streams X k-1  and Y k-1 ) may arise from one or more digital cameras instead of from a previous graphics board. Thus, a chain of one or more graphics boards may be used to mix computed image pixels with video pixels generated by the digital camera(s). In other applications, the source video stream may originate from a VCR, a DVD unit, a received MPEG transmission, etc. 
   In the various embodiments above, the multiple video streams generated by the linear array of video routers have been interpreted as separate video signals intended for separate display devices. In one alternate set of embodiments, one or more of the multiple video streams may be integrated into a single video signal prior to D/A conversion by a pixel line buffer PLB. One embodiment of a pixel line buffer is suggested by  FIG. 27A . Pixel line buffer PLB is configured to receive four video streams from the last video router in a linear array of video routers. (The linear array of video routers may span multiple graphics boards.) For example, pixel line buffer PLB may be coupled to the four video stream outputs of the last sample-to-pixel calculation unit CU(N- 1 ) of  FIG. 18 . 
   The video routers in the linear array may be partitioned into four video groups. Each group is responsible for generating one of the four video streams A–D. Each video stream may correspond to a portion of a display field as suggested by  FIG. 27B . The display field represents the array of pixels in one frame (or field) of video signal output from the pixel line buffer. Pixel line buffer PLB may comprise two sets of segment buffers, i.e. a first set comprising segment buffers A 1 , B 1 , C 1  and D 1 , and a second set comprising segment buffers A 2 , B 2 , C 2  and D 2 . Each line of the display field may be partitioned into four segments (e.g. quarters). Segment buffers A 1 , B 1 , C 1  and D 1  are configured to store pixels for the first, second, third and fourth segments of the arbitrary line. Similarly, segment buffers A 2 , B 2 , C 2  and D 2  are configured to store pixels for the first, second, third and fourth segments of the arbitrary line. The first and second sets of segment buffers may be used in a double-buffered fashion, i.e. writing to the first set while reading from the second, and vice versa. The switching between the first and second set of segment buffers is controlled by the SELECT signal. The pixel data stored in the first set of segment buffers is dumped to the DAC  179  while video streams A–D write into the second set of segment buffers. Conversely, pixel data stored in the second set of segment buffers is dumped to DAC  179  while video streams A–D write into the first set of segment buffers. Pixel line buffer PLB includes multiplexors which support such double-buffered pixel reading and dumping as shown in  FIG. 27A . 
   Video streams A, B, C and D write into segment buffers Ak, Bk, Ck and Dk respectively, where k equals 1 or 2 depending on the select signal. Video streams A–D are generated by four corresponding groups of sample-to-pixel calculation units. All four groups may be driven by a common pixel clock signal. Thus, the synchronous clock signals embedded in each of the video streams A–D have the same frequency, and each of video streams writes into a corresponding one of the segment buffers at a common rate R. To maintain a buffer stability, pixels are clocked out of the segment buffers at a rate of 4R. In other words, the output pixel clock denoted “4× Dot Clock” in  FIG. 28  has a frequency equal to four times the frequency of the common pixel clock signal denoted “Dot Clock” used by the sample-to-pixel calculation units in generation of the video streams.  FIG. 28  also illustrates a write enable signal which controls the writing of a typical video stream into one of the segment buffers. The video steam is represented by the signal denoted “Video In”. In addition, a typical video output signal is from the pixel line buffer is illustrated. Pixel line buffer PLB may also include a TTL-to-PECL converter (denoted CNV in the figure) on each video stream input. 
   Although the embodiments above have been described in considerable detail, other versions are possible. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications. Note that the headings used herein are for organizational purposes only and are not meant to limit the description provided herein or the claims attached hereto.