Primitive Processing in a Graphics Processing System

In a 3D graphics processing system, objects of a scene are represented with groups of primitives, which are typically projected, scan converted, textured, and shaded during rendering of the scene. A primitive has a simple geometric shape, often a triangle, defined by the positions of one or more vertices (e.g. three vertices in the case that the primitive is a triangle) to which a texture can be applied. The rendering of a 3D scene processes the primitives to form an image comprising an array of image pixels. One step in the rendering process is to determine, for each of a plurality of sample positions of the image, which of the primitives is/are visible. This process is called hidden surface removal (HSR). Primitives, or parts of primitives, which are hidden by other primitives do not need to be considered further in the render. In order to perform HSR, the depths (i.e. the distances from the viewpoint) of primitives in the scene for each sample position are considered in order to determine which primitives are visible at each pixel position. Primitives may be opaque or translucent. A rendering technique in which textures are used to create holes in otherwise opaque primitives is known as “punch through”. For opaque primitives, the final rendered pixel value at a pixel position (which may correspond to one or more of the sample positions) will usually be given by the textured primitive which has the smallest depth value at that pixel position. For translucent primitives the final rendered pixel value at a pixel position may be given by a blend of more than one of the textured primitives which have the smallest depth values at that pixel position. When a scene contains primitives whose textures include punch through, the final rendered pixel value at a pixel position may be determined by primitives other than the primitive with the smallest depth value at that pixel position.

1 FIG. 100 102 104 106 108 110 102 104 102 102 104 102 104 104 106 102 shows a graphics processing systemcomprising a processing modulewhich may be referred to as an Image Synthesis Processor (ISP), a depth bufferwhich may be referred to as a Z-buffer, a tag sorter module, a texturing and shading enginewhich may be referred to as a Unified Shading Cluster (USC), and a pixel buffer. In operation, primitives (e.g. vertex coordinates and primitive identifiers) are received at the ISP, and the ISP performs HSR on the primitives to determine which primitives are visible at each of a plurality of sample positions of the image to be rendered. In order to implement the HSR for a typical render, the ISP is programmed to store in depth buffer, for each sample position, a depth value representing the depth of the closest primitive which has been processed so far by the ISP, such that the ISPcan compare the depth of a primitive currently being processed with the depth values stored in the depth bufferto determine whether the current primitive is visible. The results of the HSR performed by the ISPare used to update the depth values stored in the depth bufferaccordingly. It is noted that in some Systems, the depth bufferand tag sorter modulemay be described as components of the ISP.

106 102 106 108 108 106 108 108 102 108 The tag sorter modulecomprises a tag buffer which is configured to store, for each sample position, a primitive identifier (ID) of a visible primitive at that sample position as determined by the HSR performed by the ISP. The tag sorter modulealso comprises a controller to control the updating and flushing of the tag buffer. Primitive identifiers are flushed to the USC. In response to receiving the flushed primitive identifiers, the USCwill retrieve the identified primitives and will retrieve texture data in order to apply texturing and shading to the primitives identified by the flushed primitive IDs. The controller in the tag sorter modulecontrols when primitive identifiers are flushed to the USC. For example, primitive identifiers may be flushed to the USCwhen the primitives for the image have all been processed by the ISP. Primitive identifiers may also be flushed to the USCwhen primitive identifiers of translucent primitives, or primitives with texturing that includes punch through, are to be stored in the tag buffer. This is so that these primitives can be properly blended.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

There is provided a graphics processing system having a rendering space sub-divided into tiles, the graphics processing system comprising: a plurality of depth buffers, each of the depth buffers being configured to be dynamically associated with one tile at a time and configured to store a depth value for each sample position within the tile; and a processing module configured to receive primitives and tiling data, wherein for each primitive the tiling data indicates one or more tiles in which that primitive will be processed, and wherein the processing module is configured to perform hidden surface removal for a primitive of a tile by comparing depth values for that primitive with depth values stored in the depth buffer associated with the tile while another one of the depth buffers stores depth values for a different partially processed tile.

There is also provided a method of processing primitives in a graphics processing system having a rendering space sub-divided into tiles, the method comprising: storing depth values in a plurality of depth buffers, each of the depth buffers being dynamically associated with one tile at a time and being configured to store a depth value for each sample position within the tile; receiving primitives and tiling data at a processing module, wherein for each primitive the tiling data indicates one or more tiles in which that primitive will be processed; and performing hidden surface removal at the processing module for a primitive of a tile by comparing depth values for that primitive with depth values stored in the depth buffer associated with the tile while another one of the depth buffers stores depth values for a different partially processed tile.

There is also provided computer readable code adapted to perform the steps of any of the methods of the examples described herein when the code is run on a computer. Furthermore, there may be provided computer readable code for generating any of the graphics processing systems of the examples described herein. The computer readable code may be encoded on a computer readable storage medium.

The above features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the examples described herein.

The skilled person will appreciate that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the drawings represent one example of the boundaries. It may be that in some examples, one element may be designed as multiple elements or that multiple elements may be designed as one element. Common reference numerals are used throughout the figures, where appropriate, to indicate similar features.

100 102 108 The graphics processing systemdescribed in the background section above is efficient because hidden surface removal is performed in the ISP, and only visible surfaces are sent for texturing and shading at the USC. Systems that perform texturing and shading before hidden surface removal may be less efficient because the work done in texturing and shading an object is wasted if that object is later hidden by other objects in the scene.

1 FIG. 106 102 108 106 108 108 The system ofis most efficient when processing only opaque primitives, when hidden surface removal may be completed for a whole scene, or part of a scene, before texturing and shading begins. The primitive IDs of the opaque objects are collected by the tag sorter, such that when every opaque primitive has been processed by the ISP, the tag buffer stores an identifier for the primitive visible at each sample position. The tag buffer may then be flushed, sending the primitive IDs to the USCsuch that the corresponding identified primitives may be textured and shaded. The tag sorteris so-called because primitive IDs may be grouped, or sorted, as they are flushed from the buffer, such that, wherever possible, the USCis able to process IDs from a single primitive, or from primitives with similar texturing and shading requirements, as a group. Sorting the primitive IDs may therefore lead to improved cache performance in the USC. When a scene consists only of opaque primitives, the tag buffer need only be flushed once.

1 FIG. The system ofencounters problems in some situations, such as when a scene contains translucent or punch through primitives.

102 110 Translucency means that light is able to pass through objects. When rendering translucent objects it is no longer sufficient to render only the primitives with the smallest depth value, since it may be necessary to see through those primitives to the primitives behind. The colour of a pixel in the rendered image may be formed by blending the colour of a translucent primitive with the colour of one or more other primitives. Typically, the rendered image is built up by blending layers of translucent objects, starting with the primitives with the greatest depth value, and ending with the primitives with the smallest depth value. Not all rendering systems are capable of sorting translucent objects, so it is often left to the software application (e.g. a game) to present the primitives pre-sorted into a back to front order. In one example of translucency processing, translucent primitives are processed in the ISP(for example to determine if they are hidden behind existing opaque objects at any sample positions), and the tag buffer is flushed after each translucent primitive, such that the primitive can be textured and shaded, and blended with previously textured and shaded primitives in pixel buffer. If the application sends further opaque primitives after the translucent primitives, the results of the blending may be hidden.

