Abstract:
An image rendering device disclosed herein comprises a fragment generator configured to generate a set of fragments including pixels in different positions based on inputted pixel data; and a pixel processor configured to sequentially process the pixel data contained in the fragment generated by the fragment generator.

Description:
CROSS REFERENCE TO RELATED APPLICATION  
         [0001]    This application claims benefit of priority under 35 U.S.C.§119 to Japanese Patent Application No. 2003-123986, filed on Apr. 28, 2003, the entire contents of which are incorporated by reference herein.  
         BACKGROUND OF THE INVENTION  
         [0002]    1. Field of the Invention  
           [0003]    The present invention relates to an image rendering device and an image rendering method.  
           [0004]    2. Description of the Related Art  
           [0005]    Generally, even if, in a depth test and an alpha blend, a write process is performed in the same pixel position during the time from when a current value is read from a frame buffer until a value of a processing result is written, the result of the write process can not be reflected, and hence a correct processing result can not be obtained. Therefore, in a related art, there is a mechanism in which the position of a pixel being processed at present is held in a pixel processor and compared with the position of a pixel to be newly processed, and when the position of the pixel to be newly processed matches that of the pixel being processed, the completion of processing is waited for.  
           [0006]    [0006]FIG. 1 is a block diagram showing the configuration of a related image rendering device. A rasterizer  10  shown in FIG. 1 performs the processing of expanding a polygon on an image memory on a pixel-by-pixel basis.  
           [0007]    For example, pixel-by-pixel colors are determined by interpolating colors given to respective vertexes by a method called smooth shading. In this case, a pixel processor  20  hides (does not render) an object which is hidden behind another object and invisible by a hidden surface removal algorithm called a Z-buffer algorithm. This is also called a depth test. The pixel processor  20  includes a register  22  and an arithmetic unit  24 , and frame buffer values in a memory  30  and values from the rasterizer are stored in sequence in the register  22 , processed by texture mapping and a Z-buffer algorithm in the arithmetic unit  24 , and stored again in the register  22 . The contents of the register  22  are outputted to the memory  30  which is a frame buffer. Accordingly, when the memory  30  acquires an operation result from the register  22 , it is required to determine by comparison whether a processing position which is being processed by the arithmetic unit  24  and a processing position which is to be acquired from the memory  30  match each other, and when these processing positions match each other, to wait for the start of the processing of the corresponding pixel.  
           [0008]    However, with an increase in the clock frequency of LSI, latency in processing (time from when data is inputted to the register  22  in FIG. 2 until the data is outputted) becomes longer, whereby the number of pixels which need to be held increases, which causes problems of enlargement of a comparator and an increase in stop rate due to a match between processing positions.  
           [0009]    On the other hand, due to an increase in the scale of the LSI, the degree of parallelism for pixel processors which can be mounted on the LSI increases, but in the related art, only part of many arranged pixel processors can be brought into operation in small polygon processing, and hence the processing efficiency does not increase as much as the circuit scale.  
         SUMMARY OF THE INVENTION  
         [0010]    In order to accomplish the aforementioned and other objects, according to one aspect of the present invention, an image rendering device, comprises:  
           [0011]    a fragment generator configured to generate a set of fragments including pixels in different positions based on inputted pixel data; and  
           [0012]    a pixel processor configured to sequentially process the pixel data contained in the fragment generated by the fragment generator.  
           [0013]    According to another aspect of the present invention, an image rendering device, comprises:  
           [0014]    a data buffer configured to hold rasterization results of polygons, wherein the data buffer merges the rasterization results which do not conflict with each other and holds them as one rasterization result; and  
           [0015]    a pixel processor configured to acquire the rasterization result from the data buffer and sequentially process pixel data contained in the rasterization result.  
           [0016]    According to a further aspect of the present invention, an image rendering method, comprises:  
           [0017]    generating a set of fragments including pixels in different positions based on inputted pixel data; and  
           [0018]    sequentially processing the pixel data contained in the generated fragment.  
           [0019]    According to a still further aspect of the present invention, an image rendering method, comprises:  
           [0020]    holding rasterization results of polygons, and merging the rasterization results which do not conflict with each other and holding them as one rasterization result; and  
           [0021]    acquiring the rasterization result from the data buffer and processing pixel data contained in the rasterization result in sequence.  
           [0022]    According to another aspect of the present invention, a graphic system comprises:  
           [0023]    a memory in which vertex data to render object is stored;  
           [0024]    a CPU configured to read out the vertex data from the memory to execute processing and output the result of the processing as pixel data; and  
           [0025]    an image rendering device including:  
           [0026]    a fragment generator configured to generate a set of fragments including pixels in different positions based on the inputted pixel data; and  
           [0027]    a pixel processor configured to sequentially process the pixel data contained in the fragment generated by the fragment generator.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0028]    [0028]FIG. 1 is a block diagram showing the configuration of a related image rendering device;  
         [0029]    [0029]FIG. 2 is a block diagram explaining a problem in the related image rendering device;  
         [0030]    [0030]FIG. 3 is a diagram explaining the concept of a merger of chunks in an embodiment;  
         [0031]    [0031]FIG. 4 is a block diagram explaining the configuration of an image rendering device according to this embodiment;  
         [0032]    [0032]FIG. 5 is a block diagram explaining a modification of the configuration of the image rendering device;  
         [0033]    [0033]FIG. 6 is a block diagram explaining another modification of the configuration of the image rendering device;  
         [0034]    [0034]FIG. 7 is a block diagram explaining still another modification of the configuration of the image rendering device;  
         [0035]    [0035]FIG. 8 is a block diagram explaining the configuration of a chunk merge unit according to this embodiment;  
         [0036]    [0036]FIG. 9 is a diagram explaining the connection relation between chunk data buffers and pixel processors;  
         [0037]    [0037]FIG. 10 is a block diagram explaining another configuration of the chunk merge unit according to this embodiment;  
         [0038]    [0038]FIG. 11 is a diagram showing an example in which two polygons are merged in a case where conflict determination is performed on a pixel-by-pixel basis and chunks are merged on a pixel-by-pixel basis;  
         [0039]    [0039]FIG. 12 is a diagram showing another example in which two polygons are merged in the case where conflict determination is performed on a pixel-by-pixel basis and chunks are merged on a pixel-by-pixel basis;  
         [0040]    [0040]FIG. 13 is a flowchart explaining merging processing in the case where conflict determination is performed on a pixel-by-pixel basis and chunks are merged on a pixel-by-pixel basis;  
         [0041]    [0041]FIG. 14 is a diagram showing an example in which two polygons are merged in a case where conflict determination is performed on a pixel-by-pixel basis and chunks are merged on a stamp-by-stamp basis;  
         [0042]    [0042]FIG. 15 is a diagram showing another example in which two polygons are merged in the case where conflict determination is performed on a pixel-by-pixel basis and chunks are merged on a stamp-by-stamp basis;  
         [0043]    [0043]FIG. 16 is a flowchart explaining merging processing in the case where conflict determination is performed on a pixel-by-pixel basis and chunks are merged on a stamp-by-stamp basis;  
         [0044]    [0044]FIG. 17 is a diagram showing an example in which two polygons are merged in a case where conflict determination is performed on a stamp-by-stamp basis and chunks are merged on a stamp-by-stamp basis;  
         [0045]    [0045]FIG. 18 is a diagram showing another example in which two polygons are merged in the case where conflict determination is performed on a stamp-by-stamp basis and chunks are merged on a stamp-by-stamp basis;  
         [0046]    [0046]FIG. 19 is a flowchart explaining merging processing in the case where conflict determination is performed on a stamp-by-stamp basis and chunks are merged on a stamp-by-stamp basis;  
         [0047]    [0047]FIG. 20 is a block diagram explaining a chunk data store/read mechanism according to this embodiment;  
         [0048]    [0048]FIG. 21 is a flowchart explaining processing in the store/read mechanism in FIG. 20;  
         [0049]    [0049]FIG. 22 is a block diagram explaining another chunk data store/read mechanism according to this embodiment;  
         [0050]    [0050]FIG. 23 is a flowchart explaining the process for deciding an entry from which processing is started by the pixel processor in the store/read mechanism in FIG. 22;  
         [0051]    [0051]FIG. 24 is a diagram explaining conflict determination of stamps when plural same position stamps exist;  
         [0052]    [0052]FIG. 25 is a diagram explaining the processing concept of specifying a stamp, in which pixel data is stored, by using a table;  
         [0053]    [0053]FIG. 26 is a diagram explaining the contents of the table in FIG. 25;  
         [0054]    [0054]FIG. 27 is a diagram showing an example explaining a logic circuit in a case where a stamp to be stored is specified by using the logic circuit;  
         [0055]    [0055]FIG. 28 is a diagram explaining an example in which a chunk is composed of pixels which are located adjacent to each other in a rectangular shape;  
         [0056]    [0056]FIG. 29 is a diagram explaining an example in which a chunk is composed of pixels which are located apart from each other;  
         [0057]    [0057]FIG. 30 is a diagram showing an example of the hardware configuration of a real-time three-dimensional graphics system equipped with the image rendering device according to this embodiment;  
         [0058]    [0058]FIG. 31 is a block diagram showing an example of the configuration of the image rendering device according to this embodiment; and  
         [0059]    [0059]FIG. 32 is a block diagram showing another example of the configuration of the image rendering device according to this embodiment. 
     
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS  
       [0060]    In this embodiment, in rasterization processing, a buffer is disposed after setup/DDA (Digital Differential Analysis) processing, and rasterization results of plural polygons are buffered and merged, and then processed by pixel processor. Further details will be given below.  
         [0061]    [0061]FIG. 3 is a diagram explaining the concept of merging rasterization results in this embodiment. As shown in FIG. 3, in this embodiment, the concept of a “chunk”, in which neighboring plural pixels are gathered together, is introduced. In the example in FIG. 3, one chunk is composed of 8×8=64 pixels. This chunk is a fragment in this embodiment. By using the concept of the chunk, it is guaranteed that pixels which are continuously thrown in are not in the same position, and the chunk is processed by a pixel processor. In small graphics primitives (triangle, polygon), the proportion of valid pixels in one chunk is low, and hence a merger is carried out as shown in FIG. 3. In the example in FIG. 3, two graphics primitives are merged and represented as pixels in one chunk.  
         [0062]    [0062]FIG. 4 is a block diagram showing the basic configuration of an image rendering device according to this embodiment. As shown in FIG. 4, in the image rendering device according to this embodiment, a chunk merge unit  100  and a chunk data buffer  110  are additionally inserted between a rasterizer  10  and a pixel processor  20 .  
         [0063]    The rasterizer  10  performs the processing of expanding a polygon on an image memory on a pixel-by-pixel basis. Pixel-by-pixel colors are determined by interpolating colors given to respective vertexes by a method called smooth shading. The rasterizer  10  outputs pixel-by-pixel data as a rasterization result to the chunk merge unit  100 .  
         [0064]    The chunk merge unit  100  converts the pixel-by-pixel data into chunk-by-chunk data and performs a merger of data. Data resulted from the merger is outputted to the chunk data buffer  110 . In the chunk merge unit  100 , at the time of a merger of chunks, pixel data with a deeper depth may be abandoned based on depths of respective pixels. In other words, the chunk merge unit  100  may have a depth test function. The chunk data buffer  110  is a data buffer, and the pixel processor  20  acquires chunk data stored in the chunk data buffer  110 .  
         [0065]    The pixel processor  20  processes the merged chunk data. Namely, the pixel processor  20  executes a hidden surface removal algorithm called a Z-buffer algorithm for the chunk data (depth test function). Even when the chunk merge unit  100  has a depth test function, the pixel processor  20  also needs to perform a depth test for correct hidden surface removal.  
         [0066]    The image rendering device shown in FIG. 4 has the most basic configuration, and one chunk data buffer  110  and one pixel processor  20  are provided for one chunk merge unit  100 . It is possible to simultaneously store one or more pieces of chunk data in the chunk data buffer  110 .  
         [0067]    [0067]FIG. 5 is a diagram showing a modification of the image rendering device. In the example in FIG. 5, plural pixel processors  20  are provided for one chunk merge unit  100 , and a memory  30  is fixed to each of the pixel processors  20 . In the example in FIG. 5, two pixel processors  20  are provided for one chunk merge unit  100 . Chunk data to be processed by each of the pixel processors  20  is fixedly determined by the position (X-coordinate, Y-coordinate) of a chunk. A one-to-one correspondence is established between the chunk data buffers  110  and the pixel processors  20 , and the chunk merge unit  100  determines which pixel processor  20  processes the chunk data.  
         [0068]    [0068]FIG. 6 is a diagram showing another modification of the image rendering device. In the example in FIG. 6, the pixel processors  20  and the memory  30  are connected by a bus. The bus may be a unibus or a multibus. The example in FIG. 6 is effective when the memory  30  is formed on a different chip from the pixel processors  20 . In this case, each pixel processor  20  can access the entire region of the memory  30 .  
         [0069]    [0069]FIG. 7 is a diagram showing still another modification of the image rendering device. In the example in FIG. 7, plural pixel processors  20  are provided, but no restriction is put on the connection relationship between the chunk data buffer  110  and the pixel processors  20 . Namely, chunk data to be processed by each pixel processor  20  is optional, and the next chunk data is processed when the pixel processor  20  is available. In other words, each of the pixel processors  20  can process chunk data in any position. Hence, load distribution between the pixel processors  20  becomes easy. However, a mechanism not to simultaneously process the same position chunks is needed.  
         [0070]    [0070]FIG. 8 is a block diagram showing the configuration of the chunk merge unit  100  according to this embodiment in detail. As shown in FIG. 8, the chunk merge unit  100  according to this embodiment includes a pixel merger  120 , a mask buffer  122 , a data buffer  124 , and a signal generator  126 .  
         [0071]    The pixel merger  120  checks whether pixels generated from different primitives are merged. In the example in FIG. 8, depths of pixels, which are contained in chunks stored in the chunk data buffer  110 , are also inputted to the pixel merger  120 . Therefore, the pixel merger  120  compares a depth of pixel data stored in the chunk data buffer  110  and a depth of pixel data inputted from the rasterizer  10  and abandons the pixel data with a deeper depth. Namely, it can be said that the chunk merge unit  100  in FIG. 8 has a depth test function, too.  
         [0072]    The mask buffer  122  holds whether a write has been performed to each of pixels as a status in the chunk data buffer  110 . This status is composed of 1-bit data per pixel.  
         [0073]    The data buffer  124  temporarily holds parameters of respective pixels. The signal generator  126  determines whether to flush the chunk data buffer  110  and start a controller of the pixel processor  20  based on an RP status and an overflow flag.  
         [0074]    Coverage and pixel parameters are data inputted from the rasterizer  10 . The coverage is information indicating whether the pixel parameters are valid or invalid. That is, the coverage is information indicating whether it is inside or outside the triangle. The RP status is status information indicating whether the pixel processor  20  is in the middle of processing, and it is inputted from the pixel processor  20 .  
         [0075]    Chunk data outputted from the data buffer  124  to the chunk data buffer  110  is 32 bits×(6 to 8 parameters) per pixel, and written to the chunk data buffer  110  in each cycle. The chunk data buffer  110  determines to which chunk the inputted chunk data relates, and writes the chunk data to the determined chunk. The pixel merger  120  determines whether the chunk data is actually written. Namely, the pixel merger  120  outputs a write enable to the chunk data buffer  110  when a write process is performed.  
         [0076]    [0076]FIG. 9 is a diagram showing an example of the connection relation between the chunk data buffers  110  and the pixel processors  20 . In the example shown in FIG. 9, 16 chunk data buffers  110  and 32 pixel processors  20  are provided. Accordingly, ideally speaking, the chunk data buffers  110  and the pixel processors  20  have a full X-bar configuration of the ratio of 16:32, but in this embodiment, a configuration in which four chunk data buffers  110  and eight pixel processors  20  are connected to each of four 256-bit buses is adopted. The chunk merge unit  100  and the chunk data buffers  110  are connected by a 1024-bit bus.  
         [0077]    [0077]FIG. 10 is a block diagram showing another configuration example of the chunk merge unit  100  according to this embodiment in detail. In this example, a block shown in FIG. 10 is provided for every pixel. Accordingly, in this embodiment, the number of blocks shown in FIG. 10 must be the same as the number of pixels in a stamp. Since 2×2=4 pixels constitutes one stamp in this embodiment, four blocks shown in FIG. 10 are needed for one stamp.  
         [0078]    As shown in FIG. 10, the chunk merge unit  100  corresponding to one pixel includes a chunk data address calculator  130 , a chunk flush controller  132 , a buffer  134 , a value comparison circuit  136 , and an AND circuit  138 .  
         [0079]    The chunk data address calculator  130  calculates an address in the chunk data buffer  110  which holds chunk data containing X and Y coordinates of a pixel to be processed.  
         [0080]    The chunk flush controller  132  determines whether pixel or stamp data inputted from the rasterizer  10  and pixel or stamp data in the chunk flush controller  132  conflict with each other. Alternatively, the chunk flush controller  132  determines which data is to be left according to their pixel depths.  
         [0081]    When both data conflict with each other, the chunk flush controller  132  transmits chunk data in the chunk data buffer  110  at this point in time to the pixel processor  20 , defines a new chunk, and write the pixel data inputted from the rasterizer  10  in the new chunk. Moreover, if the data to be left can be determined based on the pixel depths and the like, the chunk merge unit  100  determines whether the pixel data inputted from the rasterizer  10  is abandoned or the pixel data inputted from the rasterizer  10  is overwritten in the chunk data buffer  110 .  
         [0082]    The buffer  134  is simply FIFO, and holds the pixel data inputted from the rasterizer  10  during the aforementioned process. The value comparison circuit  136  compares the values of a pixel depth depth 1  inputted from the rasterizer  10  and a pixel depth depth 2  in the chunk data buffer  110 . Then, it determines a value comparison result from depth 1 &gt;depth 2 , depth 1 ≧depth 2 , depth 1 ≦depth 2 , depth 1 &lt;depth 2 , depth 1 ≠depth 2 , depth 1 =depth 2 , and regular overwriting. In other words, based on the comparison result by the value comparison circuit  136 , the chunk merge unit  100  performs a depth test and abandons one of the pixel data inputted from the rasterizer  10  and the same position pixel data in the chunk data buffer  110 .  
         [0083]    The AND circuit  138  performs an AND operation, in which case the pixel inputted from the rasterizer  10  is valid and the pixel in the chunk data buffer  110  is valid.  
         [0084]    [0084]FIG. 11 and FIG. 12 are diagrams explaining the processing concept of merging chunks on a pixel-by-pixel basis. FIG. 11 is a diagram explaining a merger when polygons are arranged side by side in different chunks, and FIG. 12 is a diagram explaining a merger when polygons overlap each other in different chunks.  
         [0085]    In the merging processing shown in FIG. 11 and FIG. 12, whether pixels in respective chunks conflict with each other is determined on a pixel-by-pixel basis and the chunks are merged on a pixel-by-pixel basis. In the example in FIG. 1, it is assumed that a chunk  1  stored in the chunk data buffer  110  and a chunk  2  inputted from the rasterizer  10  are in the same position. In the example in FIG. 11, pixel data in the chunk  1  stored in the chunk data buffer  110  and pixel data in the chunk  2  inputted from the rasterizer  10  do not overlap each other. Hence, the pixel data formed from two polygons are merged into one chunk  1 , and stored as one chunk data in the chunk data buffer  110 . Accordingly, pixels of these two polygons are processed by one pixel processor  20 .  
         [0086]    On the other hand, in the example in FIG. 12, pixel data in the chunk  1  stored in the chunk data buffer  110  and pixel data in the chunk  2  inputted from the rasterizer  10  overlap each other. Namely, these pixel data exists at the same X coordinate and Y coordinate. Therefore, new pixels of the chunk  2  are added only to pixels, in which no data exists, of the chunk  1 , and the remaining pixels of the chunk  2  are generated as pixels of the new chunk  2 . Accordingly, pixels of these two polygons are separately stored as two pieces of chunk data in the chunk buffer data  110  and separately processed by the pixel processors  20 .  
         [0087]    In the merging method shown in FIG. 11 and FIG. 12, the filling factor increases, but first derivative calculation with the next pixel differs according to a merger result.  
         [0088]    [0088]FIG. 13 is a flowchart for explaining pixel-by-pixel merging processing such as shown in FIG. 11 and FIG. 12. As shown in FIG. 13, it is determined whether a chunk containing a rasterization position inputted from the rasterizer  10  exists in the chunk buffer  110 , and if the chunk exists, the chunk is acquired (step S 110 ). This processing in step S 110  is performed by the chunk data address calculator  130  of the chunk merge unit  100 .  
         [0089]    Then, the chunk merge unit  100  acquires pixels in a stamp (step S 120 ). Subsequently, the chunk merge unit  100  determines whether two chunks to be merged are in the same position and a conflict occurs to any of all pixels in respective stamps (step S 130 ). When no conflict occurs to any pixel (step S 130 : No), pixel data is additionally written into the existing chunk (step S 170 ).  
         [0090]    On the other hand, if a conflict occurs to any pixel (step S 130 : Yes), only pixels which do not conflict are additionally written into the existing chunk and pixel data which has been written is deleted from write data (step S 140 ). Subsequently, after flushing the chunk (step S 150 ), the chunk merge unit  100  clears the chunk (step S 160 ). Then, the chunk merge unit  100  writes the remaining pixel data into this new chunk.  
         [0091]    The processing from step S 130  to step S 170  is performed by the chunk flush controller  132  of the chunk merge unit  100 . Condition determination as to whether a conflict occurs or not is performed by the value comparison circuit  136  and the AND circuit  138 .  
         [0092]    Then, the rasterizer  10  determines whether rasterization is completed (step S 180 ). When the rasterization is not completed (step S 180 : No), the rasterizer  10  moves to the next stamp (step S 190 ), and if a chunk containing a rasterization position after movement exists, this chunk is acquired (step S 200 ). Then, the aforementioned processing from step S 120  is repeated. The processing in step S 200  is performed by the chunk data address calculator  130  of the chunk merge unit  100 .  
         [0093]    On the other hand, when it is determined in step S 180  that the rasterization is completed (step S 180 : Yes), this processing is completed.  
         [0094]    [0094]FIG. 14 and FIG. 15 are diagrams explaining the processing concept of merging chunks on a stamp-by-stamp basis. As described above, in this embodiment, one stamp is composed of 2×2=4 pixels. FIG. 14 is a diagram explaining a merger when polygons are arranged side by side in different chunks, and FIG. 15 is a diagram explaining a merger when polygons overlap each other in different chunks.  
         [0095]    In the merging processing shown in FIG. 14 and FIG. 15, whether pixels in respective chunks conflict with each other is determined on a pixel-by-pixel basis and the chunks are merged on a stamp-by-stamp basis. In the example in FIG. 14, pixel data in the chunk  1  stored in the chunk data buffer  110  and pixel data in the chunk  2  inputted from the rasterizer  10  do not overlap on a pixel-by-pixel basis. Therefore, the pixel data formed from two polygons are merged into one chunk  1 , and stored as one chunk  1  in the chunk data buffer  110 . Accordingly, pixels of these two polygons are processed by one pixel processor  20 .  
         [0096]    On the other hand, in the example in FIG. 15, pixel data in the chunk  1  stored in the chunk data buffer  110  and pixel data in the chunk  2  inputted from the rasterizer  10  overlap each other on a pixel-by-pixel basis. Namely, these pixel data exist at the same X coordinate and Y coordinate. Therefore, only stamps, in which no pixel conflicts, out of stamps in the chunk  2  are added as new pixels (stamps) to the chunk. Namely, when any one of four pixels in one stamp conflicts with a pixel in the existing stamp, the four pixels are not added to the existing chunk. The remaining pixels (stamps) in the chunk  2  are written into pixels (stamps) in the new chunk  2 . Accordingly, pixels of these two polygons are separately stored as two pieces of chunk data in the chunk buffer data  110  and separately processed by the pixel processors  20 .  
         [0097]    As compared with the merging method shown in FIG. 11 and FIG. 12, the merging method shown in FIG. 14 and FIG. 15 is the same in that the filling factor decreases slightly and the first derivative calculation with the next pixel differs according to a merger result.  
         [0098]    [0098]FIG. 16 is a flowchart for explaining stamp-by-stamp merging processing such as shown in FIG. 14 and FIG. 15. The merging processing shown in FIG. 16 is different from the merging processing shown in FIG. 13 in step S 220 .  
         [0099]    Namely, in the merging processing in FIG. 16, after step S 120 , it is determined whether a chunk in the same position exists and a conflict occurs to any one of all pixels in a stamp constituting the chunk (step S 220 ). When no conflict occurs (step S 220 : No), the stamp is written as pixel data into the exiting chunk (step S 170 ).  
         [0100]    On the other hand, if a conflict occurs to any one of pixels in the stamp (step S 220 : Yes), the chunk is flushed (step S 150 ) and cleared (step S 160 ). Namely, all of four pixels in a stamp which are processed at the same time are written into the existing chunk data buffer  110  or written into a newly generated chunk.  
         [0101]    [0101]FIG. 17 and FIG. 18 are diagrams explaining the processing concept of performing conflict determination on a stamp-by-stamp basis and merging chunks on a stamp-by-stamp basis. FIG. 17 is a diagram explaining a merger when polygons are arranged side by side in different chunks, and FIG. 18 is a diagram explaining a merger when polygons overlap each other in different chunks.  
         [0102]    In the merging processing shown in FIG. 17 and FIG. 18, whether pixels in respective chunks conflict with each other is determined on a stamp-by-stamp basis, and the chunks are merged on a stamp-by-stamp basis. In the example in FIG. 17, pixel data in the chunk  1  stored in the chunk data buffer  110  and pixel data in the chunk  2  inputted from the rasterizer  10  do not overlap each other on a pixel-by-pixel basis but overlap each other on a stamp-by-stamp basis.  
         [0103]    Therefore, the pixel data formed from two polygons are merged into two chunk  1  and chunk  2 . Accordingly, these two chunks are processed separately by the pixel processors  20 .  
         [0104]    Similarly, also in the example in FIG. 18, pixel data in the chunk  1  stored in the chunk data buffer  110  and pixel data in the chunk  2  inputted from the rasterizer  10  overlap each other on a stamp-by-stamp basis. Namely, when pixel data is already written in a stamp located in the same position, it is determined that stamps conflict with each other regardless of whether the same position pixel data actually exists.  
         [0105]    Hence, only stamps, to which no conflict occurs, out of stamps in the chunk  2  are additionally written into the chunk  1 . In other words, if pixel data is already written into the existing stamp located in the same position, a stamp in the same position is not added to the existing chunk. The remaining pixels (stamps) in the chunk  2  are written into the new chunk  2 . Accordingly, pixels of these two polygons are separately stored as two pieces of chunk data in the chunk buffer data  110  and separately processed by the pixel processors  20 .  
         [0106]    In the merging method shown in FIG. 17 and FIG. 18, the filling factor decreases, but first derivative calculation with the next pixel is constant in a stamp, whereby a merging mechanism can be simplified. Namely, it can be determined whether stamps containing valid pixels inputted from the rasterizer  10  can be additionally written into the chunk data buffer  110  by only determining whether chunk data stored in the chunk data buffer  110  is valid or invalid on a stamp-by-stamp basis.  
         [0107]    [0107]FIG. 19 is a flowchart for explaining stamp-by-stamp merging processing such as shown in FIG. 17 and FIG. 18. The merging processing shown in FIG. 19 is different from the merging processing shown in FIG. 16 in step S 240 .  
         [0108]    Namely, in the merging processing in FIG. 19, after step S 120 , it is determined whether a chunk in the same position exists and pixel data is already written into a stamp in the same position (step S 240 ). When the pixel data is not written in the stamp in the same position (step S 240 : No), the stamp is written as pixel data into the exiting chunk (step S 170 ).  
         [0109]    On the other hand, if the pixel data is already written into the stamp in the same position (step S 240 : Yes), the chunk is flushed (step S 150 ) and cleared (step S 160 ). Then, pixel data in the stamp is written into the new chunk.  
         [0110]    Incidentally, it is defined that in the merger of chunks hitherto explained by means of FIG. 11 to FIG. 19, a depth of each pixel is not taken into account. Namely, the chunk merge unit  100  which carries out the merger from FIG. 11 to FIG. 19 is regarded as not including a depth test function or as being used when a polygon such as a translucent polygon incapable of a depth test is rendered.  
         [0111]    [0111]FIG. 20 is a diagram showing an example of a store/read mechanism which allows the chunk merge unit  100  to read chunk data from the chunk data buffer  110  and allows the pixel processor  20  to acquire the chunk data from the chunk data buffer  110 . In the example in FIG. 20, the store/read mechanism is composed of plural merge data buffers  200 . A valid flag v, a compare flag c, and chunk positions x and y of the merge data buffer  200  are formed by the chunk data address calculator  130  of the chunk merge unit  100 . Chunk data d indicates a storage region of chunk data in the chunk data buffer  100 .  
         [0112]    Entries of the chunk data buffer  110  are classified into chunks which are being processed by the pixel processors  20 , valid chunks which are waiting for processing by the pixel processors  20 , and invalid chunks which have been processed by the pixel processors  20 .  
         [0113]    The valid flag v indicates whether valid chunk data is stored in each entry of the merge data buffer  200 . The example in FIG. 20 shows that the entry is valid when the valid flag v is 1, and that the entry is invalid when the valid flag v is 0.  
         [0114]    The compare flag c indicates whether the entry is a chunk to be compared by the chunk merge unit  100 . In the example in FIG. 20, when the compare flag c is 1, the chunk merge unit  100  compares a chunk of the entry with a chunk inputted from the rasterizer  10 , and when the compare flag c is 0, it does not make a comparison. When the chunk merge unit  100  newly writes an entry, the compare flag c is turned on and set to 1. When a conflict occurs at the time of a write, the compare flag c of the entry is turned off and set to 0. Namely, as concerns a chunk which has been merged, its compare flags c is 0. Also as concerns an entry whose processing is started by the pixel processor  20 , its compare flag c is set to 0. Consequently, false overwriting in a chunk, which is in the middle of processing, by the chunk merge unit  100  can be avoided.  
         [0115]    The chunk positions x and y hold X and Y coordinates (position information) of a chunk. In the example in FIG. 20, the chunk positions x and y are each 14-bit information. The chunk merge unit  100  can determine from these chunk positions x and y whether a chunk in the same position exists in the chunk data buffer  110 .  
         [0116]    The chunk data d is 8×8=64 pixel information. Namely, the chunk data d is concrete pixel data on the entry.  
         [0117]    The chunk merge unit  100  designates these valid flag v, compare flag c, and chunk positions x and y to access the chunk data buffer  110 . In the case of a hit, the chunk merge unit  100  can acquire the chunk data d, but in the case of an unhit, no chunk data exists, and hence a chunk is newly generated.  
         [0118]    A begin pointer begin is a pointer which indicates an entry of chunk data to be processed next. Accordingly, the pixel processor  20  fetches chunk data from an entry indicated by the begin pointer begin and processes it. When processing by the pixel processor  20  is started, the begin pointer begin is moved to the next entry.  
         [0119]    As concerns an entry whose processing is started, the pixel processor  20  sets the compare flag c to 0. Moreover, as concerns an entry whose processing is completed, the pixel processor  20  sets the valid flag v to 0.  
         [0120]    [0120]FIG. 21 is a flowchart explaining the processing contents of the store/read mechanism shown in FIG. 20. As shown in FIG. 21, a stamp position is first acquired (step S 300 ). A chunk position is then acquired (step S 310 ).  
         [0121]    Next, a pixel processor number (M) is acquired. This pixel processor number (M) is information for specifying which of plural pixel processors  20  performs processing. By specifying the pixel processor  20  which performs processing, the chunk merge unit  100  which performs a merger of chunks is specified. The processing in step S 300 , step S 310 , and step S 320  are carried out by the rasterizer  10 .  
         [0122]    Thereafter, the specified chunk merge unit  100  searches the merge data buffer  200  and determines whether a chunk which is an object to be processed at present exists in the chunk data buffer  110  (step S 330 ).  
         [0123]    When the chunk as the object to be processed exists in the merge data buffer  200  (step S 330 : Yes), it is determined whether a conflict occurs between pixels. (step S 350 ).  
         [0124]    When no conflict occurs between pixels (step S 350 : No), a stamp inputted from the rasterizer  10  is written into the chunk data d of the merge data buffer  200  (step S 370 ).  
         [0125]    When it is determined in step S 350  that a conflict occurs between pixels (step S 350 : Yes) or when it is determined in the aforementioned step S 330  that the chunk as the object to be processed does not exist in the merge data buffer  200  (step S 330 : No), the chunk merge unit  100  waits until an invalid chunk is detected (step S 360 ). In other words, it waits until a chunk which allows a new write is detected. Then, a stamp is written into the new chunk (step S 370 ).  
         [0126]    The processing in step S  330 , step S 350 , step S 360 , and step S 370  is carried out by the chunk merge unit  100 .  
         [0127]    After step S 370 , it is determined whether rasterization is completed (step S 380 ). When the rasterization is not completed (step S 380 : No), a movement to the next stamp is carried out (step S 390 ), and the aforementioned processing from step S 300  is repeated.  
         [0128]    On the other hand, when the rastization is completed (step S 380 : Yes), this processing is completed. The processing in step S 380  and step S 390  is carried out by the rasterizer  10 .  
         [0129]    [0129]FIG. 22 is a diagram showing the configuration of a modification of the store/read mechanism. The store/read mechanism shown in FIG. 22 is configured by adding a merge status buffer  210  to the merge data buffer  200 .  
         [0130]    The merge status buffer  210  includes a same position chunk order o and an invalid pixel number in chunk f. The same position chunk order o is information which, when plural chunks in the same position exist in the chunk data buffer  110 , is used to specify their generation order. Namely, when only one chunk exists in a certain position, the same position chunk order o is 0, and when two chunks exist, the same position chunk order o of the chunk generated first is 0, and the same position chunk order o of the chunk generated secondly is 1. Hereinafter, similarly to the above, every time a chunk in the same position is generated, the value of the same position chunk order o increases by one. However, the same position chunk order o of the entry which is being processed by the pixel processor  20  is stored with  15  which is the maximum value.  
         [0131]    The invalid pixel number in chunk f is information indicating how many invalid pixels exist in chunk data in the entry. In this embodiment, the possible values of the invalid pixel number in chunk f are 0 to 64. However, the invalid pixel number in chunk f in the entry being processed by the pixel processor  20  is stored with 127 which is the maximum value.  
         [0132]    Moreover, in the chunk data buffer  110  shown in FIG. 22, the begin pointer begin which indicates an entry to be processed next by the pixel processor  20  does not exist. When the pixel processor  20  tries to acquire chunk data from the chunk data buffer  110 , it selects an entry with the smallest invalid pixel number in chunk f and starts processing from this entry. In the example in FIG. 22, the smallest invalid pixel number in chunk f is 3, and therefore the pixel processor  20  acquires chunk data from this entry and processes it.  
         [0133]    When plural same position chunks exist, an entry with the smallest same position chunk order o is selected. Consequently, processing in the pixel processor  20  is performed in the order in which chunk data is generated.  
         [0134]    As concerns an entry whose processing is started by the pixel processor  20 , the compare flag c is set to 0, and the same position chunk order o and the invalid pixel number in chunk f are each set to the maximum value. Moreover, one is subtracted from all values of the same position chunk order o of the same position chunks. When processing in the pixel processor  20  is completed, the valid flag v is set to 0.  
         [0135]    It should be noted that the merging processing of the chunk data buffer  110  shown in FIG. 22 is the same as that in FIG. 21. However, the process for deciding an entry from which the processing is started by the pixel processor  20  is different from that in FIG. 21.  
         [0136]    [0136]FIG. 23 is a flowchart explaining the process for deciding the entry from which the processing is started by the pixel processor  20 .  
         [0137]    As shown in FIG. 23, the pixel processor  20  repeatedly refers to respective entries in the merge status buffer  210 , selects an entry with the smallest invalid pixel number in chunk f and the smallest same position chunk order o, and acquires the chunk data d in this entry (Step S 410 ). Then, it starts to process the acquired chunk data d (Step S 420 ).  
         [0138]    Next, it is determined whether any other same position chunk exists in the chunk data buffer  110  (step S 430 ). If no other same position chunk exists (Step S 430 : No), this processing is completed.  
         [0139]    On the other hand, if other same position chunks exist, one is subtracted from the values of the same position chunk order o of all the same position chunks (step S 440 ). Then, this processing is completed.  
         [0140]    [0140]FIG. 24 is a diagram explaining a merging processing concept different from those described above. A box of 2×2 represents a stamp. It is assumed here that stamps SP 1  to SP 6  are inputted in this order in time sequence.  
         [0141]    At a point in time when the stamp SP 1  is inputted, a new stamp SP 10  (parent stamp) is generated, and pixel data is stored therein. Subsequently, the stamp SP 2  is inputted, but pixel data in this stamp SP 2  conflicts with the pixel data in the existing stamp SP 10 , and hence a new stamp SP 11  (child stamp) is generated, and the pixel data is stored therein.  
         [0142]    Thereafter, the stamp SP 3  is inputted, and since pixel data in this stamp SP 3  does not conflict with the pixel data in the first stamp SP 10 , it is stored in the stamp SP 10 .  
         [0143]    Then, the stamp SP 4  is inputted, but pixel data in this stamp SP 4  conflicts with both the pixel data in the existing stamp SP 10  and stamp SP 11 , whereby a new stamp SP 12  (grandchild stamp) is generated, and the pixel data is stored therein.  
         [0144]    Thereafter, the stamp SP 5  is inputted, but pixel data in this stamp SP 5  conflicts with all the pixel data in the existing stamp SP 10 , stamp SP 11 , and stamp SP 12 , and hence a new stamp SP 13  (great-grandchild stamp) is generated, and the pixel data is stored therein.  
         [0145]    Subsequently, the stamp SP 6  is inputted, and since pixel data in this stamp SP 6  does not conflict with the pixel data in the existing stamp SP 11 , it is stored in the stamp SP 11 .  
         [0146]    As described above, in the example in FIG. 24, when plural existing stamps exist in the same position, a stamp in which no conflict occurs is found from the existing stamps.  
         [0147]    [0147]FIG. 25 is a diagram explaining a method for determining in which existing stamp pixel data in an inputted stamp is stored by using a table  300 . In FIG. 25, existing stamps (in this example, a parent stamp, a child stamp, and a grandchild stamp) and a newly inputted stamp are inputted to the table  300 . The table  300  outputs to which stamp the newly inputted stamp is to be written based on the inputted stamps and information stored in the table  300 . In this example, the newly inputted stamp can be written into the child stamp, and this information is outputted.  
         [0148]    As shown in FIG. 26, in the table  300 , output destinations corresponding to all patterns of pixel data stored in parent stamps, child stamps, grandchild stamps, and great-grandchild stamps respectively and all patterns of pixel data stored in a newly inputted stamp are stored.  
         [0149]    [0149]FIG. 27 is a diagram showing an example when determination in the table  300  is configured by a logic circuit. As shown in FIG. 27, this logic circuit is configured by combining AND circuits AN 1 , NOR circuits NR 1 , and OR circuits OR 1  as shown in illustration.  
         [0150]    In each stamp,  1  indicates a case where pixel data exists, and 0 indicates a case where no pixel exists. By inputting position information on pixel data in a newly inputted stamp, a parent stamp, a child stamp, a grandchild stamp, and a great-grandchild stamp, a 2-bit operation result a[ 1 ], a[ 0 ] is inputted.  
         [0151]    When the operation result a[ 1 ], a[ 0 ] is 1, 1, this means that the write destination is a parent stamp; when the operation result a[ 1 ], a[ 0 ] is 1, 0, this means that the write destination is a child stamp; when the operation result a[ 1 ], a[ 0 ] is 0, 1, this means that the write destination is a grandchild stamp; and when the operation result a[ 1 ], a[ 0 ] is 0, 0, this means that the write destination is a great-grandchild stamp.  
         [0152]    [0152]FIG. 28 shows an example in which a chunk is composed in the form of a block similarly to the above description. In FIG. 28, one chunk is composed of 4×4=16 pixels. Hence, FIG. 28 shows eight chunks. If a chunk is composed of pixels which are located adjacent to each other in a rectangular shape, an operation between adjacent pixels is facilitated.  
         [0153]    [0153]FIG. 29 shows an example in which a chunk is composed in the form of interleave. In FIG. 29, one unit is composed of 8×8=64 pixels. Pixels located in “1” in one unit are defined as one chunk; pixels located in “2” in one unit are defined as one chunk; pixels located in “3” in one unit are defined as one chunk; and pixels located in “4” in one unit are defined as one chunk. Namely, a chunk is defined as a set of pixels located apart from each other.  
         [0154]    Assuming that four pixel processors  20  exist here, the four pixel processors can process four chunks discretely. Namely, according to an aspect in FIG. 29, load distribution among the pixel processors  20  becomes easy.  
         [0155]    This embodiment is used for a real-time three-dimensional graphics system such as a game machine shown in FIG. 30. A controller  1 , a DVD drive  2 , a hard disk drive  3 , and a communication unit  4  are connected to a low-speed bus, and an image rendering device  8  is also connected thereto via a bus bridge  5 . An external memory  21  and a CPU  6  are connected to the image rendering device  8 .  
         [0156]    Application software for a game or the like is stored in a medium (DVD) which is set in the DVD drive  2 . This application software is executed by means of a CPU memory  7  by the CPU  6 , and three-dimensional spatial data is updated by the performance of various kinds of processing in response to user manipulation inputted from the controller  1 . Consequently, polygon data is transmitted from the CPU 6  to the image rendering device  8 , and image rendering such as described above is performed.  
         [0157]    Specifically, the CPU  6  acquires vertex data to render objects from the CPU memory  7 , and the CPU  6  performs the geometry processing. The result of the geometry processing is transferred to the image rendering device  8 . The image rendering device  8  performs the rasterization processing thereto, transmits a completion notice to the CPU  6  when the rasterization processing is competed and waits for the next data from the CPU 6 . By repeating such processing, the rendering processing is executed.  
         [0158]    Vertex data includes various information such as coordinates of vertexes, colors, texture data, normal vectors and so on, and then the CPU  6  executes necessary operation.  
         [0159]    Image data as a rendering result outputted from the image rendering device  8  becomes a video signal output through a D/A converter  9 , and it is transmitted to a display not shown and displayed. The display may be a dedicated display, or may be a display of a TV set, a computer, or the like. A viewing area on a display is called a screen.  
         [0160]    [0160]FIG. 31 is a diagram showing an example of the image rendering device  8  according to this embodiment by means of a block. The configuration of the image rendering device  8  may be any one of FIG. 4, FIG. 5, FIG. 6, and FIG. 7. Data on a polygon is inputted to the rasterizer  10  of the image rendering device  8  from a geometry processing unit  310 . The geometry processing unit  310  may be the CPU  6 . In the example in FIG. 31, the memory  30  is provided inside the image rendering device  8 .  
         [0161]    [0161]FIG. 32 shows a modification of the image rendering device  8 , and the memory  30  is provided outside the image rendering device  8 . Namely, the memory  30  may be provided inside or outside the image rendering device  8 .  
         [0162]    As described above, according to this embodiment, the process in which the pixel processor  20  determines whether to be a pixel position being processed at present or not can be omitted by guaranteeing that each pixel data is in a different pixel position.  
         [0163]    Moreover, by integrating pixel data located adjacent to each other in a rectangular shape as a chunk, locality can be improved, and the efficiency of reading texture data and the like can be improved.  
         [0164]    Further, by collectively processing pixel data located apart from each other as a chunk, load distribution among the pixel processors  20  can be facilitated.  
         [0165]    Furthermore, the pixel processor  20  can acquire chunk data in sequence from the chunk data buffer  110  and process it in sequence. In particular, since plural pixel processors  20  are provided, the plural pixel processors  20  can respectively process chunk data, whereby the activity ratio of the pixel processor  20  can be increased.  
         [0166]    In addition, the chunk merge unit  100  merges plural chunks whose pixel data do not conflict with each other into one chunk, and hence the number of chunks processed by the pixel processor  20  can be reduced.  
         [0167]    Besides, the concept of a “stamp” composed of pixel data of two or more pixels square is introduced, and the processing of merging chunks is performed on a stamp-by-stamp basis, whereby a neighborhood calculation becomes possible. For example, a first derivative value can be found from a difference from neighborhood pixel data.  
         [0168]    Moreover, since plural chunk data buffers  110  are provided, even when the processing of some polygon gets out of the region of one chunk data buffer  110 , chunk data can be held until the processing of another polygon enters again the region of the chunk data buffer  110 .  
         [0169]    Further, if the coordinate position of a chunk stored in the chunk data buffer  110  is fixed, wiring from the chunk data buffer  110  to the pixel processor  20  can be reduced.  
         [0170]    Furthermore, if a depth test is performed by the chunk data buffer  110 , the pixel processor  20  can not process a pixel which finally becomes a hidden surface.