102 104 108 102 104 106 104 108 108 102 102 104 108 110 1 FIG. 1 FIG. 1 FIG. Punch through refers to a rendering technique where a texture may be used to add holes to otherwise opaque primitives. Holes in a primitive should not result in the ISPupdating depth buffer, but the system ofonly evaluates the textures, and therefore determines where the holes are, in the USC. The system ofmust therefore take some additional steps to render punch through objects. In an example of punch through processing, a punch through primitive arriving at ISPis sampled, and may be tested against depth bufferto determine any parts that are hidden behind existing opaque objects. Any parts of the punch through object that are not hidden are sent to the tag sorter, but depth bufferis not updated. The tag buffer is flushed immediately, which may involve flushing any existing contents of the tag buffer, then sending the punch through primitive to the USC. The USCperforms at least the texturing and shading operations required to determine whether any parts of the primitive have holes, and returns the opaque parts to the ISPthrough the path labelled “PT Feedback” that is shown with a dotted line in. The ISPperforms another depth test, since the state of depth buffermay have changed in the time taken to texture and shade the punch through primitive, and any parts of the primitive that remain visible are stored as primitive IDs in the tag buffer. When the primitive ID is eventually flushed to the USCfor the second time, the remainder of the texturing and shading is performed, and image pixels are stored in pixel buffer.

102 108 Flushing the primitive identifiers for translucent or punch through primitives as described above may be inefficient because some of the flushed primitive identifiers may relate to primitives which are subsequently hidden by other primitives that the ISPis yet to process. Furthermore, flushing primitive identifiers whenever translucent primitives or primitives with punch through textures are processed may result in many flushes being performed (e.g. with each flush including a small number of primitive identifiers). It is often less efficient to perform lots of small flushes compared to performing fewer larger flushes of primitive identifiers to the USC.

102 100 102 104 102 106 102 100 1 FIG. 1 FIG. Furthermore, in a graphics processing system in which a rendering space is subdivided into a plurality of regions, or “tiles”, which are processed independently, the ISPprocesses primitives for a tile at a time in the graphics processing Systemshown in. When the ISPhas processed the primitives for one tile (e.g. by performing HSR for the primitives of the tile) it can then start to process the primitives of a next tile. The depth bufferstores depth values for each sample position within a tile that the ISPis currently processing; and the tag buffer in the tag sorter modulestores primitive identifiers for each sample position within the tile that the ISPis currently processing. The graphics processing systemshown inis therefore constrained to processing primitives for tiles, a tile at a time, such that all of the primitives of a tile are processed before primitives of the next tile are processed. That is, the tiles are processed in a serial manner, i.e. in sequence.

Embodiments will now be described by way of example only.

2 FIG. 2 FIG. 2 FIG. 2 FIG. 2 FIG. 202 202 200 200 204 1 4 As indicated above, a graphics processing system may have a rendering space which is subdivided into a plurality of tiles, which are processed independently.shows four tilestoof a rendering spacewhich is used for rendering an image. The rendering spacemay include more than four tiles (or fewer than four tiles), but for clarity only four tiles are shown in. As indicated in, each of the tiles in this example has a size of 32×32 sample positions. A sample position represents a position of the rendered image, and may or may not correspond to the actual pixel positions of the final image, whereby the pixel positions are the positions for which pixel values are determined and stored in a pixel buffer for representing an image. The primitives are sampled at each sample position to create “fragments” which are then processed, for example by hidden surface removal, texturing, and shading, in the rest of the rendering system. In some examples there may be more sample positions than pixel positions which allows the processing of the primitives to be performed at a finer granularity than the granularity of the pixels of the final image. This can be useful for using anti-aliasing techniques to reduce the appearance of jagged edges in the rendered image. As shown in, each tile is further subdivided into microtileswhich in this example have a size of 4×4 sample positions. The use of the microtiles is explained further in the examples described below. It is noted that in other examples the tiles and microtiles may have different sizes and/or shapes to those in the example shown in.

3 FIG. 3 FIG. 3 FIG. 300 300 300 302 304 306 308 310 316 312 312 314 314 304 318 318 306 320 320 322 308 324 324 300 1 4 1 4 1 4 1 4 shows a graphics processing systemwhich is configured to allow the processing of primitives to switch between primitives of different tiles before all of the primitives of a particular tile have finished being processed. In this sense the graphics processing systemcan have “multiple tiles in flight”, i.e. multiple tiles for which the primitives are partially processed at a given time. In order to achieve this the graphics processing systemcomprises a processing module, a depth buffer block, a tag sorter module, a texturing unit, a pixel buffer, and a control module. This example also includes a block of queues. In the example shown in, the block of queuescomprises four queuesto; the depth buffer blockcomprises four depth buffersto; the tag sorter modulecomprises four tag bufferstoand a tag control module; and the texturing unitcomprises four texturing enginesto. The elements of the graphics processing systemshown inmay be implemented in hardware, software or a combination thereof.

300 312 300 300 300 202 314 314 314 300 312 302 4 FIG. 3 FIG. 3 FIG. 1 4 The operation of the graphics processing systemis described with reference to the flow chart shown in. Primitives of different tiles are received at the block of queuesof the graphics processing system. The primitives may relate to objects of a scene to be rendered, and may for example be sent to the graphics processing systemfrom an application (e.g. a game) running on the same device (e.g. a mobile user device) as the graphics processing system. The primitives are associated with tiling data which indicates one or more tilesin which the primitives will be processed. The tiling data may have been determined in a previous operation of determining which tiles the primitives are present in, which is not described in detail herein. Each of the primitives is described by primitive data which includes an indication of the positions of the vertices of the primitive, and may include other information such as an indication of a texture to be applied to the primitive. Each of the queuestois configured to store the primitives for a respective tile at a time. In the examples described herein, the tiling data indicates which tile each primitive is for. In the examples described above, since a queue is associated with a tile at a time, the tiling data associated with the primitives does not need to be, and is not, stored in the queues to indicate which tile each primitive is for. However, in some other examples, the tiling data may be stored in the queues with the primitives. The queuesmay for example be implemented as First In First Out (FIFO) buffers. The graphics processing systemshown incan have up to four tiles in flight at a given time. In some examples there may be a different number of queues in the block, and in some examples there might not be any queues and the primitives and tiling data may be received directly at the processing modulewithout first storing the primitives and tiling data in any queues as shown in.

402 302 302 In step Sthe processing modulereceives primitives and the associated tiling data. The tiling data identifies the tile or tiles in which the primitive will be processed, and should identify at least one of the tiles to which the resources (e.g. the depth and tag buffers) of the processing moduleare currently assigned.

3 FIG. 302 314 314 314 314 1 4 1 4 In the example shown inthe primitives and tiling data are received at the processing modulefrom one of the queuesto. Since each of the queuestois configured to store the primitives for a respective tile at a time, the tiling data may simply comprise the identity of the queue from which the primitive is received.

404 302 318 318 318 318 1 4 1 4 In step Sthe processing moduleperforms hidden surface removal (HSR) for a primitive of a tile by comparing depth values for that primitive with depth values stored in the depth buffer associated with the tile. Each of the depth bufferstois configured to be associated with one tile at a time and configured to store a depth value for each sample position within the respective associated tile. For example, the four depth bufferstomay be associated with four tiles (tile A to tile D) respectively. The four tiles with which the depth buffers are associated may be selected from any position on the rendering surface. There is no requirement that the tiles be adjacent to each other. In some examples, tiles may be selected from positions in more than one rendering surface.

302 318 The HSR performed by the processing modulefor a primitive comprises determining which sample positions lie within the primitives (based on the vertex positions of the primitives), and performing depth tests at these sample positions based on the depth values stored in the relevant depth buffer.

404 302 318 As part of step Sthe processing modulemay update one or more of the depth values stored in the depth bufferassociated with the tile that is currently being processed.

302 300 318 318 302 318 302 302 300 100 102 102 302 300 102 100 324 1 4 The processing modulehas a processing unit which operates on one primitive at a time. However, since the graphics processing systemcomprises a plurality of depth buffersto, it is able to switch between processing primitives from different tiles before finishing the processing of all of the primitives within a tile. That is, the processing modulecan perform HSR for a primitive of a tile while another one of the depth buffersstores depth values for a partially processed tile. The partially processed tile in this case is a different tile to the tile for which a primitive is currently being processed by the processing module. This allows greater flexibility in the order in which the primitives are processed by the processing module, which can lead to more efficient processing of the primitives by the graphics processing systemcompared to the processing performed by the graphics processing systemin which all of the primitives of one tile are processed by the processing modulebefore any of the primitives of the next tile are processed by the processing module. For example, if the processing of a tile stalls for some reason that is specific to the tile being processed, then the processing moduleof the graphics processing systemcan continue to process primitives from other tiles, whereas the processing moduleof the graphics processing systemmay be stalled until the processing can resume for the stalled tile. Furthermore, as described below, multiple texturing enginescan be implemented, to increase the texturing and shading capability of the system. In previous systems a processing unit with a single depth buffer has been coupled to multiple texturing engines. It was therefore necessary to devise a system to supply fragments to each texturing engine, in such a way that the loading of the texturing engines is kept reasonably well balanced, and so that the efficiency of caches, etc., is maintained. In practice this is difficult to achieve.

324 324 In the present system, where there are multiple tiles in flight, it can be efficient to use the same texturing enginefor applying texturing to all of the visible primitives within a particular tile. That is, each texturing enginecan be associated with a respective tile.

324 324 324 324 This association can be beneficial because each primitive in a tile causes texturing data for that primitive to be loaded into the local caches of the texturing engine. By processing a primitive's fragments in a single texturing engine, the primitive's texturing data is loaded only into the caches of that texturing engine. In contrast, if the primitive's fragments were distributed to several texturing engines, the same texturing data would be duplicated in several caches. By avoiding duplication of data, the efficiency of the caches is improved. The arrangement is also beneficial in that the loading of the texturing enginescan be more easily balanced, for example by associating each texturing enginewith a different one of the multiple tiles in flight, rather than by attempting to evenly distribute the fragments from one tile to several texturing engines. Load balancing is described in more detail below.

406 404 320 320 320 306 318 320 320 320 320 320 3 FIG. 3 FIG. 6 8 FIGS.and 1 4 1 4 In step Sprimitive identifiers for the fragments which survive the hidden surface removal of step Sare stored in the tag buffers, such that, after each primitive has been processed, the tag buffers contain the identity of the primitive that is visible at each sample location. In the example shown in, there are four tag buffers (to) in the tag sorter module, which is the same as the number of depth buffers, such that each of the tag bufferstois dynamically associated with a respective particular tile. That is, each of the tag buffersstores the primitive identifiers identifying the primitives determined by the HSR to be visible at each sample position within a respective tile. In general, for each of the tiles that may be “in flight” there is an associated set of at least one tag bufferconfigured to store the primitive identifiers for the visible primitives of that tile. In the example shown inall of the “sets of tag buffers” which are associated with particular tiles include just one tag buffer, but as is described in more detail below with reference tothese sets may include more than one tag buffer.

322 306 320 306 302 322 320 320 308 306 9 1 4 5 a FIGS. b. The tag control moduleof the tag sorter modulecontrols the selection of one of the tag buffersfor storage of each of the primitive identifiers received at the tag sorter moduleas the output of the HSR performed by the processing module. The tag control modulealso controls the flushing of primitive identifiers from the tag buffersto. The flushed primitive identifiers are passed to the texturing unit. The operation of the tag sorter moduleis described below in more detail in relation toto

408 324 324 324 324 324 324 318 308 320 324 324 1 4 1 4 3 FIG. In step Sone of the texturing enginestoapplies texturing and shading to the primitives identified by the flushed primitive identifiers. A texturing engineretrieves texture data and the identified primitives (e.g. from a memory) and applies the texture data to the primitives identified by the flushed primitive identifiers. In the example shown inthere are four texturing enginesto, i.e. there are the same number of texturing enginesas there are depth buffers. In this case each of the texturing engines is associated with a respective tile such that all of the texturing that is applied to the primitives of a particular tile is performed by the same texturing engine. That is, the primitive identifiers in the tag buffer(s)associated with a particular tile are all sent to the same ones of the texturing engines, such that all of the texturing that is applied to the visible primitives of the particular tile is applied by the same texturing engine. As described above, this may improve the efficiency of texturing the primitives in the case that there are multiple tiles in flight. Methods for applying texturing to primitives are known in the art, and as such the texturing process is not described in great detail herein.

308 308 308 310 310 The result of applying the texturing to the primitives at the texturing unitis a set of pixel values for the image. The texturing unitmay comprise some logic for converting sample values to pixel values where the samples do not exactly correspond to the pixels (e.g. where there are more samples than pixels). The pixel values are output from the texturing unitand stored in the pixel buffer. The pixel bufferstores the pixel values of the image which can then be used in any suitable manner, e.g. output to a display or stored in a memory or transmitted to another device, etc.

316 302 302 302 316 312 314 316 302 314 302 316 314 302 302 316 300 314 316 300 316 302 3 FIG. The control modulecontrols which primitives are processed by the processing moduleto thereby control the switching of the processing modulebetween processing primitives for different tiles. In order to control the switching of the processing module, the control modulemay send a control signal to the block of queues, thereby selecting one of the queues. Alternatively, the control modulemay send a control signal to the processing moduleindicating which of the queuesthe processing moduleshould read from. The control modulemay manage the flow control in different ways and the two methods suggested above are given by way of example only. A primitive from the selected queueis sent to the processing module. The primitive's associated tiling data is also sent to the processing module, such that the primitive can be processed as described above. As shown in, the control modulemay receive state information which describes the state of the graphics processing system. The selection of the one of the queuesby the control modulemay be based on the state information. The state information may be any suitable information relating to the state of the graphics processing systemwhich may be useful for the control modulein determining whether to switch the processing of the processing modulein order to process primitives of a different tile.

316 308 324 316 324 324 324 316 320 324 320 324 316 302 For example, the control modulemay receive state information from the texturing unitindicating that one of the texturing enginesis idle or is about to become idle. In this case, the control modulemay prioritise the processing of primitives for the tile currently associated with the indicated texturing engine. This is useful in order to balance the processing load across the different texturing engines, e.g. thereby avoiding, if appropriate, a situation in which one of the texturing enginesis not being utilised to the greatest extent possible. In one example the state information received by control modulecomprises information about the state of buffers (e.g. FIFOs) at the interfaces between tag buffersand texturing engines. A tag buffermay flush many primitive identifiers at one time, and a texturing enginemay process them one at a time, or in small groups. The texturing engines may therefore buffer a number of primitive identifiers until they can be scheduled for execution by the texturing engine. When the number of buffered primitive identifiers falls to zero the texturing engine has no more work to do, and becomes idle. Control modulemay prioritise the processing of primitives in an attempt to ensure that the buffers never, or rarely, become empty. “Prioritising” the processing of primitives for a tile may mean increasing the frequency with which the primitives for that tile are selected to be processed by the processing module, or, as described below, preferentially selecting a tag buffer associated with that tile, when it is necessary to perform a flush.

316 316 314 As another example, the control modulemay receive state information, e.g. from the tiling process, indicating that there is a large quantity of data (e.g. many layers of primitives) to process in a tile. In this case, the control modulemay be configured to prioritise the processing of primitives for the tile by ensuring that a queueis assigned to that tile at an early opportunity. By doing this, the system ensures that other tiles are able to be processed simultaneously, thereby increasing the utilisation of the texturing engines.

316 308 306 316 302 As another example, the control modulemay receive state information, e.g. from the texturing unitor the tag sorter module, indicating that the processing of a tile has stalled, e.g. because it is waiting for a response to a memory access request to an off-chip memory. In this case, the control moduleis configured to deprioritise the processing of primitives for the stalled tile. “Deprioritising” the processing of primitives for a tile may mean reducing the frequency with which the primitives for that tile are selected to be processed by the processing module. The state information may include more than one of the indications described above and in this case the effects of the different prioritisations/deprioritisations can be combined in order to determine which of the tiles should be selected.

316 302 314 302 302 314 Other example graphics processing systems might not include a control module, and the selection of which of the primitives should be processed by the processing modulemay be determined in a different manner. For example, one of the queuescould be selected periodically at random to provide a primitive to the processing modulewhen the processing moduleis ready to receive a new primitive. Alternatively, the queuescould each be selected in turn in some pattern, e.g. according to a round robin scheme.

300 302 318 318 It can therefore be appreciated that the graphics processing systemallows multiple tiles to be “in flight” wherein the processing modulecan perform HSR for primitives for one tile using one of the depth bufferswhile depth values for a different, partially processed tile are stored in a different one of the depth buffers.

5 a FIG. 5 a FIG. 5 a FIG. 5 a FIG. 500 502 500 502 504 506 504 500 506 500 500 502 504 506 508 508 510 There can be a situation in which many primitives are present at a particular sample position within a tile, such that the primitives are overlapping. An example of such a situation is shown inwhich, for clarity, shows a small tile, which is divided into an 8×8 grid. In this example, each grid square corresponds to a screen pixel and has a sample position, typically at its centre. As described above, different tile configurations and sampling patterns are possible.shows that there is a primitivewhich covers the whole of the tile, and may for example represent a background in the image. In front of the primitive(i.e. closer to the viewpoint, and therefore represented, in this example, by smaller “depth” values) there are two further primitivesandwhich do not overlap with each other. It can be seen inthat the primitivedoes not extend outside of the tile, whereas the primitiveextends outside the tile, e.g. into another tile (not shown in) which is positioned below the tile. In front of the primitives,andis another primitive. Further, in front of the primitiveis a further primitive. If the primitives are completely opaque then the final sample values will be determined by the closest primitive at each of the sample positions. If some of the primitives are not fully opaque (e.g. they have some translucency or have textures which include punch through) then the final sample values may be determined by a blend of more than one of the primitives at the sample positions.

6 FIG. 6 FIG. 6 FIG. 600 600 602 604 606 608 610 606 620 620 622 600 1 3 As described above, if just one tag buffer is used to store primitive identifiers for primitives within a tile then when hidden surface removal is performed for a primitive which is not fully opaque then the primitive identifiers that are already in the tag buffer will be flushed to allow the newly processed primitive identifier to be stored in the tag buffer. This results in a large number of separate flushing operations, which may be less efficient than performing fewer, but larger flushing operations which provides greater opportunity for opaque primitives to hide previously processed primitives, thereby avoiding unnecessary further processing being performed on the previously processed primitives which will ultimately be hidden in the final image.shows a graphics processing systemwhich can reduce the number of separate flushing operations that are performed. The graphics processing systemcomprises a processing module, a depth buffer, a tag sorter module, a texturing engineand a pixel buffer. In the example shown in, the tag sorter modulecomprises three tag bufferstoand a tag control module. The elements of the graphics processing systemshown inmay be implemented in hardware, software or a combination thereof.

600 702 602 600 600 500 602 600 606 7 FIG. 3 FIG. 6 FIG. The operation of the graphics processing systemis described with reference to the flow chart shown in. In step Sthe processing modulereceives primitives which may relate to objects of a scene to be rendered, and may for example be sent to the graphics processing systemfrom an application (e.g. a game) running on the same device (e.g. a mobile user device) as the graphics processing system. In this example the primitives relate to a single tile (e.g. tile) in which the primitives will be processed. Unlike the system of, the system ofdoes not support “multiple tiles in flight”. It is therefore not necessary for the processing moduleto receive tiling data indicating which one of several tiles the primitive should be processed in. Although the graphics processing systemis described as having a rendering space which is subdivided into a plurality of tiles, it is noted that the use of multiple tag buffers to allow for the storage of overlapping layers of primitive identifiers in the tag sorter modulecan be used in other examples which may not have a rendering space which is divided into multiple tiles, i.e. which have only one tile.

704 602 500 604 602 604 500 704 602 604 In step Sthe processing moduleperforms hidden surface removal (HSR) for a primitive of the tileby comparing depth values for that primitive with depth values stored in the depth buffer. The HSR performed by the processing modulefor a primitive may for example comprise determining which sample positions lie within the primitives (based on the vertex positions of the primitives), and performing depth tests at these sample positions based on the depth values stored in the depth buffer. In this way, the HSR determines primitive identifiers identifying the primitives which are visible at each of the sample positions in the tile. As part of step Sthe processing modulemay update one or more of the depth values stored in the depth buffer.

620 620 620 1 3 The three tag bufferstoform a set of tag buffers which are configured to store primitive identifiers for each of the sample positions in the tile, whereby primitive identifiers stored at corresponding sample positions in the tag buffersof the set represent overlapping layers of primitives.

706 622 620 602 620 620 602 In step Sthe tag control moduleselects one of the tag buffersfor the storage of each of the primitive identifiers output from the processing modulewhich identify primitives which are determined to be visible by the hidden surface removal. In one example a tag bufferis selected independently for each sample position at which the primitive is determined to be visible according to the primitive identifiers already stored in the tag buffersat each sample position. In another example, processing moduleperforms hidden surface removal for a primitive at each sample position in a microtile. A microtile is a group of sample positions, typically 4×4, for which hidden surface removal for a primitive may be performed in parallel. In this case it may be appropriate to select one tag buffer to store all the primitive identifiers for the fragments of a primitive determined to be visible in the microtile. In a third example, one tag buffer is selected to store the primitive identifiers for all the fragments of a primitive determined to be visible in the tile, whilst another tag buffer may be selected to store the primitive identifiers for all the fragments of another primitive determined to be visible in the tile. Therefore, in the third example, the selection of a tag buffer for storing the primitive identifiers of a primitive is performed at the scale of whole tiles, rather than at the scale of microtiles or at the scale of individual samples.

708 In step Sthe primitive identifiers for the fragments which are determined to be visible by the HSR for each of the sample positions are stored in the corresponding selected tag buffer(s).

5 5 a b FIGS.and 5 a FIG. 5 b FIG. 5 a FIG. 5 b FIG. 5 b FIG. 512 502 500 504 506 508 510 514 620 514 620 514 620 514 514 512 502 510 512 514 620 514 620 514 620 620 1 1 2 2 3 3 1 3 1 1 2 2 3 3 illustrate the example in which a tag buffer is selected independently for each sample position. With reference to, one of the columns of sample positions is indicated by the arrow. As an example, the primitiveis opaque, whereas the other primitives in the tile(primitives,,and) are all translucent.shows a columnof tag buffer, a columnof tag bufferand a columnof tag buffer. Each of the columnstoare configured to store primitive identifiers for the primitives shown in the columnshown in. It can be appreciated that the primitivestooverlap at some of the sample positions within the column.shows the viewpoint on the left of the figure, such that it can be seen that in the example shown in, for each sample position, the columnof the tag bufferis configured to store primitive identifiers for primitives which are further away than overlapping primitives for which the columnof the tag bufferis configured to store primitive identifiers, which themselves are further away than overlapping primitives for which the columnof the tag bufferis configured to store primitive identifiers. In this way, the tag buffersrepresent overlapping layers of primitives at different sample positions.

502 606 502 500 502 502 502 620 622 620 620 502 514 620 606 504 620 504 620 504 504 514 620 5 a FIG. 5 b FIG. 5 b FIG. 1 1 1 1 1 2 2 2 In an example, the primitive identifier for the primitiveis received at the tag sorter modulebefore the primitive identifiers for the other primitives shown in. The primitiveis opaque and covers all of the sample positions of tile. As such it will hide any primitives which may have previously been received for the tilewhich are further away, e.g. which have larger depth values, than the primitive(it is noted that in other examples the depth values may be defined such that primitives which are further away have smaller depth values). The primitive identifier for primitivecan therefore be stored in the tag bufferat all of the sample positions. Therefore the tag control moduleselects the tag buffer, which in this example is the one of the tag bufferswhich stores primitive identifiers for the furthest layer of the primitives. This is shown inin that the primitive identifiers are stored for the primitivein the columnof the tag buffer. The tag sorter modulemay then receive primitive identifiers for the next primitive(which is translucent) and it will determine that the tag bufferis full at the sample positions covered by the primitive, and will therefore select the next layer, i.e. buffer, to store the primitive identifiers for the primitive. This is shown inin that primitive identifiers are stored for the primitivein the columnof the tag buffer.

606 506 620 500 506 620 506 500 506 504 504 506 620 506 514 620 1 2 2 2 2 5 b FIG. The tag sorter modulemay then receive primitive identifiers for the next primitive(which is translucent) and it will determine that the tag bufferis full at the sample positions in the tilecovered by the primitive, and will therefore select the next layer, i.e. buffer, to store the primitive identifiers for the primitivewhich are in the tile. It is noted that the primitivedoes not overlap the primitiveand as such the primitive identifiers for the primitivesandcan be stored in the same tag buffer. This is shown inin that primitive identifiers are stored for the primitivein the columnof the tag buffer.

606 508 620 508 508 620 508 620 5082 514 620 508 508 514 620 620 622 620 1 2 2 2 2 1 3 3 3 2 5 b FIG. The tag sorter modulemay then receive primitive identifiers for the next primitive(which is translucent) and it will determine that the tag bufferis full at all of the sample positions covered by the primitive. For some of the sample positions of the primitivethe tag bufferis available but for some other sample positions of the primitivethe tag bufferis not available. In the example illustrated in, the primitive identifieris stored in columnof bufferat the locations where space is available. Primitive identifiersandare stored in columnof tag bufferat the locations where space in tag bufferis not available. That is, the tag control moduleselects the tag bufferfor storing primitive identifiers on a per-sample position basis.

606 510 512 620 620 620 510 510 710 620 622 620 620 608 620 620 510 620 1 2 3 5 b FIG. The tag sorter modulemay then receive primitive identifiers for the next primitive(which is translucent) and it will determine that, for the column, none of the tag buffers,andare available at the sample positions covered by the primitive. This is represented in. Therefore, in order to store the primitive identifiers for the primitivein a tag buffer, one of the tag buffers is flushed. That is, in step S, the primitive identifiers from one or more of the tag buffersare flushed. The tag control modulecontrols the flushing of the tag buffers. When primitive identifiers are flushed from a tag bufferthey are received at the texturing engine. The flushing of a tag bufferwill make that tag bufferavailable such that the primitive identifiers for the primitivecan then be stored in the available tag buffer.

622 620 500 512 502 514 514 514 620 620 620 514 502 530 532 500 532 514 512 5 c FIG. 5 a FIG. 5 d FIG. 1 2 3 1 2 3 1 In another example the tag control moduleselects a tag bufferfor storing all primitive identifiers of a primitive that relate to a particular microtile, such that for each of the microtiles, if all of the sample positions within that microtile are available in a layer then the primitive identifiers for the primitive are stored in the tag buffer corresponding to that layer. However, if it is not the case that all of the sample positions within a microtile are available in the layer then the primitive identifiers for the primitive are stored in the next layer.shows the same tile, column of sample positions, and opaque background primitiveas in.shows columns,, andof tag buffers,, andrespectively, with columncontaining primitive identifiers corresponding to primitive. Linesanddivide the tileinto four microtiles, each containing sixteen sample positions. Similarly, linedivides the columnsinto upper and lower parts corresponding to the two microtiles intersected by the column of sample positions.

606 520 620 502 622 620 520 520 514 620 1 2 2 2 5 d FIG. In this example, the tag sorter modulemay receive primitive identifiers for the primitive(which is translucent). Tag bufferalready contains primitive identifiers for opaque primitive, so tag control moduleselects tag bufferto store the primitive identifiers for primitive. This is shown inin that the primitive identifiers are stored for the primitivein the columnof the tag buffer.

606 522 522 522 514 620 620 522 522 514 620 620 706 620 706 620 1 2 2 2 2 3 3 2 The tag sorter modulemay then receive primitive identifiers for the next primitive(which is translucent). In this case a portionof the primitive identifiers for the primitiveare stored in the columnof the tag bufferbecause all of the sample positions within the relevant microtile are available in the tag buffer, whereas portionof the primitive identifiers for the primitiveare stored in the columnof the tag bufferbecause it is not the case that all of the sample positions within the relevant microtiles are available in the tag buffer. In general, for each microtile, the primitive identifiers of sample positions within the microtile are stored in the furthest layer represented by the tag buffers which is available for all of the sample positions within the microtile. That is, the selection in step Scomprises selecting the one of the tag buffersthat corresponds to the furthest available layer of the overlapping layers for a block of one or more sample positions (i.e. for a microtile). In other examples, for each microtile, the primitive identifiers of sample positions within the microtile are stored in the furthest layer represented by the tag buffers which is available for all of the sample positions covered by the primitive identifiers within the microtile. That is, the selection in step Smay comprise selecting the one of the tag buffersthat corresponds to the furthest available layer of the overlapping layers for the primitive identifiers within a block of one or more sample positions (i.e. for a microtile).

712 608 408 608 608 608 610 610 In step Sthe texturing engineapplies texturing and shading to the primitives identified by the flushed primitive identifiers. The texturing is performed in the corresponding way to that described above in relation to step S. That is, the texturing engineretrieves texture data and the identified primitives (e.g. from a memory) and applies the texture data to the primitives identified by the flushed primitive identifiers. As described above, the result of applying the texturing to the primitives at the texturing unitis a set of pixel values for the image. The pixel values are output from the texturing unitand stored in the pixel buffer. The pixel bufferstores the pixel values of the image which can then be used in any suitable manner, e.g. output to a display or stored in a memory or transmitted to another device, etc.

In the examples described in detail above, the selection of a tag buffer for the primitive identifiers is performed either for each individual sample position, or on the microtile scale, e.g. for a 4×4 block of sample positions corresponding to a microtile. However, in other examples, the selection of a tag buffer may be performed at other scales, e.g. for blocks of sample positions of different sizes and/or shapes. Choosing a larger scale may help to reduce occurrences of flushing primitives in multiple phases, which may occur when different portions of the primitive identifiers are stored in different layers. However, choosing a larger scale reduces the opportunities to fill in gaps within layers of the tag buffers. Therefore, there is a trade-off to consider when setting the scale of the blocks.

620 622 620 620 620 622 620 620 622 620 620 606 1 5 b FIG. 5 d FIG. When one of the tag buffersis to be flushed, the tag control moduledetermines which of the tag buffers to flush based on a flushing strategy. For example, the flushing strategy may be that the tag buffercontaining primitive identifiers of the furthest layer (e.g. tag bufferin the examples described above) is to be flushed before another tag bufferis flushed. As another example, the flushing strategy may be that the tag buffer containing the most primitive identifiers (i.e. the fullest tag buffer) is to be flushed before another tag buffer is flushed. The tag control modulemay control the flushing of the primitive identifiers from the tag bufferssuch that primitive identifiers from only one of the tag buffersare flushed at a time. Alternatively, the tag control modulemay control the flushing of the primitive identifiers from the tag bufferssuch that primitive identifiers from multiple tag buffersare flushed simultaneously. Where the correct behaviour of the rendering depends on the order in which primitives are rendered, the flushing strategy should be chosen so as to preserve this. Note that when primitive identifiers are stored in multiple tag buffers, as shown inand, the layering reflects the order in which primitive identifiers are received by the tag sorter module, rather than the depths of the primitives. Therefore the multiple tag buffers are capable of preserving order.

6 FIG. 620 shows an example of how the graphics processing system could be arranged, in which there are three tag buffers. In other examples there may be two or more than three tag buffers in the graphics processing system which could be configured to store primitive identifiers for different layers of primitives within a tile.

620 602 608 502 504 502 504 502 504 502 504 620 502 608 504 606 504 620 502 504 606 502 504 620 620 5 a FIG. 2 1 2 An advantage of using multiple tag buffersto represent overlapping layers of primitives is that sometimes primitive identifiers that are written to a tag buffer may identify primitives which are subsequently found to be hidden by other primitives by the HSR performed by the processing module. In that case, the use of multiple tag buffers can reduce the number of primitive identifiers which are flushed to the texturing engine. For example, if only one tag buffer was used in the example shown inthen the primitive identifiers for the primitivewould have been flushed to the texturing engine in response to the arrival of the primitive identifiers for the translucent primitive. If the next primitive to be processed was opaque and in front of the primitivesandthen primitivesandmay be wholly or partially hidden and as such the hidden parts of primitivesandwould not need to be textured. With the use of multiple tag buffers, the primitive identifiers for the primitivewould not be flushed to the texturing enginein response to the arrival of the primitive identifiers for the primitiveat the tag sorter module, because the primitive identifiers for the primitivecan be written into the second tag buffer. Therefore, no flushes have occurred when the primitive identifiers for the opaque primitive covering primitivesandis received at the tag sorter module. In that case primitive identifiers for the primitivesandcan be overwritten in the tag buffersandrespectively where they are not needed to be textured. In this way, the unnecessary texturing of fragments of primitives which are ultimately hidden by other primitives can be reduced.

The two ideas described above of allowing multiple tiles to be in flight at a given time with the use of multiple depth buffers, and allowing overlapping layers of primitive identifiers to be stored in multiple tag buffers can be combined to provide a very flexible graphics processing system.

8 FIG. 3 6 FIGS.and 8 FIG. 8 FIG. 800 300 600 800 300 800 312 314 314 302 304 318 318 308 324 324 310 300 800 1 4 1 4 1 4 shows a graphics processing systemwhich combines features of the graphics processing systemsanddescribed above and shown inrespectively. In particular, the graphics processing systemincludes some of the same elements as the graphics processing systemand these elements are shown inwith the same reference numerals. That is, the graphics processing systemincludes a block of queuescomprising four queuesto; a processing module; a blockof depth buffersto; a texturing unitcomprising four texturing enginestoand a pixel buffer. These elements operate as described above in relation to graphics processing system. All of the elements of the graphics processing systemshown inmay be implemented in hardware, software or a combination thereof.

800 816 316 300 800 806 306 300 806 822 820 820 820 318 820 600 820 800 822 318 820 800 1 8 As described in more detail below, the graphics processing systemincludes a control module, which is similar, but not identical to the control moduleof the graphics processing system. Furthermore, the graphics processing systemcomprises a tag sorter modulewhich is not the same as the tag sorter moduleof graphics processing system. The tag sorter modulecomprises a tag control moduleand eight tag buffersto. In this way, there are more tag buffersthan depth buffers, so more than one tag buffercan be used to store overlapping layers of primitive identifiers for primitives of a particular tile, as described above in relation to one tile with reference to graphics processing system. It can therefore be seen that there is a group of eight tag buffers, and the graphics processing system(in particular the tag control module) is configured to dynamically associate, with each of the depth buffers, a respective set of one or more of the eight tag buffers. The association of the tag buffers with the depth buffers (which corresponds to an association of the tag buffers with the tiles that are being processed) is performed dynamically in the sense that it can be altered to suit the current requirements of the graphics processing system.

820 806 822 820 820 For example, if none of the tag buffersof a set which is currently associated with a particular tile are available at a sample position when a primitive identifier of a primitive covering that sample position is received at the tag sorter module, then the tag control modulecan add an available tag bufferto the set of tag buffers that is associated with that tile. The additional tag bufferin the set represents a new layer of primitives for the tile, and the primitive identifier can be stored in the additional tag buffer representing the new layer.

820 820 822 820 820 1 8 1 8 If (in the same way as in the example given above) a primitive identifier is to be stored at a sample position to a tag buffer of the set of tag buffers associated with a particular tile, but none of the tag buffers of the set are available at the sample position, and if (unlike in the example given above) there are no available tag buffers in the group of tag buffers (to), then the tag control modulemay flush the primitive identifiers from one of the tag bufferstothereby making that tag buffer available such that the primitive identifier can be stored in the available tag buffer. The tag buffer selected for flushing may or may not be a tag buffer that is currently a member of the set of tag buffers associated with the tile. By flushing a tag buffer associated with one tile, and then re-associating the flushed tag buffer with a different tile, the tag buffer is moved to a different set.

820 820 822 820 There may be a predetermined maximum number of tag bufferswhich can be included in one of the sets of tag buffersassociated with a tile. For example, the tag control modulemight not associate more than four of the tag buffersto any given tile.

820 820 800 The distribution of objects within a scene is likely to be such that some tiles contain translucent objects, and some do not. Of those tiles that contain translucent objects, the complexity of the scene, i.e. the number of layers of translucency, may vary considerably. The flexibility in the association between tag buffersand tiles allows the tag buffersto be used to best suit the current needs of the graphics processing system.

300 308 324 324 324 324 324 324 318 308 308 310 324 318 1 4 1 4 8 FIG. As in the graphics processing systemdescribed above, the flushed primitive identifiers are passed to the texturing unit. One of the texturing enginestoapplies texturing and shading to the primitives identified by the flushed primitive identifiers. As described above, a texturing engineretrieves texture data and the identified primitives (e.g. from a memory) and applies the texture data to the primitives identified by the flushed primitive identifiers. In the example shown inthere are four texturing enginesto, i.e. there are the same number of texturing enginesas there are depth buffers, and in this case each of the texturing engines is associated with a respective tile such that all of the texturing that is applied to the primitives of a particular tile is performed by the same texturing engine. As described above, this may improve the efficiency of texturing the primitives in the case that there are multiple tiles in flight. As described above, the texturing unitoutputs a set of pixel values for the image which are then stored in the pixel buffer. In other examples, the number of texturing enginesmay be different to the number of depth buffersand in that case each of the texturing engines might not be associated with a respective tile.

816 316 300 816 302 302 820 820 820 816 312 820 800 816 302 As mentioned above the control moduleis similar to the control moduleof the graphics processing system. However, the control modulecan further control which primitives are processed by the processing moduleto thereby control the switching of the processing modulebetween processing primitives for different tiles, based on the number of tag buffersin the sets of tag bufferswhich are associated with the different tiles. For example, if there are lots of tag buffersassociated with a particular tile, the control modulemay control the block of queuesto prioritise the output of primitives for that tile. Having lots of tag buffersassociated with a tile may allow the graphics processing systemto process the primitives for that tile more efficiently and as such the control modulemay control the processing moduleto preferentially process primitives from that tile.

9 9 a b FIGS.and 822 show a flow chart for a method by which a tag control modulemay control the selection of tag buffers for storing incoming primitive identifiers of a tile and the flushing of tag buffers in an example.

904 906 908 908 908 910 822 910 912 910 914 910 918 920 922 914 916 904 926 9 b FIG. Initially, no tag buffers are associated with the tile. At stepa set of primitive IDs are received. These primitive IDs correspond to a single primitive, and to sample positions within the tile according to the positions at which the primitive has been determined to be visible. The primitive may be opaque or translucent. At stepa decision is made according to whether the primitive is opaque or translucent, and if the primitive is not translucent (i.e. if it is opaque), then at stepa clearing process occurs. Stepwill be described further below. In the initial case, where no tag buffers are allocated, stephas no effect. At stepthe tag control modulesearches for a tag buffer in which to store the primitive IDs. The process within blockis described in more detail below, and in. At step, the result of the search processis tested. If the search was successful and a tag buffer was found, the flow advances to step, and the primitive IDs are stored in the tag buffer that was found. However, in the initial case there are no tag buffers in the set associated with the tile, and so searchwill fail to find a suitable tag buffer. In this case the flow advances to a series of steps that will attempt to add a new tag buffer to the set associated with the tile. Steptests whether the set of tag buffers is already of a predetermined maximum size, and stepchecks to see whether there is an available buffer that is not currently associated with a tile. In the initial case, flow will proceed to stepin which a free tag buffer will be added to the set associated with the tile. The primitive IDs may then be stored in the tag buffer, in step. At stepa test is made to determine whether there are more primitives to be processed. Flow proceeds accordingly, either to step, in order to receive further primitive IDs, or to stepin which all the buffers are flushed (in order, from rear to front), and the process ends.

910 952 954 964 956 966 956 958 960 962 958 968 970 972 960 9 b FIG. 9 9 a b FIGS.and The sub-process of stepis shown in. Note that for simplicity of explanation,illustrate a system in which selection of a tag buffer for storing the primitive identifiers of a primitive is performed at the scale of whole tiles, rather than at the scale of microtiles or at the scale of individual samples. Examples in which a tag buffer is selected per-pixel, or per-microtile, may be implemented using straightforward modifications to the technique described here as will be apparent to a person skilled in the art. The process begins at, and ata test is made to determine whether the set of tag buffers allocated to the tile is empty. If the set is empty then atthe sub-process ends and reports that a buffer was not found. When the set contains at least one buffer, the processing differs depending on whether the primitive is opaque or translucent. This is tested at, and in the simple case of an opaque primitive, the sub-process ends atand reports that the rear buffer, i.e. the tag buffer representing the layer furthest from the viewer is available to store primitive IDs. The remaining steps are used when stepidentifies that the primitive is translucent. In this case the aim of the sub-process is to search the tag buffers in front to rear order and to report the rear-most layer in which it is possible to store the primitive IDs. At, variables P and C represent the previous and current tag buffers respectively. C is initialised to indicate the front-most buffer. P will indicate the buffer one layer closer to the front than C, however, since there is no closer buffer, P is initialised with a value indicating no buffer. Ata test is made to determine whether all of the primitive IDs can be stored in the buffer indicated by C. The process ends when it is found that the primitive IDs cannot be stored in C, as at this point it is known that the buffer indicated by P must be the rear-most layer in which it is possible to store the primitive IDs. Stepreturns the identity of buffer P. In the event that the test fails for the front most layer, the value of P will indicate directly that no buffer was found, due to the way that P was initialised in step. If the process does not end, i.e. the primitive IDs can be stored in buffer C, the process continues to stepwhich determines whether there is another buffer representing a layer deeper than the current buffer C. If not, then C is the rear-most buffer, and the primitive IDs may be stored in it, so atthe identity of buffer C is returned. If another buffer does exist then stepadjusts P and C by one step backwards, such that P stores the identity of what was the current buffer, and C stores the identity of the buffer immediately behind the current buffer. Flow returns to the test of step, where the test is performed to see if the primitive IDs can be stored in the buffer now represented by C.

9 a FIG. 8 FIG. 910 912 914 918 922 914 918 924 308 922 920 924 924 920 918 816 822 Returning to, the result of sub-processis tested atto determine whether a suitable buffer was found. If a buffer was found then the primitive IDs are stored in it, in step. When a buffer is not found, steps-are used to allocate a new tag buffer to the set, and stepthen stores the primitive IDs in the new buffer. Generally, the new buffer is allocated from a pool of free buffers. However, it is may not be desirable for the set of buffers associated with one tile to grow without limit, particularly if the pool of buffers is shared with several other tiles, e.g. as shown in. The test in stepmay be used to limit the number of buffers in a set, and, by directing flow to step, to cause the rear-most buffer to be flushed (i.e. the contents of the buffer are sent to texturing and shading unit). The flushed buffer may then be recycled and added to the set as a new front buffer in step. In another situation, the pool of free buffers may be empty, e.g. the buffers have been allocated to sets associated with other tiles. This is detected by the test in step. Again, flow is directed to step, when a buffer is flushed to create a new free buffer. In the case that the flow reached stepfrom step, rather than from step, it is possible for the buffer selected for flushing to be a member of a set other than the one associated with the current tile. That is, provided that it is permissible to extend a set, the set may be extended by flushing and transferring a buffer from another set. In this way, under the control of the control moduleand/or the tag sorter control module, the tag buffers may be allocated flexibly according to the requirements of the system.

906 908 956 966 910 908 308 When an opaque primitive is identified at step, stepperforms a clearing operation. The tag sorter receives only primitive IDs for fragments that have passed a depth test. It is therefore known that opaque primitive IDs must be in front of, and therefore will occlude, any other opaque or translucent primitives that have already been processed. The primitive IDs for opaque objects may therefore always be stored in the rear-most tag buffer. Stepsandof sub-processwill identify opaque objects and return the identity of the rear-most buffer. Stepclears the stored primitive IDs for any translucent objects already stored in any buffer layer, at the positions corresponding to the opaque primitive IDs. This has the effect of flattening the layer structure, ensuring that translucent fragments are not rendered unnecessarily or incorrectly. Optionally, stepmay determine that the clearing process has left a tag buffer completely empty, and return the empty layer to the pool of free buffers.

As described above, punch-through primitives are rendered in two passes. On the first pass, before the transparency has been evaluated, primitive IDs for punch-through primitives may be handled as for translucent primitives. On the second pass, a punch-through primitive ID corresponds to a part of the object that is known to be opaque. Therefore, on the second pass, primitive IDs for punch-through primitives may be handled as for opaque primitives.

Examples are described above in detail which relate to receiving primitive identifiers of translucent primitives at the tag sorter module. The same principles can be used when primitive identifiers for primitives which have textures including punch through are received.

The methods described herein could be implemented by running suitable computer readable code which is adapted to perform the steps of the methods. Furthermore, the graphics process systems described herein could be generated by running suitable computer readable code. The computer readable code could be encoded on a computer readable storage medium.

Generally, any of the functions, methods, techniques or components described above can be implemented in modules using software, firmware, hardware (e.g., fixed logic circuitry), or any combination of these implementations. The terms “module,” “functionality,” “component”, “block”, “unit” and “logic” are used herein to generally represent software, firmware, hardware, or any combination thereof.

In the case of a software implementation, the module, functionality, component, block, unit or logic represents program code that performs specified tasks when executed on a processor (e.g. one or more CPUs). In one example, the methods described may be performed by a computer configured with software in machine readable form stored on a computer-readable medium. One such configuration of a computer-readable medium is signal bearing medium and thus is configured to transmit the instructions (e.g. as a carrier wave) to the computing device, such as via a network. The computer-readable medium may also be configured as a computer-readable storage medium and thus is not a signal bearing medium. Examples of a computer-readable storage medium include a random-access memory (RAM), read-only memory (ROM), an optical disc, flash memory, hard disk memory, and other memory devices that may use magnetic, optical, and other techniques to store instructions or other data and that can be accessed by a machine.

The software may be in the form of a computer program comprising computer program code for configuring a computer to perform the constituent portions of described methods or in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. The program code can be stored in one or more computer readable media. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of computing platforms having a variety of processors.

Those skilled in the art will also realize that all, or a portion of the functionality, techniques or methods may be carried out by a dedicated circuit, an application-specific integrated circuit, a programmable logic array, a field-programmable gate array, or the like. For example, the module, functionality, component or logic may comprise hardware in the form of circuitry. Such circuitry may include transistors and/or other hardware elements available in a manufacturing process. Such transistors and/or other elements may be used to form circuitry or structures that implement and/or contain memory, such as registers, flip flops, or latches, logical operators, such as Boolean operations, mathematical operators, such as adders, multipliers, or shifters, and interconnects, by way of example. Such elements may be provided as custom circuits or standard cell libraries, macros, or at other levels of abstraction. Such elements may be interconnected in a specific arrangement. The module, functionality, component or logic may include circuitry that is fixed function and circuitry that can be programmed to perform a function or functions; such programming may be provided from a firmware or software update or control mechanism. In an example, hardware logic has circuitry that implements a fixed function operation, state machine or process.

It is also intended to encompass software which “describes” or defines the configuration of hardware that implements a module, functionality, component or logic described above, such as HDL (hardware description language) software, as is used for designing integrated circuits, or for configuring programmable chips, to carry out desired functions. That is, there may be provided a computer readable storage medium having encoded thereon computer readable program code for generating a processing unit configured to perform any of the methods described herein, or for generating a processing unit comprising any apparatus described herein.

The term ‘processor’ and ‘computer’ are used herein to refer to any device, or portion thereof, with processing capability such that it can execute instructions, or a dedicated circuit capable of carrying out all or a portion of the functionality or methods, or any combination thereof.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. It will be understood that the benefits and advantages described above may relate to one example or may relate to several examples.

Any range or value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person. For example, the specific numbers given in the examples described above (e.g. the numbers of tag buffers, depth buffers, queues, texturing engines, tiles, microtiles within a tile and sample positions within a microtile) are given by way of example only. The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.