Systems and methods for processing primitive segments

Abstract

The present disclosure relates to primitive fragment processing in a rasterization stage of a graphics processing system. A system and method for processing primitive fragments in a rasterization stage of a graphics processing system, wherein a rendering space is subdivided into a plurality of tiles, is disclosed. The method comprises: receiving a plurality of primitive fragments, each primitive fragment corresponding to a pixel sample in a tile; determining whether a depth buffer read is to be performed for hidden surface removal processing of one or more of the primitive fragments; and sorting the primitive fragments into a priority queue and a non-priority queue based on the depth buffer read determination; and performing hidden surface removal processing on the primitive fragments in the priority and non-priority queues, wherein priority is given to the primitive fragments in the priority queue.

Description

[0001] Divisional Application Instructions

[0002] This application is a divisional application of the invention patent application with the application date of June 18, 2020, application number 202010557445.5, and name “System and method for processing primitive fragments”. Technical Field

[0003] The present disclosure relates to primitive fragment processing in the rasterization stage of a graphics processing system. Background Art

[0004] The graphics processing system is configured to receive graphics data, for example, from an application (e.g., a game application) running on a computer system, and render an image from the graphics data to provide a rendered output. For example, an application may generate a 3D model of a scene and output geometry data representing objects in the scene. Specifically, the application may represent each object using one or more primitives (i.e., simple geometric shapes, such as, but not limited to, rectangles, triangles, lines, and points to which textures may be applied), where the plurality of primitives are defined by the positions of one or more vertices. In these cases, the geometry data output by the application may include information identifying each vertex (e.g., the coordinates of the vertex in world space) and information indicating the primitives formed by the vertices. The graphics processing system then converts the received geometry data into an image that can be displayed on a screen.

[0005] A graphics processing system may, for example, implement immediate mode rendering (IMR) or tile-based rendering (TBR). In IMR, the entire scene is rendered as a whole. In contrast, in TBR, the scene is rendered using a rendering space that is divided into sub-segments or sub-regions called tiles, where at least a portion of the rendering process can be performed independently for each tile. Tiles can have any suitable shape, but are typically rectangular (wherein the term "rectangular" includes squares). An advantage of TBR is that fast, on-chip memory can be used during rendering for color, depth, and stencil buffer operations, which allows for a significant reduction in system memory bandwidth compared to IMR, without requiring on-chip memory large enough to store data for the entire scene simultaneously.

[0006] TBR involves two key phases: the geometry processing phase and the rasterization phase. During the geometry processing phase, geometry data (e.g., vertices defining primitives) received from an application (e.g., a gaming application) is transformed from world-space coordinates to screen-space coordinates. A per-tile list of transformed primitives (e.g., triangles) that at least partially fall within the bounds of the tile is then created. During the rasterization phase, each tile is rendered individually (i.e., the transformed primitives are mapped to pixels and a color is identified for each pixel in the tile). This may include identifying which primitive(s) are visible at each pixel. The color of each pixel can then be determined by the appearance of the visible primitives at that pixel, which can be defined by a texture applied to that pixel and / or a pixel shader program running on that pixel. A pixel shader program describes the operations to be performed for a given pixel. Rendering each tile individually enables the graphics processing system to retrieve only the transformed primitive data associated with a particular tile when rendering that tile in the rasterization phase, which keeps bandwidth requirements for memory (e.g., intermediate buffers) low. Once a color value has been identified for each pixel in a tile, the color value for the tile is written out to memory (e.g., a frame buffer). Once the entire scene has been rendered (i.e., once color values have been determined for the pixels of all tiles), the scene can be displayed, for example, on a screen.

[0007] Figure 1 An example TBR graphics processing system 100 is shown. The system 100 includes memory 1021, 102 2、 1023, 1024, geometry processing logic 104, and rasterization logic 106. Two or more of memories 1021, 1022, 1023, and 1024 may be implemented in the same physical unit of memory.

[0008] The geometry processing logic 104 implements the geometry processing stage of TBR. The geometry processing logic 104 includes transformation logic 108 and a tiling engine 110. The transformation logic 108 receives geometry data (e.g., vertices, primitives, and / or patches) from an application (e.g., a game application) and transforms the geometry data into a rendering space (e.g., screen space). The transformation logic 108 may also perform functions such as clipping and culling to remove geometry data (e.g., primitives or patches) that falls outside the viewing frustum, and / or apply lighting / attribute processing as known to those skilled in the art. The transformed geometry data (e.g., vertices, primitives, and / or patches) is (i) stored in memory 1022 and (ii) provided to the tiling engine 110. The tiling engine 110 generates a list of transformed primitives for each tile from the transformed geometry data, the transformed primitives at least partially falling within the tile. The list may be referred to as a display list or a transformed display list. In some cases, the transformed display list includes pointers or links to transformed geometry data (eg, vertex data) associated with primitives that fall at least partially within the tile.

[0009] The rasterization logic 106 implements the rasterization stage of TBR. Specifically, the rasterization logic 106 renders primitives in a tile-by-tile manner by: fetching a display list for a tile from the memory 1023, then fetching transformed geometry data from the memory 1022 for primitives that fall within the tile as indicated by the display list for the tile; and rendering the primitives for the tile based on the transformed geometry data.

[0010] In some cases, the rasterization logic 106 may include a rasterizer 112, hidden surface removal (HSR) logic 114, and texturing / shading logic 116. In these cases, the rasterizer 112 retrieves each display list from memory 1023 and, for each display list, retrieves the transformed geometry data from memory 1022 for primitives that fall within the tile specified by the corresponding display list and converts each primitive into a set of primitive fragments. The term "fragment" is used herein to refer to a sample of a primitive at a sampling point that is processed to render a pixel of an image. In some examples, there may be a one-to-one mapping of pixels to fragments. However, in other examples, there may be more fragments than pixels, and this oversampling may allow for higher quality rendering of pixel values, for example, by facilitating anti-aliasing and other filters that may be applied to multiple fragments for rendering each pixel value.

[0011] The primitive fragments for a particular tile are then provided to the HSR logic 114, which removes hidden primitive fragments (e.g., hidden by other primitive fragments) by performing depth testing on the primitive fragments. The remaining fragments (after hidden surfaces are removed) are then passed to the texturing / shading logic 116, which performs texturing and / or shading on the primitive fragments to determine pixel values for the rendered image. The rendered pixel values for the tile are then stored in the memory 1024 (e.g., a frame buffer).

[0012] The rasterization logic 106 processes each tile, and when the entire image has been rendered and stored in the memory 1024 (e.g., a frame buffer), the image can be output from the graphics processing system 100 and used in any suitable manner, such as displayed on a display, stored in memory, or transmitted to another device, etc. In the sense that fragments are processed by the HSR logic 114 before being processed by the texturing / shading logic 116, Figure 1 The TBR graphics processing system 100 shown is a “deferred” rendering system. In other examples, the graphics processing system may not be a deferred rendering system, in which case texturing / shading would be applied to fragments before HSR is applied to those fragments.

[0013] It is important to be able to perform depth testing in an efficient manner.

[0014] The embodiments described below are provided by way of example only and are not limiting of implementations that address any or all of the shortcomings of known methods and systems for performing depth testing in graphics processing systems. Summary of the Invention

[0015] This summary is provided to introduce some concepts 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.

[0016] A system and method for processing primitive fragments in a rasterization stage of a graphics processing system is described herein, wherein a rendering space is subdivided into a plurality of tiles. The method comprises: receiving a plurality of primitive fragments, each primitive fragment corresponding to a pixel sample in a tile; determining whether a depth buffer read is to be performed for hidden surface removal processing of one or more of the primitive fragments; and sorting the primitive fragments into a priority queue and a non-priority queue based on the depth buffer read determination; and performing hidden surface removal processing on the primitive fragments in the priority and non-priority queues, wherein priority is given to the primitive fragments in the priority queue.

[0017] A first aspect provides a system for processing primitive fragments in a rasterization stage of a graphics processing system, wherein a rendering space is subdivided into a plurality of tiles, the system comprising: a priority queue for storing primitive fragments; a non-priority queue for storing primitive fragments; logic configured to: receive a plurality of primitive fragments, each primitive fragment corresponding to pixel samples in a tile; determine whether a depth buffer read is to be performed for hidden surface removal processing of one or more of the primitive fragments; and classify the primitive fragments into the priority queue and the non-priority queue based on the depth buffer read; and hidden surface removal logic configured to perform hidden surface removal processing on the primitive fragments in the priority and non-priority queues, wherein priority is given to the primitive fragments in the priority queue.

[0018] A second aspect provides a method for processing primitive fragments in a rasterization stage of a graphics processing system, wherein a rendering space is subdivided into a plurality of tiles, the method comprising: receiving a plurality of primitive fragments, each primitive fragment corresponding to a pixel sample in a tile; determining whether a depth buffer read is to be performed for hidden surface removal processing of one or more of the primitive fragments; and classifying the primitive fragments into a priority queue and a non-priority queue based on the depth buffer read; and performing hidden surface removal processing on the primitive fragments in the priority and non-priority queues, wherein priority is given to the primitive fragments in the priority queue.

[0019] A third aspect provides a graphics processing system configured to execute the method of the second aspect.

[0020] The coarse depth test logic and graphics processing system described herein may be embodied as hardware on an integrated circuit. A method of manufacturing the coarse depth test logic and / or graphics processing system described herein at an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided that, when processed in the integrated circuit manufacturing system, configures the system to manufacture the coarse depth test logic or graphics processing system as described herein. A non-transitory computer-readable storage medium may be provided having stored thereon a computer-readable description of the coarse depth test logic or graphics processing system, which, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the coarse depth test logic or graphics processing system.

[0021] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of the coarse depth test logic or graphics processing system described herein; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit embodying the coarse depth test logic or graphics processing system; and an integrated circuit generation system configured to manufacture the coarse depth test logic or graphics processing system based on the circuit layout description.

[0022] Computer program code for performing the method as described herein may be provided.A non-transitory computer-readable storage medium having computer-readable instructions stored thereon may be provided, which, when executed at a computer system, causes the computer system to perform the method as described herein.

[0023] It will be clear to those skilled in the art that the above-described features may be combined where appropriate and with any aspect of the examples described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0025] Figure 1 is a block diagram of an example tile-based rendering graphics processing system;

[0026] Figure 2 is a block diagram of an example hybrid rendering graphics processing system;

[0027] Figure 3 is a block diagram of an example hybrid rendering graphics processing system with coarse depth testing logic;

[0028] Figure 4 yes Figure 3 A block diagram of an example implementation of coarse depth test logic;

[0029] Figure 5 is a diagram illustrating an example coarse hidden depth test based on a depth range of a tile;

[0030] Figure 6 is a diagram illustrating an example coarse pre-depth test based on tile-based depth ranges;

[0031] Figure 7 is a schematic diagram showing the relationship between 'previous' primitives and 'non-previous' primitives;

[0032] Figure 8 is a schematic diagram illustrating an example pixel sample map;

[0033] Figure 9 is a schematic diagram illustrating updating an example pixel sample map in response to an example 'previous' primitive;

[0034] Figure 10 is a schematic diagram illustrating determining whether to perform a depth buffer read of a first example 'non-previous' primitive based on an example pixel sample map;

[0035] Figure 11 is a diagram illustrating determining whether to perform a depth buffer read of a second example 'non-previous' primitive based on an example pixel map;

[0036] Figure 12 is a flow chart of an example method for performing coarse depth testing in a graphics processing system;

[0037] Figure 13 is used for Figure 12 a flowchart of a first example set of optional steps of a method;

[0038] Figure 14 is used for Figure 12 a flowchart of a second example set of optional steps of a method;

[0039] Figure 15 is a diagram illustrating a first example method of determining a maximum or minimum depth of a primitive in a tile;

[0040] Figure 16 is a diagram illustrating a second example method of determining a maximum or minimum depth of a primitive in a tile;

[0041] Figure 17 is a diagram illustrating a third example method of determining a maximum or minimum depth of a primitive in a tile;

[0042] Figure 18 It is shown that when the Figure 12 A graph showing the depth buffer read bandwidth reduction for several benchmarks using the coarse depth test method.

[0043] Figure 19 is a block diagram of an example system for processing primitives in a rasterization stage in which a queue is placed between coarse depth test logic and HSR logic;

[0044] Figure 20 is a block diagram of an example system for processing primitives in a rasterization stage in which two queues are placed between coarse depth test logic and HSR logic;

[0045] Figure 21 The primitives are classified into Figure 20 Flowchart of an example method for two queues;

[0046] Figure 22 It is from Figure 20A flowchart of an example method for selecting primitives to be processed from two queues;

[0047] Figure 23 is a block diagram of an example computer system in which the coarse depth test logic or graphics processing system described herein may be implemented; and

[0048] Figure 24 is a block diagram of an example integrated circuit fabrication system that may be used to produce integrated circuits embodying the coarse depth test logic or graphics processing systems described herein.

[0049] The accompanying drawings illustrate various examples. Those skilled in the art will appreciate that element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent one example of boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. Where appropriate, common reference numerals are used throughout the drawings to indicate similar features. DETAILED DESCRIPTION

[0050] The following description is presented as an example to enable a person skilled in the art to make and use the present invention. The present invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described by way of example only.

[0051] As described above, by rendering each tile individually, a TBR graphics processing system only needs to retrieve the transformed primitive data associated with a particular tile when rendering that tile in the rasterization stage, which keeps bandwidth requirements on memory (e.g., intermediate buffers) to a minimum. However, TBR also has a number of disadvantages compared to immediate mode rendering. For example, TBR typically requires the use of system memory to store the transformed geometry data for an entire frame, which typically requires a large amount of bandwidth to transfer data (e.g., transformed geometry data) between the chip on which the geometry processing logic 104 and rasterization logic 106 are implemented and memory that is typically located "off-chip." Therefore, in order to take advantage of some of the benefits of TBR while reducing some of the disadvantages associated therewith, the applicant has developed a "hybrid rendering" technique, which, as the name suggests, is a hybrid between immediate mode rendering and TBR.

[0052] In hybrid rendering, the rendering space is divided into tiles and primitives are associated with tiles, just like in TBR (but in some cases, the tiles can be smaller). Accordingly, in hybrid rendering, there is also a geometry processing stage and a rasterization stage. However, while in TBR, the display list generated by the geometry processing stage contains, if possible, a list of all transformed primitives that fall at least partially within a particular tile, in hybrid rendering, the display list generated by the geometry processing stage may only contain a subset of transformed primitives that fall at least partially within a particular tile for a particular rendering, so the display list may be referred to as a partial display list in this article. Specifically, in TBR, if possible, all primitives are processed in the geometry processing stage and the transformed primitives are stored in off-chip memory, and a display list is generated for each tile, the display list referring to the transformed primitives stored in memory. In contrast, in hybrid rendering, transformed primitives are stored in a relatively small memory (e.g., on-chip memory, such as a local buffer), and a partial display list is generated for each tile, referring to the transformed primitives in the small memory. The small memory (e.g., the local buffer) is not necessarily large enough to store all transformed primitives for rendering, so when transformed primitives are generated in the geometry processing stage, they are stored in the small memory, and a partial display list is built for the transformed primitives stored in the small memory. The partial display list is periodically provided to the rasterization stage so that some of the transformed primitives can be processed in the rasterization stage, so that these primitives no longer need to be stored in the small memory (and can be removed from it), thereby freeing up a portion of the small memory. New transformed primitives are then stored in the free space in the small memory, and partial display lists continue to be built based on the new transformed primitives. However, a partial display list for a particular tile may be sent to the rasterization stage before all of the transformed primitives for the tile have been stored in the small memory, and thus, at least one subsequent partial list may be generated for the tile, the at least one subsequent partial list including transformed primitives stored in the small memory after a previous partial display list for the tile was provided to the rasterization stage.

[0053] Figure 2 An example hybrid rendering graphics processing system 200 is shown. Graphics processing system 200 includes memories 2021, 2024, geometry processing logic 204, and rasterization logic 206. Memories 2021 and 2024 may be implemented in the same physical unit of memory.

[0054] Similar to Figure 1The geometry processing logic 204 implements the geometry processing stage. The geometry processing logic 204 includes the transformation logic 208 and the tiling engine 210. The operation of the transformation logic 208 is similar to that of the Figure 1 The tiling engine 210 may be configured to process the geometry data (e.g., vertices, primitives, and / or patches) of the image. The tiling engine 210 may be configured to process the geometry data (e.g., vertices, primitives, and / or patches) of the image. Specifically, the ...

[0055] The tiling engine 210 stores the transformed geometry data in a transformed local geometry buffer 211 and, for each tile, generates a list of transformed primitives in the transformed local geometry buffer 211 that fall at least partially within the tile. The list may be referred to as a partial display list. In some cases, the partial display list may include pointers or links to the transformed geometry data (e.g., vertex data) in the transformed local geometry buffer 211 associated with the primitives that fall at least partially within the tile. The transformed local geometry buffer is not necessarily large enough to store all the transformed geometry data to render a frame. Therefore, the tiling engine 210 periodically (e.g., from time to time, such as at regular intervals, or when the transformed geometry buffer 211 becomes full, or when the fullness of the transformed geometry buffer 211 exceeds a threshold) sends one or more partial display lists to the rasterization logic 206 to free up space in the buffer 211. As described above, this means that when a partial display list is provided to the rasterization logic 206 , it may include only a portion of the primitives that fall within the tile (because some primitives that fall within the tile may not have been processed by the geometry processing logic 204 ).

[0056] The rasterization logic 206 performs the rasterization stage. Specifically, the rasterization logic 206 renders primitives in a tile-by-tile manner by: extracting transformed geometry data from the transformed local geometry buffer 211 for primitives that fall within a tile as indicated by the partial display list for that tile; and rendering the primitives for that tile based on the transformed geometry data.

[0057] In some cases, the rasterization logic 206 may include a rasterizer 212, hidden surface removal (HSR) logic 214, and texturing / shading logic 216. In these cases, the rasterizer 212 receives partial display lists from the tiling engine 210 and, for each partial display list, extracts transformed geometry data from the transformed local geometry buffer 211 for primitives that fall within the tile as indicated by the partial display list and converts each primitive into a set of primitive fragments.

[0058] The primitive fragments for a particular tile are then provided to HSR logic 214, which removes hidden primitive fragments (e.g., hidden by other primitive fragments). The remaining fragments (after hidden surface removal) are then passed to texturing / shading logic 216, which performs texturing and / or shading on the primitive fragments to determine pixel values for the rendered image. The rendered pixel values for the tile may then be stored in 2024 (e.g., a frame buffer).

[0059] When the entire image has been rendered and stored in memory 2024 (eg, a frame buffer), the image may be output from graphics processing system 200 and used in any suitable manner, such as displayed on a display, stored in memory, transmitted to another device, or the like.

[0060] Although the geometry processing logic is shown as separate from the rasterization logic in the figure, in some embodiments, the geometry processing logic and the rasterization logic may share some resources. For example, the graphics processing system may use a unified shading approach, in which the same physical execution unit can be used to execute instructions used in the geometry processing stage (e.g., perform vertex processing) and to execute instructions used in the rasterization stage (e.g., perform fragment processing).

[0061] In such a hybrid rendering graphics processing system, each tile may be processed more than once in the rendering stage. For example, a first partial display list for a tile may be generated by the geometry processing stage, which is then processed in the rasterization stage; subsequently, a second partial display list for the same tile may be generated by the geometry processing stage, which is then processed in the rasterization stage. Whenever a partial display list is processed in the rasterization stage, full-resolution hidden surface removal is performed by hidden surface removal (HSR) logic to remove hidden primitive fragments. This may involve reading in a depth buffer for the tile stored in memory, and comparing the depth value (e.g., Z value or Z coordinate) of each of the primitive fragments with the value in the depth buffer for the corresponding sample position. Specifically, the depth buffer is a record of the 'best' depth value (e.g., the depth value closest to the viewer) for each pixel sample of the tile so far. If a received primitive fragment has a depth value that is 'worse' than the corresponding depth value in the depth buffer (e.g., a depth value indicating that it is farther from the viewer), then the primitive fragment is hidden by another primitive and, therefore, the primitive fragment 'fails' the depth test and is discarded. However, if a received primitive fragment has a depth value that is 'better' than the corresponding depth value in the depth buffer (i.e., a depth value indicating that it is closer to the viewer), then the primitive fragment 'passes' the depth test. The primitive identifier of the primitive fragment is then stored in a tag buffer, and the corresponding value in the depth buffer is updated to indicate the presence of a new 'best' depth value. The tag buffer stores, for each sample position (i.e., pixel sample) of the tile, the primitive identifier of the primitive fragment that most recently passed the depth test at that sample position. Once the depth test has been performed for all primitive fragments corresponding to a partial display list, the depth buffer is stored in memory until the next partial display list for that tile is processed by the HSR logic.

[0062] Therefore, in such graphics processing systems, the depth buffer of each tile may be read from and written to the memory multiple times. Since each read and write consumes a lot of bandwidth and time, it is desirable to reduce the number of reads and writes to the depth buffer in such graphics processing systems.

[0063] Thus, coarse depth test logic and methods are described herein for performing a coarse depth test on a set of primitives and / or primitive fragments associated with a tile (e.g., primitives / primitive fragments in a partial display list) and subsequently performing full-resolution hidden surface removal (e.g., depth testing performed by HSR logic) on those primitives / primitive fragments in order to reduce the number of reads from and writes to the depth buffer of the tile. Specifically, in the methods and logic described herein, a depth range (e.g., a minimum depth value and a maximum depth value) is maintained for each tile and stored on-chip. Based on the depth range of the tile, an initial ("coarse") determination is made as to whether the primitives / primitive fragments in the set are hidden by primitives already processed for the tile (e.g., primitives associated with a previous or earlier partial display list for the tile) and / or whether the primitives / primitive fragments have a 'better' depth (according to a depth comparison mode) than the primitives already processed for the tile.

[0064] Specifically, when the coarse depth test logic receives a set of primitives for a tile, the coarse depth test logic determines, based on the depth range of the tile, whether each of the primitives (or each of the primitive fragments generated by the primitive) would be hidden by a primitive previously processed for the tile at each location in the tile where the primitive / primitive fragment overlaps. If the primitive / primitive fragment is determined to be hidden, then no further processing is performed on the primitive / primitive fragment with respect to the tile (e.g., the primitive / primitive fragment is not processed by the HSR logic with respect to the tile). Therefore, if the primitive / primitive fragment is determined to be hidden, then the primitive / primitive fragment may not be output from the coarse depth test logic. However, if the primitive / primitive fragment is not determined to be hidden at each location in the tile where the primitive / primitive fragment overlaps, then the coarse depth test logic determines, based on the depth range of the tile, whether the primitive / primitive fragment has a 'better' depth than a primitive already processed for the tile at each location in the tile where the primitive / primitive fragment overlaps. If a primitive / primitive fragment is determined to have a 'better' depth than primitives already processed for that tile, then the tile's depth buffer does not need to be read to perform a full resolution depth test on that primitive / primitive fragment, and the primitive / primitive fragment is identified as such.

[0065] Thus, in the methods and systems described herein, if each of the primitives or primitive fragments in the set: (i) is hidden by a primitive previously processed for the tile; or (ii) has a 'better' depth than the primitive previously processed for the tile according to a depth comparison mode, then a read of the tile's depth buffer need not be performed to perform a full-resolution depth test on the set of primitives for the tile. This can significantly reduce the number of depth buffer reads from memory in situations where each tile is processed multiple times (e.g., via multiple partial display lists).

[0066] In some cases, as described in more detail below, the reads of the depth buffer of a tile and / or the number of full-resolution depth tests performed on the tile can be further reduced by: maintaining a record of the pixel samples in the tile whose 'best' depth values will be available to the HSR logic; and comparing the pixel samples associated with each primitive / primitive fragment to the record to determine whether the read of the depth buffer can be omitted and / or whether the full-resolution depth test can be omitted for the primitive / primitive fragment.

[0067] Although the coarse depth test logic and methods for performing coarse depth testing are described below as being used in a hybrid rendering graphics processing system, the use of the coarse depth test logic and related methods described herein is not limited to use in a hybrid rendering graphics processing system and may be used in other graphics processing systems, such as, but not limited to, other graphics processing systems that render areas of a rendering space multiple times (e.g., render primitives associated with the same area in batches or groups).

[0068] Now refer to Figure 3 , which shows an example hybrid rendering graphics processing system 300 including coarse depth test logic 320 that performs a coarse depth test on primitives associated with a tile (e.g., primitives in a partial display list) based on a depth range associated with the tile before full-resolution hidden surface removal. Specifically, the hybrid rendering graphics processing system 300 and Figure 2 The hybrid rendering graphics processing system 300 is similar to the hybrid rendering graphics processing system 200 of FIG. 3 , and has: memories 3021, 3024; geometry processing logic 304, which includes transformation logic 308, a tiling engine 310, and a transformed local geometry buffer 311; and rasterization logic 306, which includes a rasterizer 312, HSR logic 314, and texturing / shading logic 316 (which is generally similar to the above description of FIG. 3 ). Figure 2 The corresponding components in the described system 200 operate in the same manner), except that the hybrid rendering graphics processing system 300 additionally includes coarse depth test logic 320.

[0069] The coarse depth test logic 320 is configured to perform a coarse depth test on each set of primitives / primitive fragments associated with a tile (e.g., primitives / primitive fragments in a partial display list) before full-resolution hidden surface removal (i.e., full-resolution depth testing). Specifically, the coarse depth test logic 320 is configured to: store a depth range (e.g., a minimum depth value and a maximum depth value) for each tile, the depth range representing the depth range of the tile based on primitives that have been previously processed (e.g., previously rendered) for the tile; and perform a coarse hidden depth test for each primitive associated with the tile (or each primitive fragment generated by the primitive) based on the stored depth range for the tile to determine whether the primitive / primitive fragment is hidden by a primitive previously processed for the tile. If the coarse depth test logic determines that the primitive / primitive fragment is hidden in the tile, no further processing is performed on the primitive / primitive fragment with respect to the tile (e.g., the primitive / primitive fragment is not processed by the HSR logic 314 with respect to the tile). For example, if the coarse depth test logic 320 determines that a primitive is hidden in a tile, then the primitive may not be output by the coarse depth test logic 320. However, if the coarse depth test logic 320 does not determine that the primitive / primitive fragment is hidden by a primitive previously processed for the tile, then the coarse depth test logic 320 performs a coarse pre-depth test based on the depth range of the tile to determine whether the primitive / primitive fragment has a 'better' depth than the primitive previously processed for the tile. If the primitive / primitive fragment is determined to have a 'better' depth than the primitive previously processed for the tile, then the coarse depth test logic 320 provides the primitive / primitive fragment to the HSR logic with an indication or flag that full resolution depth testing may be performed without reading the depth buffer of the tile.

[0070] In one example, a coarse hidden depth test is performed by the coarse depth test logic 320 before the rasterizer 312 rasterizes the set of primitives (i.e., before the primitives are converted into primitive fragments), and a coarse pre-depth test is performed after the rasterizer 312 has rasterized the set of primitives (i.e., after the primitives have been converted into primitive fragments). An advantage of performing a coarse hidden depth test before rasterization is that any primitives that are hidden are culled before rasterization, so time and resources are not wasted rasterizing hidden primitives. Specifically, rasterizing primitives into primitive fragments typically involves determining the depth of each primitive fragment by interpolating the depths of the primitive's vertices, which is very computationally intensive. Thus, culling primitives before rasterization can avoid performing this computationally intensive processing on primitives that will not be visible in the final frame / image. An advantage of performing the coarse pre-depth test after rasterization is that in some cases a finer coarse pre-depth test (e.g., at the primitive fragment / pixel sample level rather than at the primitive level) can be performed relative to the minimum depth value of the tile. However, it will be apparent to those skilled in the art that this is merely an example, and that the functionality performed by the coarse depth test logic 320 can be split in any suitable manner between before and after rasterization (i.e., converting primitives to primitive fragments). For example, in other cases, both the coarse hidden depth test and the coarse pre-depth test can be performed after rasterization, or both the coarse hidden depth test and the coarse pre-depth test can be performed before rasterization. Figure 4 An example implementation of the coarse depth test logic 320 is described.

[0071] In this example, the HSR logic 314 is configured to receive primitives (or primitive fragments) that pass the coarse depth test performed by the coarse depth test logic 320 and perform full-resolution hidden surface removal on the received primitives / primitive fragments, and when the HSR logic 314 receives a primitive / primitive fragment that has been identified as not requiring a depth buffer read, perform full-resolution hidden surface removal without reading the depth buffer of the corresponding tile.

[0072] For example, in some cases, the HSR logic 314 may be configured to maintain a depth value update map for a tile and a current best depth value buffer for the tile while performing hidden surface removal on a set of primitives (or a set of primitive fragments) associated with the tile. The depth value update map indicates which pixel sample depth values have been updated during processing of the set of primitives / primitive fragments, and the current best depth value buffer indicates the 'best' (e.g., minimum) depth value for each pixel sample of the tile so far. When the HSR logic 314 receives the first primitive / primitive fragment in the set associated with the tile, the depth value update map for the tile may be initialized to indicate that the depth value has not been updated. The current best depth value buffer for the tile may also be initialized at this time. However, the initialization of the current best depth value buffer may differ depending on whether the depth buffer for the tile has been loaded from memory. For example, if the first primitive / primitive fragment in the set is identified as not requiring a depth buffer read, the depth buffer for that tile may not yet have been read from memory, and the value in the current best depth value buffer may be initialized to the 'worst' (e.g., maximum) depth value. However, if the first primitive / primitive fragment is not identified as not requiring a depth buffer read (i.e., it requires a depth buffer read), then when the depth buffer is read from memory, the value in the current best depth value buffer may be initialized to the value in the depth buffer. If one or more pixel sample depth values are updated in the current best depth value buffer before the depth buffer read and the HSR logic subsequently receives a primitive / primitive fragment that triggers a depth buffer read (i.e., a primitive / primitive fragment that was not identified as not requiring a depth buffer read), then only the depth values in the loaded depth buffer associated with those pixel samples that were not marked as having been updated in the depth value update map are loaded into the current best depth value buffer. For example, if the depth value associated with pixel sample 1 is updated before the depth buffer is read, the depth value associated with sample 1 in the current best depth value buffer is not replaced or overwritten with the depth buffer value associated with pixel sample 1.

[0073] Performing full-resolution hidden surface removal on a primitive / primitive fragment may include comparing the depth of the primitive fragment, or the depth value of each primitive fragment of a primitive, to the corresponding current 'best' depth value of the pixel samples associated with the primitive fragment in the tile. If the depth value of the primitive fragment is better than the current 'best' depth value, then the primitive fragment passes the full-resolution depth test and an identifier of the primitive fragment is sent to the tag buffer. The current best depth value buffer is then updated to reflect the new 'best' depth value of the pixel sample, and the depth value update map is updated to reflect that the depth value of the pixel sample has been updated. However, if the depth value of the primitive fragment is worse (e.g., higher) than the current 'best' depth value of the corresponding pixel sample, then the primitive fragment fails the full-resolution depth test and no further processing is performed on the primitive fragment relative to the tile (e.g., the primitive fragment may not be processed by texturing / shading logic relative to the tile).

[0074] When the last primitive / primitive fragment associated with a tile in a set is processed by the HSR logic 314 , the HSR logic 314 may be configured to write the depth value in the current best depth value buffer identified as being updated in the depth value update map to the depth buffer in memory.

[0075] Now refer to Figure 4 , which shows Figure 3 1 . An example implementation of the coarse depth test logic 320 of FIG. 1 is provided. In this example, the coarse depth test logic 320 includes a memory 402 for storing a depth range for each tile; hidden depth test logic 404 for determining whether each of the primitives / primitive fragments associated with a tile is hidden by a primitive previously processed for the tile; and previous depth test logic 406 for determining whether each of the primitives / primitive fragments associated with a tile has a 'better' depth than a primitive previously processed for the tile. The coarse depth test logic 320 may also include depth range update logic 408 for updating the depth range of the tile.

[0076] The depth range of each tile represents the depth range associated with primitives previously processed (e.g., previously rendered) for that tile. As described above, the depth buffer of a tile is used to record the 'best' (e.g., lowest) depth value of each pixel sample in the tile so far, where the 'best' (e.g., lowest) depth value of a pixel sample is the depth value of the currently unhidden or visible primitive fragment at that pixel sample. In some cases, the depth range of a tile may be defined by a minimum depth value and a maximum depth value for the tile, where the minimum depth value of the tile is the minimum 'best' depth value (so far) for the tile, and the maximum depth value of the tile is the maximum 'best' depth value (so far). In other words, the minimum depth value of the tile is the minimum depth value of unhidden primitive fragments in the tile based on primitives previously processed for the tile, and the maximum depth value of the tile is the maximum depth value of unhidden primitive fragments in the tile based on primitives previously processed for the tile. In some cases, at the start of each rendering, the maximum and minimum depth values of each tile can be initialized (e.g., by a driver or another component) to the maximum and minimum depth values in the depth buffer of the tile, respectively. In other cases, without automatically initializing the maximum and minimum depth values of the tile by, for example, a driver, the coarse depth test logic 320 can be configured to initialize the maximum and minimum depth values of all tiles to the 'worst' (e.g., maximum) possible depth value.

[0077] The meaning of the minimum and maximum depth values (e.g., whether the minimum or maximum value is closer to the viewer) may depend on the depth comparison mode used by the graphics processing system to determine when an object (e.g., a primitive / primitive fragment) is in front of another object (e.g., a primitive / primitive fragment). Specifically, the graphics processing system can use a variety of different depth comparison modes and can switch between them. Example depth comparison modes include, but are not limited to, "less than" (DCM_LESS), "less than or equal to" (DCM_LESS_EQ), "greater than" (DCM_GREATER), "greater than or equal to" (DCM_GREATER_EQ), "equal to" (DCM_EQ), "not equal to" (DCM_NOT_EQ), "always" (DCM_ALWAYS), or "never" (DCM_NEVER).

[0078] The DCM_LESS comparison mode is a common depth comparison mode because it corresponds to rendering in a coordinate system where depth values increase with distance from the viewer. A primitive fragment with a smaller depth value than another primitive fragment is closer to the viewer and, therefore, has a 'better' depth value and is rendered in front of the other primitive fragment. Other depth comparison modes support alternative coordinate systems. Depth comparison modes are traditionally used for full-resolution hidden surface removal in the HSR logic 314, but may also be considered when performing coarse depth testing in the coarse depth test logic 320.

[0079] The depth range of each tile can be stored in the memory 402 in any suitable manner. For example, in some cases, the depth range of the tiles can be stored in a lookup table or index table with one entry for each tile. For example, the tiles can be numbered from 0 to n, and the depth range (e.g., maximum depth value and minimum depth value) of the i-th tile can be stored at the i-th index in the table and accessed via that index. In some cases, the coarse depth test logic 320 may include a cache (not shown) between the memory 402 storing the depth ranges and the hidden depth test logic 404 and / or the front depth test logic 406, which stores the depth ranges of recently accessed tiles. This can significantly reduce the number of reads from the memory 402, as both the hidden depth test logic 404 and the front depth test logic 406 will need to access the same depth range information multiple times. However, because memory 402 is implemented “on-chip” as part of the coarse depth test logic 320, the cost of reading data from and writing data to memory 402 is not as high (in terms of power consumption and latency) as the cost of reading data from and writing data to off-chip system memory (3021 and 3024).

[0080] The hidden depth test logic 404 is configured to receive a set of primitives associated with a tile (e.g., primitives in a partial display list) or a set of primitive fragments associated with a tile (e.g., primitive fragments generated by primitives in a partial display list) and perform a coarse hidden depth test on the primitives / primitive fragments based on the depth range of the tile to determine which primitives / primitive fragments in the set are hidden by a primitive previously processed for the tile at each location in the tile that is overlapped by a primitive / primitive fragment.

[0081] In some cases, the hidden depth test logic 404 may be configured to perform a coarse hidden depth test on a per-primitive basis. Specifically, in some cases, the hidden depth test logic 404 may be configured to determine, for each primitive in the set, whether the primitive is hidden by a primitive previously processed for the tile at all locations in the tile overlapped by the primitive (i.e., whether the primitive is hidden in the tile). In these cases, the hidden depth test logic 404 may be configured to determine whether the primitive is hidden by a primitive previously processed for the tile at all locations in the tile overlapped by the primitive by comparing the maximum depth and / or minimum depth of the primitives in the tile to the depth range of the tile.

[0082] For example, when the coarse depth test logic 320 operates in DCM_LESS mode, the only thing that can be determined with certainty is that at each location in a tile that is overlapped by primitives, if the minimum depth value (prim min ) is greater than the maximum depth of the tile (tile max )(i.e., prim min >tile max ), then the primitive is hidden. This is Figure 5 506, where the range of possible depth values extends from 0.0 to 1.0, with 0.0 being closest to the viewer and 1.0 being farthest from the viewer. In each example 502, 504, 506, the depths (prim max 、prim min ) is shown as the depth range of the tile (tile max 、tile min ) for comparison. In the first example 502, primitive 508 has min to prim max The depth range is determined by the tile min and tile max In this example, it is not possible to know that primitive 508 is hidden at all locations in the tile without comparing the depth of the primitive at each relevant location with the corresponding depth in the depth buffer, and therefore it is not possible to determine with certainty in the coarse depth test logic 320 that the primitive is hidden.

[0083] In the second example 504, primitive 510 has min to prim maxIn this example, the primitive will be hidden at some locations, but it cannot be determined with certainty in the coarse depth test logic 320 that the primitive is hidden at all locations.

[0084] In the third example 506, primitive 512 has min to prim max The depth range of the tile is greater than the maximum depth of the prim min >tile max ). This means that at every position of the tile that is overlapped by a primitive, there is a primitive that has been previously processed for this position of this tile that has a 'better' depth value (e.g. a smaller depth value when the depth comparison mode is DCM_LESS). Therefore, the primitive will not be unhidden at any position in the tile (i.e., at every position in the tile that is overlapped by a primitive, the primitive will be hidden).

[0085] Any suitable method may be used to determine the maximum depth and / or minimum depth of a primitive in a tile. An example method for determining the maximum depth and / or minimum depth of a primitive in a tile is described below. For example, when the primitive falls entirely within the bounds of the tile and a coarse hidden depth test is performed prior to rasterization, the maximum depth and minimum depth of the primitive's vertices may be used as the maximum depth and minimum depth of the primitive. However, when the primitive does not fall entirely within the bounds of the tile and a coarse hidden depth test is performed prior to rasterization, the maximum depth or minimum depth of the primitive in the tile may be estimated as the maximum or minimum of: the depth at any intersection of the edge of the primitive with the edge of the tile; the depth of the primitive at any location where the corner of the tile falls within the primitive; and the depth of any vertex where the primitive falls within the tile (see, e.g., Figure 16 ).

[0086] If the hidden depth test logic 404 determines that the primitive is hidden in a tile, then the primitive is not further processed for that tile (e.g., full resolution depth testing is not performed on the primitive for that tile). However, if the hidden depth test logic 404 has not determined that the primitive is hidden at all locations in the tile that are overlapped by the primitive, then the hidden depth test logic 404 outputs the primitive for further processing. In some cases (e.g., Figure 3), the hidden depth test logic 404 may be configured to output primitives that pass the coarse hidden depth test to the rasterizer 312, which generates primitive fragments from those primitives, and the primitive fragments are then provided to the front depth test logic 406. However, in other cases, the hidden depth test logic 404 may be configured to provide primitives that pass the coarse hidden depth test directly to the front depth test logic 406.

[0087] In some cases, instead of performing a hidden depth test on a per-primitive basis, a hidden depth test may be performed on a per-primitive fragment basis. For example, in some cases, a primitive may be converted (i.e., rasterized) into a primitive fragment before being provided to the hidden depth test logic 404 (e.g., by the rasterizer 312), such that the hidden depth test logic 404 receives a set of primitive fragments associated with a tile. Next, for each primitive fragment in the set, the coarse hidden depth test logic 404 may be configured to determine whether the primitive fragment is hidden in the tile by a primitive previously processed for the tile. When implementing DCM_LESS mode, if the depth value of the primitive fragment is greater than the tile maximum depth value defined by the depth range of the tile, the primitive fragment may be determined to be hidden in the tile by a primitive previously processed for the tile. If the primitive fragment is determined to be hidden in the tile, no further processing may be performed on the primitive fragment relative to the tile (e.g., a full-resolution depth test may not be performed on the primitive fragment). However, if it is determined that the primitive fragment is not hidden in a tile, then the primitive fragment may be output to the front depth test logic 406 .

[0088] The front depth test logic 406 is configured to perform a coarse front depth test based on the depth range of the tile on primitives / primitive fragments received (directly or indirectly) from the hidden depth test logic 404. Specifically, the front depth test logic 406 is configured to determine whether the primitives / primitive fragments in the set have a 'better' depth (according to a depth comparison mode) than a primitive previously processed for the tile based on the depth range of the tile.

[0089] In some cases, the front depth test logic 406 may be configured to perform a coarse front depth test on a per-primitive basis, where a primitive has a 'better' depth than a primitive previously processed for a tile if, at all locations in the tile overlapped by the primitive, the primitive has a 'better' depth than a primitive previously processed for the tile. In these cases, the front depth test logic 406 may be configured to determine whether a primitive has a 'better' depth than a primitive previously processed for the tile by comparing the maximum depth and / or minimum depth of the primitives in the tile to the depth range of the tile.

[0090] For example, when the coarse depth test logic 320 operates in DCM_LESS mode, the only thing that can be determined conclusively is that at each location in a tile that is overlapped by primitives, if the maximum depth value (prim max ) is less than the minimum depth of the tile (tile min )(i.e., prim max <tile min ), then the primitive has a 'better' depth than the previously processed primitive. This is Figure 6 , where the range of possible depth values extends from 0.0 to 1.0, with 0 being closer to the viewer and 1.0 being further away from the viewer. In this example, primitive 602 has min to prim max depth range, where the entire depth range of the primitive is less than the minimum depth of the tile (i.e., the prim max <tile min ). This means that at every position of the tile that is overlapped by a primitive, the primitive has a 'better' depth value than all primitives previously processed for that tile. Thus, primitive 602 will be in front of primitives previously processed for that tile at sample positions that are overlapped by the primitive. Such primitives may be referred to herein as 'previous' primitives.

[0091] If the front depth test logic 406 has determined that a primitive has a 'better' (e.g., smaller) depth than a primitive previously processed for the tile, the front depth test logic 406 identifies the primitive as one for which full-resolution depth testing (e.g., performed by HSR logic) can be performed on the primitive relative to the tile without reading the depth buffer. Such primitives may also be referred to as 'no depth buffer read' primitives. This is because if a primitive has a better (e.g., smaller) depth than a primitive previously processed for the tile, then (i) the primitive has the 'best' depth values at all relevant pixel samples, and therefore the depth value of the primitive at each relevant pixel sample will become the new 'best' depth for those pixel samples; or (ii) one or more primitives preceding the primitive in the set will have a better depth value than the depth value of the primitive at one or more pixel samples. In the second case, the depth value of the primitive only needs to be compared with the depth values of earlier primitives in the set. In either case, the 'best' depth values for those pixel samples will be from the primitives in the set currently being processed. Thus, if the front depth test logic 406 has determined that a primitive has a better (e.g., smaller) depth than all primitives previously processed for that tile, the front depth test logic 406 may output the primitive along with an indication that a depth buffer read is not necessary. The indication may take any suitable form. For example, in some cases, the indication may take the form of a flag when a depth buffer read is not necessary. However, this is merely an example, and the indication may take other forms. When a coarse front depth test is performed after rasterization, each primitive fragment associated with the primitive in the tile may be identified as a 'no depth buffer read' primitive fragment.

[0092] Performing a coarse pre-depth test to identify primitives for which a depth buffer read is not necessary can significantly reduce the number of depth buffer reads. For example, if all primitives in a set of primitives received by the hidden depth test logic 404 are culled because they are hidden or identified as not requiring a depth buffer read because they have a 'better' depth than primitives previously processed for that tile, then when the set of primitives (or primitive fragments associated therewith) is subsequently processed by the HSR logic, the depth buffer of the corresponding tile does not need to be read.

[0093] In some cases, the front depth test logic 406 can be configured to further reduce the number of depth buffer reads by: maintaining a record (e.g., in memory 410) of the pixel samples in the tile for which the HSR logic is known to have the 'best' depth value; and for any 'non-previous' primitive in the set, comparing the pixel samples associated with the primitive to the record to determine whether the primitive requires a depth buffer read. Specifically, if the HSR logic already has the 'best' depth value for all pixel samples associated with the 'non-previous' primitive in the tile (so far), then the full-resolution depth test of the 'non-previous' primitive does not require a depth buffer read.

[0094] In some cases, the previous depth test logic 406 may be configured to update a record in response to identifying a 'previous primitive' to indicate that the HSR logic will have the 'best' depth value so far for all pixel samples associated with the 'previous primitive'. If all pixel samples associated with a 'non-previous' primitive are related to an earlier 'previous' primitive, then full-resolution depth testing of the 'non-previous' primitive does not require a read of the depth buffer because the best depth values for those pixel samples so far will come from either the 'previous' primitive that precedes the primitive in the set or from a 'non-previous' primitive. Specifically, in these cases, two scenarios may occur: Figure 7 , 702, is that a 'non-previous' primitive 706 is completely behind a 'previous' primitive 708, which precedes the 'previous' primitive in the set of primitives; and a second scenario, shown at 704, is that a 'non-previous' primitive 710 is partially behind and partially in front of a 'previous' primitive 712. In either scenario, the 'best' depth value comes from either the 'non-previous' primitive 706, 710, or the 'previous' primitives 708, 712 in the set that precede the 'non-previous' primitive. Therefore, in these situations (where all pixel samples in a tile that are associated with a 'non-previous' primitive (primitive 706 or 710) are also associated with a 'previous' primitive (primitives 708 and 712), there is no need to read the depth buffer to identify the 'best' depth value for those pixel samples so far. Thus, if it is determined that the HSR logic will have the ‘best’ depth values for all pixel samples associated with a ‘non-previous’ primitive, then the ‘non-previous’ primitive can be output to the next stage (e.g., HSR logic) with an indication that full resolution depth testing can be performed without reading the depth buffer.

[0095] In some cases, the front depth test logic 406 may be configured to detect the tile currently being processed by maintaining a Figure 8This is implemented using the pixel sample map 800 shown, which indicates which pixel samples the HSR logic will have the 'best' depth values for that tile so far. Figure 8 In the example shown, the pixel sample map 800 is for a 4×4 tile of pixel samples 802, and for each pixel sample there is a bit that indicates whether the HSR logic will have the 'best' depth value for that pixel sample. In this example, a '0' indicates that the HSR logic may not have the 'best' (e.g., lowest) depth value for that pixel sample so far, and a '1' indicates that the HSR logic will have the 'best' (e.g., lowest) depth value for that pixel sample so far, however, it will be apparent to those skilled in the art that this is merely an example. Thus, in this example, the HSR logic only has the 'best' (e.g., lowest) depth value for pixel samples (3, 2) and (3, 3).

[0096] The previous depth test logic 406 may be configured to, in response to determining that a primitive has a 'better' depth (according to the depth comparison mode) than a primitive previously processed for the tile (i.e., the primitive is a 'previous' primitive), identify pixel samples associated with the 'previous' primitive. If the primitive overlaps with the location of the pixel sample, then the pixel sample may be associated with the primitive. A comparison is then made between the identified pixel samples and the pixel sample map 800. If the pixel sample map 800 indicates that any of the pixel samples identified as being associated with the 'previous' primitive are not marked in the pixel sample map, then the previous depth test logic 406 updates the pixel sample map to indicate that the HSR logic is to have the 'best' depth values for those pixel samples. For example, if Figure 9 As shown, receiving a 'previous' primitive 902 associated with pixel samples (0,0), (0,1), and (1,0), and pixel samples (0,0), (0,1), and (1,0) are not currently marked in the pixel sample map 800, then the pixel sample map 800 is updated to indicate that the HSR logic is to have 'optimal' depth values for pixel samples (0,0), (0,1), and (1,0) to generate an updated pixel sample map 904.

[0097] The tile pixel samples associated with a primitive may be determined in any suitable manner. For example, where the front depth test logic 406 is configured to receive a primitive after it has been rasterized (i.e., after it has been converted into a primitive fragment), the pixel samples associated with the primitive may be based on a primitive fragment for the primitive. For example, rasterizing the primitive converts the primitive into one or more primitive fragments, each of which corresponds to a particular pixel sample. In these cases, the front depth test logic 406 may be configured to determine that a primitive is associated with a particular pixel sample if there is a primitive fragment for the primitive that corresponds to the pixel sample.

[0098] The front depth test logic 406 may then be further configured to, in response to determining that the primitive is a 'non-front' primitive, identify pixel samples in the tile that are associated with the 'non-front' primitive. A comparison is then made between the identified pixel samples and the pixel sample map. If the pixel sample map indicates that the HSR logic has the 'best' depth value (so far) for all pixel samples associated with the 'non-front' primitive, then the front depth test logic 406 identifies the primitive as a 'no depth buffer read' primitive. For example, if Figure 10 As shown, if a 'non-previous' primitive 1002 is received that is associated with pixel samples (0,0), (0,1), (0,2), (1,0), (1,1), and (2,0), and the pixel sample map 1004 indicates that the HSR logic will have 'optimal' depth values for all those pixel samples, then the depth buffer for that tile does not need to be read. However, if Figure 11 'Non-previous' primitive 1102 is shown being received that is associated with pixel samples (0,0), (0,1), (0,2), (0,3), (1,0), (1,1), (1,3), (2,0), (2,1), and (3,0), but the pixel sample map 1104 does not indicate that the HSR logic will have 'optimal' depth values for pixel samples (0,3), (1,2), (2,1), and (3,0), so a read of the depth buffer may be required.

[0099] In some cases, the front depth test logic 406 may be further configured to, upon identifying a primitive that requires a depth buffer read (e.g., a 'non-previous' primitive where the pixel sample map indicates that the HSR logic does not have an 'optimal' depth value for at least one of the pixel samples associated with the 'non-previous' primitive), update a record (e.g., a pixel sample map) to indicate that the HSR logic has 'optimal' depth values for all pixel samples, such that all subsequent primitives will be identified as 'no depth buffer' read primitives. This is because a primitive that requires a depth buffer read will trigger a read of the tile's depth buffer, which means that after processing the primitive, the HSR logic will have 'optimal' depth values for all pixel samples. Therefore, even if a subsequent primitive requires information in the depth buffer to perform full-resolution depth testing on the primitive, the depth buffer information will already be available.

[0100] In some cases, once the front depth test logic 406 has identified primitives in a tile's primitive set as requiring a depth buffer read, the front depth test logic 406 may not be able to perform a coarse front depth test on subsequent primitives in the set. This is because once a primitive in a set has been identified as requiring a depth buffer read, that primitive triggers a depth buffer read, and thus the primitive set cannot avoid a depth buffer read, regardless of whether subsequent primitives require a depth buffer read. Thus, time and resources can be saved by not performing unnecessary coarse front depth tests.

[0101] Where the front depth test logic 406 is configured to maintain a record (e.g., a pixel sample map) of the pixel samples in a tile for which the HSR logic will have the 'best' depth values (so far) and to update the record (e.g., a pixel sample map) after each 'previous' primitive and after primitives that require a depth buffer read, the front depth test logic 406 may additionally or alternatively use the record (e.g., a pixel sample map) to determine whether full resolution depth testing can be skipped for the 'previous' primitive.

[0102] Specifically, in some cases, in response to identifying a primitive as a 'previous' primitive, the previous depth test logic 406 may be configured to identify pixel samples associated with the 'previous' primitive. A comparison is then performed between the identified pixel samples and the pixel sample map. If the pixel sample map indicates that the HSR logic will not have a 'best' depth value (so far) for any of the pixel samples associated with the primitive (i.e., this is the first 'previous' primitive associated with these pixel samples, and the 'previous' primitive is not in the set after the primitive that requires a depth buffer read), then there is no need to perform a full-resolution depth test because the depth value of this primitive will be the 'best' value so far, and therefore the depth value of the primitive in the tile may simply be recorded as the 'best' depth value so far for the corresponding pixel sample.

[0103] However, if the pixel sample map indicates that the HSR logic will have the 'best' depth value (so far) for at least one of the pixel samples associated with the 'previous' primitive (i.e., the pixel sample is associated with an earlier 'previous' primitive in the set, or the primitive is after the primitive in the set that requires a depth buffer read), then full-resolution depth testing may need to be performed on these pixel samples. In these cases, if the previous depth test logic 406 determines that the 'previous' primitive does not require a full-resolution depth test, then the 'previous' primitive may be output with an indication that a full-resolution depth test is not required. The indication may take any suitable form. For example, in some cases, the indication may be a flag that may be set when a full-resolution depth test is required and may not be set when it is not required.

[0104] Identifying primitives that do not require full-resolution depth testing saves time and resources from reading depth values from the depth buffer and performing unnecessary full-resolution depth testing.

[0105] When performing a coarse front depth test after rasterization (i.e., after primitives have been converted into primitive fragments), the depth buffer read and / or full-resolution depth test determination may be performed on a per-primitive-fragment basis rather than on a per-primitive basis. For example, in some cases, the front depth test logic 406 may be configured to determine whether each primitive fragment associated with a tile in a set of primitive fragments (e.g., a set of primitive fragments corresponding to primitives identified in a partial display list) has a better depth value than a primitive previously processed for the tile, rather than the front depth test logic 406 being configured to determine whether each primitive associated with a tile in a set of primitive fragments has a better depth value than a primitive previously processed for the tile.

[0106] In these situations, the front depth test logic 406 may be configured to determine whether a primitive fragment has a 'better' depth than a primitive previously processed for the tile by comparing the primitive fragment's depth to the tile's depth range. For example, when the coarse depth test logic 320 is operating in DCM_LESS mode, if the primitive fragment's depth (e.g., Z value or Z coordinate) is less than the tile's minimum depth, then the primitive fragment may be determined to have a 'better' depth value than a primitive previously processed for the tile. If the front depth test logic 406 determines that the primitive fragment has a 'better' (e.g., smaller) depth than a primitive previously processed for the tile, then (for the reasons described above) the front depth test logic 406 may identify the primitive fragment as a primitive fragment for which full-resolution depth testing (e.g., performed by HSR logic) may be performed without reading the tile's depth buffer. Such a primitive fragment may be referred to herein as a 'previous' primitive fragment. Primitive fragments that do not have a 'better' depth than a primitive previously processed for a tile may be referred to herein as 'non-previous' primitive fragments.

[0107] In these situations, the front depth test logic 406 may be configured to maintain a record (e.g., a pixel sample map) of pixel samples in the tile for which the HSR logic will have the 'best' depth value (so far). The front depth test logic 406 may be configured to update the record after identifying a 'previous' primitive fragment to indicate that the HSR logic will have the 'best' depth value for the pixel samples associated with the 'previous' primitive fragment. The front depth test logic 406 may also be configured to update the record after identifying a 'depth buffer read' primitive fragment to indicate that the HSR logic will have the 'best' depth value for each pixel sample in the tile. The front depth test logic 406 may then be configured to determine, in response to identifying a 'non-previous' primitive fragment, whether the 'non-previous' primitive fragment can avoid a depth buffer read based on the record. For example, the preceding depth test logic 406 may be configured to determine that a 'non-previous' primitive fragment does not require a 'depth buffer' read if a record (e.g., a pixel sample map) indicates that the HSR logic will have an 'optimal' depth value for pixel samples associated with the primitive fragment. If the preceding depth test logic 406 determines from the record that a 'non-previous' primitive fragment does not require a depth buffer read, the 'non-previous' primitive fragment may be identified as a 'no depth buffer read' primitive fragment. However, if the record does not indicate that the HSR logic will have an optimal depth value for the 'non-previous' primitive fragment, the preceding depth test logic 406 may be configured to identify the 'non-previous' primitive fragment as a 'depth buffer read' primitive fragment.

[0108] Where the preceding depth test logic 406 is configured to maintain a record (e.g., a pixel sample map) of pixel samples in a tile for which the HSR logic has the 'best' depth value (so far), the record may be used to determine whether full-resolution depth testing needs to be performed on the 'previous' primitive fragment. For example, in some cases, if the record indicates that the HSR logic does not have the 'best' depth value for pixel samples associated with the 'previous' primitive fragment, then the 'previous' primitive fragment may be identified as a 'no depth buffer test' primitive fragment.

[0109] The depth range update logic 408 is configured to update the depth range of a tile as primitives / primitive fragments associated with the tile are processed. In some cases, the depth range update logic 408 may be configured to update the depth range of the tile after the set of primitives / primitive fragments associated with the tile has been completely processed by the coarse depth test logic 320. For example, in some cases, the depth range update logic 408 may be configured to track the current 'best' depth value for the tile currently being processed, and when the coarse depth test logic 320 has completed processing the set of primitives / primitive fragments associated with the tile (i.e., has performed a coarse hidden depth test and a coarse front depth test on each primitive / primitive fragment in the set), the depth range update logic 408 may be configured to update the memory 402 with the current 'best' depth value.

[0110] For example, in some cases, when the current depth test logic 406 identifies a 'previous' primitive or a 'previous' primitive fragment from the primitive set, the previous depth test logic 406 may provide the 'best' depth value of the 'previous' primitive or the 'previous' primitive fragment to the depth range update logic 408 (e.g., where the DCM_LESS depth test mode is used, the 'best' depth value is the lowest depth value or the minimum depth value). The depth range update logic 408 may then determine whether the 'best' depth value for the tile has already been received from the previous depth test logic 406. If the depth range update logic 408 has not yet received the 'best' depth value for this tile from the previous depth test logic 406, the depth range update logic 408 may record or store the received depth value as the current 'best' depth value for the tile. If the depth range update logic 408 has received a 'best' depth value for a tile from the previous depth test logic 406, the depth range update logic may compare the received 'best' depth value with the stored current 'best' depth value for the tile to determine which is better. If the received 'best' depth value is better than the stored current 'best' depth value, the stored current 'best' depth value is updated with the received value. For example, where the DCM_LESS depth test mode is used, the depth range update logic 408 may determine whether the received depth value is less than the current 'best' depth value, and if so, update the current 'best' depth value with the received depth value.

[0111] When the coarse depth test logic has processed all primitives / primitive fragments in the set, the depth range update logic 408 may write the current 'best' depth value for the tile to the memory 402 .

[0112] In some cases, the HSR logic may be configured to determine whether the HSR logic has 'best' depth values for all pixel samples in a tile (e.g., a current best depth value buffer has a depth value for each pixel sample in the tile) after it completes processing a partial display list for the tile (e.g., primitive fragments associated with primitives identified in the partial display list). The HSR logic may include 'best' depth values for all pixel samples in the tile if: (a) processing the partial display list has resulted in a depth value update for each of the pixel samples in the tile; or (b) a depth buffer read has been performed on the tile. If a depth buffer read has not been performed on the tile and not all depth values in the tile have been updated by processing the partial display list, the HSR logic may not include 'best' depth values for all pixel samples in the tile. If the HSR logic determines that it includes the ‘best’ depth value for all pixel samples in the tile, the HSR logic may identify the ‘worst’ (e.g., maximum) depth value for the tile and send a message or command to the coarse depth test logic 320 to update the depth range for the tile to reflect the ‘worst’ (e.g., maximum) depth value for the tile.

[0113] In some cases, such as Figure 4 As shown, the coarse depth test logic 320 may receive information (e.g., a partial display list) identifying a set of primitives that fall within the bounds of a tile. In these cases, the coarse depth test logic 320 may also include fetch logic 412 configured to receive the partial display list and, for each partial display list, fetch corresponding transformed geometry data (e.g., a transformed geometry data buffer) for the primitives identified in the partial display list from memory and provide the associated transformed geometry data to the hidden depth test logic 404. However, in other cases, the coarse depth test logic 320 may directly receive transformed geometry data for a set of primitives / primitive fragments associated with a tile.

[0114] It should be noted that in some cases, there may be some primitives for which the HSR logic will not perform hidden surface removal. Examples of such primitives include primitives such as punch-through primitives whose primitive visibility is shader-dependent and depth feedback primitives with shader-dependent depth values. In these cases, the coarse depth test logic 320 may be configured to simply pass any such primitives through. In other words, if the coarse depth test logic 320 determines that a received primitive is a primitive for which hidden surface removal will not be performed by the HSR logic, then the coarse depth test logic 320 may not perform a coarse hidden depth test or a coarse pre-depth test on the primitive.

[0115] Now refer to Figure 12 , which illustrates an example method 1200 for performing a coarse depth test on a primitive in a graphics processing system before performing a full-resolution depth test, which may be performed by Figure 4 The method 1200 begins at block 1202, where the coarse depth test logic 320 receives a set of primitives associated with a tile. Receiving a primitive may include receiving data defining the primitive (e.g., transformed geometry data or primitive fragment data). A primitive is said to be associated with a tile if it falls at least partially within the bounds of the tile. The set of primitives may, for example, be a set of primitives in a partial display list. Once the set of primitives has been received, the method 1200 proceeds to block 1204.

[0116] At block 1204, a depth range is obtained for the tile. As described above, the depth range represents a depth range associated with the tile based on primitives previously processed for the tile (e.g., primitives in a previous partial display list for the tile). Specifically, the depth buffer for the tile is used to record the 'best' (e.g., lowest) depth value for each pixel sample in the tile, where the current 'best' (e.g., lowest) depth value for a pixel sample is the depth value of the currently unhidden or visible primitive fragment at that pixel sample. The depth range may be defined by a maximum depth value and a minimum depth value, where the minimum depth value for the tile is the minimum 'best' depth value (so far) for the tile, and the maximum depth value for the tile is the maximum 'best' depth value (so far). In other words, the minimum depth value for the tile is the minimum depth value of unhidden primitive fragments in the tile based on primitives previously processed for the tile, and the maximum depth value for the tile is the maximum depth value of unhidden primitive fragments in the tile based on primitives previously processed for the tile. In some cases, the depth range of each tile may be stored in a memory (e.g., memory 402), and obtaining the depth range of the tile may include reading the depth range of the relevant tile from the memory. Once the depth range of the tile is obtained, the method 1200 proceeds to block 1206.

[0117] At block 1206, one of the primitives in the set is selected as the current primitive. In some cases, the primitives in the set may be received in a particular order and may be processed in the order in which they were received. Once one of the primitives in the set has been selected as the current primitive, method 1200 proceeds to block 1208.

[0118] At block 1208, based on the depth range of the tile, a determination is made as to whether the current primitive is hidden by primitives previously processed for the tile at all locations in the tile that overlap with the current primitive. As described above, this determination can be made by comparing the depth range of the tile to the maximum depth or minimum depth of the primitives in the tile. For example, using the DCM_LESS depth comparison mode, if the minimum depth of a primitive in the tile is greater than the maximum depth of the tile, then the primitive can be determined to be hidden in the tile by primitives previously processed for the tile. Any suitable method can be used to determine the maximum depth and / or minimum depth of a primitive in a tile. An example method for determining the maximum depth and / or minimum depth of a primitive in a tile when making this determination prior to rasterization is described below. If it is determined that the primitive is hidden, then method 1200 proceeds to block 1210, in which no further processing is performed on the current primitive relative to the current tile (e.g., no full-resolution depth test is performed on the primitive relative to the current tile). However, if it is not determined in block 1208 that the primitive is hidden, then the method 1200 proceeds to block 1212 .

[0119] At block 1212, a determination is made based on the depth range of the tile whether the current primitive has a 'better' depth than a previously processed primitive for the tile at all locations in the tile that overlap the current primitive. As described above, this determination can be made by comparing the depth range of the tile to the maximum or minimum depth of the primitives in the tile. For example, using the DCM_LESS depth comparison mode, if the maximum depth of a primitive in the tile is less than the minimum depth of the tile, then the primitive can be determined to have a 'better' depth than a previously processed primitive for the tile. The maximum and / or minimum depth of a primitive in the tile can be determined using any suitable method. For example, when the 'before' determination is made after rasterization, the maximum or minimum depth of a primitive in the tile can be the maximum or minimum depth, respectively, of the primitive fragments of the primitive that fall within the tile. If the primitive is not determined to have a 'better' depth than a previously processed primitive for the tile, method 1200 proceeds to block 1214, where the primitive is output for further processing. For example, as described above, the primitive may be provided to the HSR logic for processing. However, if it is determined at block 1212 that the primitive has a 'better' depth than a primitive previously processed for the tile at all locations of the tile that overlap with the current primitive, then the method 1200 proceeds to block 1216.

[0120] At block 1216, the primitive is identified as a 'no depth buffer read' primitive. Specifically, as described above, if the primitive has a better (e.g., smaller) depth than a primitive previously processed for the tile according to the depth comparison mode (e.g., DCM_LESS), then the optimal depth for the pixel samples associated with the primitive will be the depth value of the primitive or earlier 'previous' primitive in the set, and thus, the 'optimal' depth values for those pixel samples can be determined without reading the tile's depth buffer. Method 1200 then proceeds to block 1214, where the primitive is output for further processing (using the identification).

[0121] After block 1214, the method 1200 proceeds to block 1218, where it is determined whether at least one primitive remains in the set that has not been processed. If at least one primitive remains in the set of primitives for the current tile that has not been processed, the method 1200 returns to block 1206, where the next primitive in the set is selected and blocks 1208 to 1216 are repeated for that primitive. However, if all primitives in the set have been processed, the method 1200 proceeds to block 1220.

[0122] The depth range of the tile is updated to reflect any changes in the tile range due to primitives in the set at block 1220. For example, in some cases, if any primitive is determined to be 'ahead' of a primitive previously processed for the tile, there will be a 'better' (e.g., lower) depth value for the tile, and the depth range of the tile is updated using the 'best' (e.g., lowest) depth value of those depth values.

[0123] As described above, in some cases, the HSR logic may be configured to determine whether the HSR logic has a 'best' depth value for all pixel samples in a tile (e.g., a current best depth value buffer having a depth value for each pixel sample in the tile) once it has processed a partial display list for the tile (e.g., primitive fragments associated with primitives identified in the partial display list). The HSR logic may include the 'best' depth values for all pixel samples in the tile if: (a) processing the partial display list has resulted in a depth value update for each of the pixel samples in the tile; or (b) a depth buffer read has been performed on the tile. If a depth buffer read has not been performed on the tile and not all depth values in the tile have been updated by processing the partial display list, the HSR logic may not include the 'best' depth values for all pixel samples in the tile. If the HSR logic determines that it includes the ‘best’ depth value for all pixel samples in the tile, the HSR logic may identify the ‘worst’ (e.g., maximum) depth value for the tile and send a message or command to the coarse depth test logic 320 to update the depth range for the tile to reflect the ‘worst’ (e.g., maximum) depth value for the tile.

[0124] Method 1200 then ends.

[0125] Although method 1200 has been described as receiving all primitives in a set of primitives for a tile before performing a coarse hidden depth test and a coarse front depth test on individual primitives, it will be apparent to those skilled in the art that this is merely an example, and in other examples, primitives may arrive sequentially, and as soon as a primitive is received, a coarse hidden depth test may be performed on the primitive, and a coarse front depth test may be performed on the primitive, if desired. In other words, a coarse hidden depth test and / or a coarse front depth test may be performed on the primitives in the set before all primitives in the set have been received.

[0126] As described above, in some cases, a record (e.g., a pixel sample map) is maintained of the pixel samples in a tile for which the HSR logic will have the 'best' depth values, and if a primitive is not determined to have a 'better' depth than a primitive previously processed for the tile (i.e., the primitive is a 'non-previous' primitive), another test based on the record is performed on the 'non-previous' primitive to determine whether the 'non-previous' primitive can avoid a depth buffer read. In some cases, the record may be updated after identifying a 'previous' primitive to indicate that after processing the 'previous' primitive, the HSR logic will have the 'best' depth values for the pixel samples associated with the 'previous' primitive in the tile. In some cases, the record may also be updated after identifying a primitive that requires a depth buffer read to indicate that after processing the depth buffer read primitive, the HSR logic will have the 'best' depth values for all pixel samples in the tile.

[0127] Now refer to Figure 13 , which shows that you can add to Figure 12 The method 1200 is an optional block for implementing this method. Specifically, Figure 13 As shown, if Figure 12 If it is determined at block 1212 of method 1200 that a primitive does not have a 'better' depth than a primitive previously processed for the tile (i.e., if the primitive is determined to be a 'non-previous' primitive), method 1200 may proceed to block 1302, where a record of pixel samples in the tile for which the HSR logic has the 'best' depth value (so far) is obtained (e.g., a pixel sample map). Once the record has been obtained, method 1200 proceeds to block 1304, where the pixel samples associated with the primitive are identified. As described above, if a primitive overlaps with a pixel sample location, then the pixel sample is associated with the primitive. The pixel samples associated with the primitive for the tile may be determined in any suitable manner. For example, if block 1304 is performed after rasterization of a primitive, then one or more primitive fragments may exist for the primitive, each of which corresponds to a particular pixel sample. In these cases, if a primitive fragment exists that corresponds to a particular pixel sample, then the primitive is associated with the pixel sample.

[0128] Once the pixel samples associated with the primitive for the tile have been identified, the method 1200 proceeds to block 1306, where a determination is made as to whether a record (e.g., a pixel sample map) indicates that the HSR logic will have a 'best' depth value for each of the pixel samples associated with the primitive (indicating that each pixel sample associated with the primitive is associated with an earlier 'previous' primitive in the set, or (optionally) that the primitive is after the depth buffer read primitive in the set). If it is determined that the HSR logic will have a 'best' depth value for all pixel samples associated with the primitive, then a depth buffer read is not required for this primitive, and the method 1200 proceeds to block 1216, where the primitive is identified as a no-depth-buffer-read primitive. As described above, this is because if all pixel samples associated with a 'non-previous' primitive are related to at least one 'previous' primitive, then when the primitive is processed by the HSR logic, the 'best' depth value for those pixel samples will be the depth value of the 'non-previous' primitive or one of the previous 'previous' primitives, and thus no value in the depth buffer is needed to identify the 'best' depth value for those pixel samples; or (optionally) if the primitive follows the depth buffer read primitive, then when the primitive is processed by the HSR logic, the HSR logic will have the 'best' depth values for all pixel samples.

[0129] However, if it is determined at block 1306 that the HSR logic will not have a 'best' depth value for at least one pixel sample associated with the primitive, then the primitive is a 'depth buffer read' primitive and the method 1200 proceeds to block 1214 where the primitive is output for further processing. In some cases, after determining that the primitive is a 'depth buffer read' primitive and before proceeding to block 1214, the method 1200 may proceed to block 1308 where a record (e.g., a pixel sample map) is updated to indicate that the HSR logic will have a 'best' depth value for all pixel samples in the tile. This is because the 'depth buffer read' primitive will trigger a depth buffer read, so after processing the depth buffer read primitive, the HSR logic will have a current 'best' depth value for all pixel samples in the tile.

[0130] If in Figure 12 If it is determined at block 1212 of method 1200 that a primitive has a 'better' depth than a previously processed primitive for the tile, then method 1200 may proceed to block 1310 before proceeding to block 1216. At block 1310, a record (e.g., a pixel sample map) indicating which pixel samples of the tile the HSR logic is to have the 'best' depth values for is updated such that the record indicates that the HSR logic is to have the 'best' depth value for each of the pixel samples associated with the 'previous' primitive.

[0131] Wherein the coarse depth test logic 320 maintains a record (e.g., a pixel sample map) of pixel samples in a tile for which the HSR logic will have a maintained 'best' depth value; and updates the record (e.g., a pixel sample map) after identifying a 'previous' primitive to indicate that the HSR logic will have a 'best' depth value for each of the pixel samples in the tile associated with the 'previous' primitive, and updates the record after identifying a depth buffer read primitive to indicate that the HSR logic will have a 'best' depth value for all pixel samples in the tile; and another record-based test may then be performed on the record-based 'previous' primitive to determine whether the 'previous' primitive can avoid full-resolution depth testing.

[0132] Now refer to Figure 14 , which shows that you can add to Figure 12 The method 1200 is an optional block for implementing this method. Specifically, Figure 14 As shown, if Figure 12 If it is determined at block 1212 of method 1200 that a primitive is a 'previous' primitive (i.e., the primitive has a better (e.g., smaller) depth than a primitive previously processed for the tile), method 1200 may proceed to block 1402, where a record (e.g., a pixel sample map) of pixel samples in the tile for which the HSR logic has the 'best' depth value is obtained. Once the record has been obtained, method 1200 proceeds to block 1404, where the pixel sample associated with the 'previous' primitive is identified. As described above, if a primitive overlaps with a pixel sample's location, then the pixel sample is associated with the primitive. The pixel sample associated with the primitive for the tile may be determined in any suitable manner. For example, if block 1404 is performed after rasterization of the 'previous' primitive, then one or more primitive fragments may exist for the primitive, each of which corresponds to a particular pixel sample. In these cases, if a primitive fragment exists that corresponds to a particular pixel sample, then the primitive is associated with the pixel sample.

[0133] Once the pixel samples associated with the 'previous' primitive of the tile have been identified, the method 1200 proceeds to block 1406, where a determination is made as to whether the record (e.g., pixel sample map) indicates that the HSR logic has an 'optimal' depth value for any of the pixel samples associated with the primitive (i.e., any of the pixel samples associated with the primitive is associated with at least one earlier 'previous' primitive in the set, or the 'previous' primitive is after the depth buffer reading primitive in the set). If it is determined at block 1406 that the HSR logic will not have an 'optimal' depth value for any of the pixel samples associated with the primitive (i.e., none of the pixel samples associated with the 'previous' primitive is associated with an earlier 'previous' primitive in the set, and the primitive is not after the depth buffer reading primitive in the set), then this 'previous' primitive does not require a full-resolution depth test, and the method 1200 proceeds to block 1408, where the primitive is identified as a 'no depth test' primitive, and then proceeds to block 1410. As described above, this is because if the pixel samples associated with a 'previous' primitive are unrelated to any earlier 'previous' primitive and the primitive is not after a 'depth buffer read' primitive, then the 'best' depth value so far for these pixel samples is the depth value from this primitive, and the depth value of this primitive can be directly recorded as the best depth value so far.

[0134] If it is determined at block 1406 that the HSR logic will have a 'best' depth value for at least one of the pixel samples associated with the primitive, then a full-resolution depth test may be required, and the method 1200 proceeds to block 1410, where a record (e.g., a pixel sample map) is updated so that the record indicates that the HSR logic will have a 'best' depth value for each of the pixel samples associated with the 'previous' primitive. After block 1410, the method 1200 proceeds to block 1216, where the primitive is identified as a 'no depth buffer read' primitive.

[0135] If in Figure 12 If it is determined at block 1212 of method 1200 that the primitive is a depth buffer read primitive, then method 1200 may proceed to block 1412 where a record (e.g., a pixel sample map) is updated to indicate that the HSR logic will have an 'optimal' depth value for all pixel samples in the tile. Next, method 1200 proceeds to block 1214.

[0136] In some cases, instead of performing a hidden depth test on a primitive basis, a hidden depth test may be performed on a primitive fragment basis. For example, in some cases, primitives may be converted (i.e., rasterized) into primitive fragments before being provided to the hidden depth test logic 404, such that the hidden depth test logic 404 receives a set of primitive fragments associated with a tile. Next, for each primitive fragment in the set, the hidden depth test logic 404 may be configured to determine whether the primitive fragment is hidden in the tile by a primitive previously processed for the tile. When implementing DCM_LESS mode, if the depth value of the primitive fragment is greater than the tile maximum depth value defined by the tile's depth range, the primitive fragment may be determined to be hidden in the tile by a primitive previously processed for the tile. If the primitive fragment is determined to be hidden in the tile, no further processing of the primitive fragment may be performed with respect to the tile. However, if the primitive fragment is determined not to be hidden in the tile, the primitive fragment may be output to the front depth test logic 406.

[0137] In some cases, instead of performing a no-depth-buffer read and / or no-full-resolution depth test determination on a primitive basis, a no-depth-buffer read and / or no-full-resolution depth test determination may be performed on a primitive fragment basis. For example, after a primitive has passed the coarse hidden depth test, the primitive may be converted (i.e., rasterized) into one or more primitive fragments that are provided to the pre-depth test logic 406, or the primitives in the set may be converted (i.e., rasterized) into primitive fragments before the coarse hidden depth test, and any primitive fragments that pass the coarse hidden depth test may be provided to the pre-depth test logic 406. Then, for each primitive fragment received, the coarse pre-depth test logic may determine whether the primitive fragment has a better depth value than a primitive previously processed for the tile. When DCM_LESS mode is implemented, a primitive fragment may be determined to have a 'better' depth value than a primitive previously processed for the tile if the primitive fragment's depth value is less than the tile minimum depth value defined by the tile's depth range. If a primitive fragment is determined to have a 'better' depth value than a primitive previously processed for a tile, the primitive fragment may be identified as a 'no depth buffer read' primitive fragment. In some cases, a record is maintained of which HSR logic will have the 'best' depth value for the pixel samples of a tile (e.g., the pixel sample map described above). In these cases, if a primitive fragment is not determined to have a 'better' depth value than a primitive previously processed for a tile (i.e., a 'non-previous' primitive fragment), a determination may be made as to whether the primitive fragment is a 'no depth buffer read' primitive fragment based on the record. For example, if the record indicates that the HSR logic will have the 'best' depth value for the pixel samples associated with the primitive fragment, the 'non-previous' primitive fragment may be identified as a 'no depth buffer read' primitive fragment. In some cases, if a primitive fragment is determined to have a better depth than a primitive previously processed for a tile (i.e., a 'previous' primitive fragment), a determination may be made as to whether the 'previous' primitive fragment is a 'no depth test' primitive fragment based on the record. For example, in some cases, a primitive fragment may be identified as a 'no depth test' primitive fragment if records indicate that the HSR logic does not have an 'optimal' depth value for pixel samples associated with a 'previous' primitive fragment.

[0138] Example method for determining a maximum depth value and / or a minimum depth value for primitives in a tile

[0139] Example methods for determining the maximum depth value and / or minimum depth value of a primitive in a tile prior to rasterization of the primitive will now be described. Any of these methods may be used by Figure 4 The hidden depth test logic 404 and / or the front depth test logic 406 of the coarse depth test logic 320 are used. In these examples, it is assumed that the primitives are planar.

[0140] In primitive 1502 such as Figure 15 In a first example method used when the primitive 1502 is completely within the tile 1504, the maximum depth or minimum depth of the primitive 1502 in the tile 1504 can be estimated as the maximum depth or minimum depth of the vertices 15061, 15062, and 15063 of the primitive 1502. Whether the primitive 1502 is completely within the tile 1504 can be determined by defining a bounding box (e.g., an axis-aligned bounding box) around the primitive and determining whether the bounding box is completely within the bounds of the tile. As known to those skilled in the art, a bounding box is the lowest or minimum bounding or enclosing axis-aligned box of a set of points, within which all points are located. Thus, the bounding box of a primitive can be defined as the smallest axis-aligned rectangle (where "rectangle" includes "square") that encompasses all of the vertices.

[0141] In primitive 1602 such as Figure 16 In a second example method shown for use when not entirely within a tile 1604 , the maximum depth or minimum depth of a primitive 1602 in a tile 1604 may be estimated as the maximum depth or minimum depth of the following for the primitive 1602 :

[0142] The intersection points 16061, 16062 of the edges of the primitives and the edges of the tiles 1604;

[0143] A primitive 1602 with a tile 1604 at the location of a corner 1608 within the primitive 1602; and

[0144] ●Vertices 1610 of primitive 1602 within tile 1604.

[0145] In a third example method, the maximum depth or minimum depth of a primitive in a tile may be estimated as:

[0146] If a primitive completely covers a tile, then the maximum or minimum depth of the primitive in the tile is estimated as the maximum or minimum depth of the primitive at the corner locations of the tile; and

[0147] • If the primitive does not fully cover the tile, the plane of the primitive is extended to the corners of the tile, and the maximum or minimum depth of the primitive in the tile is estimated to be the maximum or minimum depth at the location of the tile corners within the extended plane.

[0148] Specifically, if Figure 17 As shown, each primitive 1702 is on a plane 1703, which can be defined as the interior of planes 17061, 17062, 17063 where the edges of the primitive 1702 lie. Figure 17As shown, triangle primitive 1702 can be defined as the interior of three planes 17061, 17062, and 17063, where the edges of the triangle lie. The depth of any point (x, y) on plane 1703 where the triangle primitive lies is equal to Ax+By+C, where x is the x-coordinate, y is the y-coordinate, and A, B, and C are coefficients. As is well known, coefficients A, B, and C can be determined based on the coordinates (x, y, z) of the vertices 17081, 17082, and 17083 of the triangle primitive. Therefore, the depth of plane 1703 at corner positions 17101, 17102, 17103, and 17104 of tile 1704 can be determined based on Ax+By+C.

[0149] In some cases, a rasterizer (e.g., rasterizer 312) may be configured to determine the depth of a primitive fragment by calculating A, B, and C from the primitive's vertices and then calculating Ax + By + C. In these cases, determining the maximum or minimum depth of a primitive in a tile in this manner may be efficient because the hardware is already able to determine A, B, and C for the primitive.

[0150] It should be noted that, in general, pixel sample points of a tile will not lie on tile boundaries (and, in particular, on tile corners), nor will they generally align perfectly with primitive vertices. Therefore, the maximum or minimum depth of a primitive in a tile is estimated based on the depth of the primitive at the corners of the tile (or the depth of the extended plane on which the primitive lies), the depth of the primitive at the intersection of the primitive edge with the tile edge, and / or the primitive's vertices. This may cause the estimated maximum depth of a primitive in a tile to be higher than the actual maximum depth of any of the primitive fragments generated for the primitive in the tile, or the estimated minimum depth of a primitive in a tile to be lower than the actual minimum depth of any of the primitive fragments generated for the primitive in the tile. Therefore, these estimates are conservative, meaning that a primitive may not be culled by the coarse depth test logic even if it could have been culled, but if the primitive should not have been culled, then it will not be culled by the coarse depth test logic. Because the rasterization logic can still generate correct raster output if primitives that should have been culled are not culled, but may not generate correct raster output if primitives that should not have been culled are culled, the rasterization logic is still able to generate correct raster output using conservative estimates implemented by the coarse depth test logic.

[0151] It will be apparent to those skilled in the art that these are merely example methods and that the maximum and minimum depths of primitives in a tile may be determined / estimated in any suitable manner.

[0152] Test results

[0153] Now refer to Figure 18, which shows that before performing full-resolution depth testing, Figure 12 When the method 1200 performs a coarse depth test, the depth buffer fetch bandwidth of several graphics processing system benchmarks is reduced. It can be seen that for all benchmarks, the depth buffer fetch bandwidth is reduced, and for some benchmarks, the depth buffer fetch bandwidth is reduced by almost 90%.

[0154] Slow and fast rasterization queues

[0155] As described above, reading the depth buffer of a tile from memory only when the HSR logic already has information to identify the 'best' depth for pixel samples associated with the primitive / primitive fragment can significantly reduce the number of depth buffer reads performed. However, since the depth buffer is not automatically pre-fetched, this can cause latency issues in the rasterization stage. Specifically, if a primitive fragment received by the HSR logic requires a depth buffer read and the depth buffer is not in the depth buffer cache 1902, then a read of the depth buffer memory 1904 is performed. There can be significant latency associated with reading the depth buffer memory 1904. Therefore, in order to ensure that the HSR logic is not stalled while waiting for a depth buffer memory read to be performed, the queue 1906 (e.g. Figure 19 A queue 1906 (shown in FIG. 1904 ) can be inserted between the coarse depth test logic 320 and the HSR logic 314 to store a certain number of primitive fragments that have been output by the coarse depth test logic. This allows the HSR logic 314 to keep processing primitive fragments while performing a depth buffer memory read for one primitive fragment (or set of primitive fragments) in the queue 1906. However, testing has indicated that in order to mask the latency associated with the depth buffer memory read, the queue 1906 must be quite large (e.g., testing has indicated that in some cases, the queue 1906 may need to be able to store data for one hundred primitive fragments to mask the latency associated with the depth buffer memory read).

[0156] Therefore, there is a need to mask the latency associated with depth buffer memory reads without such a large queue 1906. The inventors have determined that the queue 1906 can be more efficiently implemented as two queues, where only primitive fragments identified as not requiring a depth buffer read are placed in a priority queue, and any primitive fragments identified as requiring a depth buffer read are placed in a non-priority queue. The HSR logic 314 can be configured to prioritize primitive fragments in the priority queue over primitive fragments in the non-priority queue. In some cases, as described in more detail below, the HSR logic 314 can be configured to process only primitive fragments in the non-priority queue if the priority queue is empty, unless one or more exception conditions are met. Prioritizing primitive fragments in the priority queue allows for more efficient masking of latency associated with depth buffer memory reads than with a single queue.

[0157] although Figures 20 to 22 The system and method are described as being used in a hybrid rendering graphics processing system, but their use is not limited to hybrid rendering graphics processing systems, and in other examples, the system and method can be used or implemented in other graphics processing systems.

[0158] Now refer to Figure 20 , which illustrates an example system 2000 for processing primitive fragments in the rasterization stage of a hybrid rendering graphics processing system. The system 2000 includes logic 2002 for receiving primitive fragments to be rendered and determining whether a depth buffer read is required to perform full-resolution hidden surface removal for at least some of the received primitive fragments; a priority queue 2004; a non-priority queue 2006; and HSR logic 2008 for performing full-resolution hidden surface removal on the primitive fragments in queues 2004 and 2006.

[0159] The logic 2002 is configured to: receive primitive fragments to be rendered, each primitive fragment being associated with a tile; determine, for at least some of the received primitive fragments, whether a depth buffer read is required to perform full resolution hidden surface removal on the primitive fragments of the associated tile; and sort the primitive fragments into a queue based on the depth buffer read determination. The logic 2002 may determine whether a primitive fragment requires a depth buffer read in any suitable manner. For example, the logic 2002 may be configured to determine whether a primitive / primitive fragment requires a depth buffer read according to any of the methods described above with respect to the coarse depth test logic 320. For example, the logic 2002 may be configured to: perform a coarse hidden depth test on a per-primitive basis or a per-primitive fragment basis; and / or perform a coarse pre-depth test on a per-primitive or per-primitive fragment basis to determine whether a depth buffer read is required. In some examples, for example Figure 20As shown, logic 2002 may be implemented as the coarse depth test logic described above (e.g., coarse depth test logic 320), which may further include sorting logic (not shown) for sorting primitives into queues 2004, 2006 based on depth buffer read determinations.

[0160] In some cases, the logic 2002 may be configured to place only primitive fragments that do not require a depth buffer read in the priority queue 2004 and primitive fragments that do require a depth buffer read in the non-priority queue 2006. In some cases, the logic 2002 may also be configured to place any primitive fragment in a set of primitive fragments for a tile (e.g., primitive fragments corresponding to primitives in a partial display list) in the non-priority queue 2006 if a previous primitive fragment in the set has been identified as requiring a depth buffer read. In other words, in some cases, once one primitive fragment in a set of primitive fragments associated with a tile (e.g., primitive fragments corresponding to primitives in a partial display list) has been placed in the non-priority queue 2006, all subsequent or subsequent primitive fragments in the set may be placed in the non-priority queue. This can be advantageous because, generally speaking, primitive fragments associated with a tile will be processed in the order they are received, and therefore, once a primitive fragment in the set of primitive fragments associated with a tile requires a depth buffer read, all subsequent primitive fragments must also wait for the depth buffer read to complete. Figure 21 An example method for sorting primitive fragments into queues is described, which may be implemented by logic 2002 .

[0161] In some cases, the logic 2002 may be configured to place a primitive fragment in the queues 2004, 2006 by adding information or data defining the primitive fragment (e.g., its coordinates (X, Y, and Z)). In other cases, the logic 2002 may be configured to place / store the primitive fragment in the queue by placing or adding information to the queue identifying the primitive fragment (e.g., a primitive fragment identifier). The information or data defining the primitive (e.g., its coordinates (X, Y, and Z)) may be stored in memory (e.g., a buffer). In these cases, the HSR logic may be configured to retrieve the information or data defining the primitive (e.g., its coordinates (X, Y, and Z)) from memory once it has selected the primitive fragment from the queue using the information identifying the primitive fragment (e.g., the primitive fragment identifier). In some cases, the primitive fragment identifier and / or the information or data defining primitive fragments associated with the same primitive may be stored together in the queue.

[0162] In some cases, the logic 2002 may be configured to, in response to placing the first primitive fragment in the set of primitive fragments associated with a tile in the non-priority queue, begin reading the depth buffer for the tile from the memory 2010. In some cases, this may require sending a request for the depth buffer for the tile to the depth buffer cache 2012, and if the depth buffer cache 2012 does not include the requested depth buffer, reading the depth buffer from the memory 2010.

[0163] The HSR logic 2008 is configured to perform full-resolution hidden surface removal on primitive fragments in queues 2004 and 2006, with priority being given to primitive fragments in the priority queue. Giving priority to primitives in the priority queue generally means that primitive fragments in the priority queue 2004 are processed before primitive fragments in the non-priority queue 2006. Specifically, in some cases, the HSR logic 2008 may be configured to only process primitive fragments in the non-priority queue 2006 if no primitive fragments are present in the priority queue 2004, unless one or more exception conditions are met. One or more exception conditions that may allow the HSR logic 2008 to process primitive fragments in the non-priority queue 2006 when the priority queue 2004 is not empty may include one or more of the following: the first / top primitive fragment in the non-priority queue 2006 is associated with a tile in the depth buffer cache 2012; the depth buffer cache 2012 is full (or almost full); and the number of primitive fragments in the non-priority queue 2006 exceeds a threshold (e.g., the non-priority queue 2006 becomes overfull). Figure 22 An example method for selecting primitive fragments from the queues 2004 , 2006 , which may be implemented by the HSR logic 2008 , is described.

[0164] Now refer to Figure 21 , which illustrates an example method 2100 for sorting primitive fragments into a priority queue 2004 and a non-priority queue 2006. The method 2100 begins at block 2102, where the logic 2002 (e.g., the coarse depth test logic 320) receives a primitive fragment. The primitive fragment can be part of a set of primitive fragments associated with a particular tile (e.g., the primitive fragment can be one of one or more primitive fragments corresponding to a primitive in a partial display list or generated by the primitive). As described above, the primitive fragment can be received at the logic 2002 when data identifying and / or defining the primitive fragment is received. In some cases, the data identifying and / or defining the primitive fragment can be received from geometry processing logic. Once the primitive fragment has been received, the method 2100 can proceed to block 2104.

[0165] At block 2104, a determination is made at logic 2002 as to whether any previous primitive fragments in the same set of primitive fragments associated with the tile (e.g., primitive fragments corresponding to primitives identified in the partial display list for the tile) have been placed in a non-priority queue. In other words, a determination is made as to whether any previous primitive fragments in the same set have been identified as requiring a depth buffer read. If it is determined at block 2104 that at least one primitive fragment in the same set of primitive fragments associated with the tile has been placed in a non-priority queue, then method 2100 proceeds to block 2106, where the primitive fragment is placed in the non-priority queue 2006. However, if it is determined at block 2104 that no previous primitive fragments in the same set of primitive fragments have been placed in a non-priority queue, then method 2100 proceeds to block 2108.

[0166] At block 2108, a determination is made at the logic 2002 as to whether the primitive fragment requires a depth buffer read for full-resolution hidden surface removal. Whether a primitive fragment requires a depth buffer read may be determined in any suitable manner using any suitable criteria. For example, the logic 2002 may be configured to determine whether a depth buffer read is required using any of the methods described above with respect to the coarse depth test logic 320. For example, the logic 2002 may be configured to determine whether a depth buffer read is required by performing a coarse pre-depth test on a primitive basis or on a primitive fragment basis.

[0167] If it is determined at block 2108 that the primitive fragment does not require a depth buffer read, then the method 2100 proceeds to block 2110, where the primitive fragment is placed in the priority queue 2004. However, if it is determined at block 2108 that the primitive fragment requires a depth buffer read, then the method 2100 proceeds to blocks 2112 and 2114, where the primitive fragment is placed in the non-priority queue 2006 and a read of the depth buffer for the associated tile is initiated. As described above, the read of the depth buffer for the associated tile can be initiated by, for example, sending a request for the depth buffer for the associated tile to the depth buffer cache. This can cause the depth buffer cache to determine whether it includes a depth buffer for the associated tile. If the cache determines that it does not include a depth buffer for the associated tile, then a read of the depth buffer memory can be performed to retrieve the depth buffer for the associated tile.

[0168] Now refer to Figure 22, which illustrates an example method 2200 for processing primitive fragments in queues 2004 and 2006, which may be implemented by HSR logic 2008. In this example, HSR logic 2008 is configured to process primitive fragments associated with the same tile in the order in which they are in the queue; however, HSR logic 2008 may process tiles out of order. For example, HSR logic 2008 may process primitive fragments for tile X before all primitive fragments have been processed relative to tile Y, even if the primitive fragments for tile X are after the primitive fragments for tile Y in the queue. However, HSR logic 2008 may be configured to process the primitive fragments for tile X in order and the primitive fragments for tile Y in order. Method 2200 begins at block 2202, where HSR logic 2008 determines whether an exception condition exists. Specifically, the HSR logic 2008 is typically configured to prioritize primitive fragments in the priority queue 2004 (e.g., processing all primitive fragments in the priority queue 2004 before processing any primitive fragments in the non-priority queue). However, if an exception condition exists, the HSR logic 2008 may process primitive fragments in the non-priority queue 2006 even if there are primitive fragments in the priority queue 2004. Example exceptions include, but are not limited to: the first / top primitive fragment in the non-priority queue 2006 is associated with a tile whose depth buffer is in the depth buffer cache 2012; the depth buffer cache 2012 is full (or nearly full); and the number of primitive fragments in the non-priority queue 2006 exceeds a threshold (e.g., the non-priority queue 2006 becomes overfull). If the HSR logic 2008 determines that an exception condition does not exist, the method 2200 proceeds to block 2204. However, if the HSR logic 2008 determines that an exception condition exists, the method 2200 proceeds to block 2206.

[0169] At block 2204, the HSR logic 2008 first determines whether any primitive fragments exist in the priority queue 2004. If, at block 2204, it is determined that at least one primitive fragment exists in the priority queue, the method 2200 proceeds to block 2208, where the HSR logic selects the first primitive fragment in the priority queue. The method 2200 then proceeds to block 2216. However, if, at block 2204, it is determined that the priority queue is empty, the method 2200 proceeds to block 2210, where the HSR logic 2008 determines whether any primitive fragments exist in the non-priority queue 2006. If, at block 2210, it is determined that the non-priority queue is empty, the method 2200 returns to block 2202. However, if, at block 2210, it is determined that at least one primitive fragment exists in the non-priority queue 2006, the method 2200 proceeds to block 2212, where the HSR logic selects the first primitive fragment in the non-priority queue 2006. The method 2200 then proceeds to block 2214 where the HSR logic checks to ensure that the depth buffer for the associated tile has been loaded from memory. Once it has been determined that the depth buffer has been loaded from memory, the method 2200 proceeds to block 2216.

[0170] At block 2206, the HSR logic 2008 first determines whether any primitive fragments exist in the non-priority queue 2006. If, at block 2206, it is determined that at least one primitive fragment exists in the non-priority queue, the method 2200 proceeds to block 2212, where the HSR logic selects the first primitive fragment in the non-priority queue 2006. The method 2200 then proceeds to block 2214, where the HSR logic checks to ensure that the depth buffer for the associated tile has been loaded from memory. Once it is determined that the depth buffer has been loaded from memory, the method 2200 proceeds to block 2216. However, if, at block 2206, it is determined that the non-priority queue 2006 is empty, the method 2200 proceeds to block 2218, where the HSR logic 2208 determines whether any primitive fragments exist in the priority queue 2004. If, at block 2218, it is determined that the priority queue 2004 is empty, the method 2200 returns to block 2202. However, if it is determined at block 2218 that there is at least one primitive fragment in the priority queue 2004 , then the method 2200 proceeds to block 2220 where the HSR logic selects the first primitive fragment in the priority queue.

[0171] At block 2216 , the HSR logic performs full-resolution hidden surface removal on the selected primitive fragments.

[0172] As described above, when the HSR logic is performing hidden surface removal on a set of primitive fragments associated with a tile, the HSR logic may maintain a depth value update map for the tile and a current best depth value buffer for the tile. The depth value update map indicates which pixel sample values have been updated during processing of the set of primitive fragments, and the current best depth value buffer indicates the 'best' depth value for each pixel sample in the tile to date. When the HSR logic receives or selects a new primitive fragment for the tile, the depth value update map may be initialized to indicate that the depth values have not yet been updated. The current best depth value buffer may also be initialized at this time. However, the initialization may differ depending on whether the depth buffer for the tile has already been loaded from memory. If the first primitive fragment does not cause a depth buffer read (e.g., the first primitive fragment is in a priority queue), the value in the current best depth value buffer may be initialized to the 'worst' (e.g., maximum) depth value. However, if the first primitive fragment causes a depth buffer read (e.g., the first primitive fragment is in a non-priority queue), the value in the current best depth value buffer may be initialized to the value in the depth buffer. If the HSR logic receives or selects a primitive fragment that causes a depth buffer read after one or more pixel sample depth values have been updated, then only those depth values in the loaded depth buffer that are associated with pixel samples that are not marked as updated in the depth value update map are loaded into the current best depth value buffer.

[0173] Performing full-resolution hidden surface removal on a primitive fragment may include comparing the depth (e.g., Z value or Z coordinate) of the primitive fragment to the corresponding current 'best' depth value of the pixel sample associated with the primitive fragment in the tile. If the depth value of the primitive fragment is better than the current 'best' depth value, then the primitive fragment passes the full-resolution depth test and is sent to the tag buffer. The current best depth value buffer is then updated to reflect the new 'best' depth value of the pixel sample, and the depth value update map is updated to reflect that the depth value of the pixel sample has been updated. However, if the depth value of the primitive fragment is worse (e.g., higher) than the current 'best' depth value of the corresponding pixel sample, then the primitive fragment fails the full-resolution depth test and is discarded (e.g., the primitive fragment is not further processed by the rasterization logic with respect to the current tile).

[0174] In some cases, as described above, the coarse depth test logic 320 may be configured to identify those primitive fragments for which full-resolution depth testing does not need to be performed (i.e., the depth value of the primitive fragment does not need to be compared with the current 'best' depth value of the corresponding pixel sample). In these cases, the HSR logic may be configured to, when it receives a primitive fragment that has been identified as not requiring full-resolution depth testing, simply update the current best depth buffer with the depth value (e.g., Z value or Z coordinate) of the primitive fragment and store the identifier of the primitive fragment in the tag buffer.

[0175] After a complete set of primitive fragments for a tile has been processed by the HSR logic, the current 'best' depth value, which has been updated (as indicated by the depth value update map), may be stored / written to the depth buffer in memory.

[0176] Figure 23 23. A computer system is shown in which the coarse depth test logic and / or graphics processing system described herein may be implemented. The computer system includes a CPU 2302, a GPU 2304, a memory 2306, and other devices 2314, such as a display 2316, a speaker 2318, and a camera 2320. A processing block 2310 (which may correspond to the coarse depth test logic and / or graphics processing system described herein) is implemented on the GPU 2304. In other examples, the processing block 2310 may be implemented on the CPU 2302. The components of the computer system may communicate with each other via a communication bus 2322.

[0177] Figures 1 to 4 The coarse depth test logic and graphics processing system of 19 to 20 are shown as including multiple functional blocks. This is merely illustrative and is not intended to define a strict division between the different logical elements of such entities. Each functional block may be provided in any suitable manner. It should be understood that intermediate values described herein as being formed by the coarse depth test logic or graphics processing system need not be physically generated by the coarse depth test logic or graphics processing system at any point, and may simply represent logical values that conveniently describe the processing performed by the coarse depth test logic or graphics processing system between its inputs and outputs.

[0178] The coarse depth test logic and graphics processing system described herein can be embodied as hardware on an integrated circuit. The coarse depth test logic and graphics processing system described herein can be configured to perform any of the methods described herein. In general, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms "module," "function," "component," "element," "unit," "block," and "logic" may be used herein to generally refer to software, firmware, hardware, or any combination thereof. In the case of a software implementation, a module, function, component, element, unit, block, or logic represents program code that performs a specified task when executed on a processor. The algorithms and methods described herein can be performed by one or more processors executing code that causes the processor to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk storage, and memory devices that can use magnetic, optical, and other technologies to store instructions or other data accessible by a machine.

[0179] As used herein, the terms computer program code and computer-readable instructions refer to any type of code that can be executed by a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code that defines an integrated circuit (e.g., a hardware description language or netlist), and code expressed in programming language code such as C, Java, or OpenCL. Executable code can be, for example, any type of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0180] A processor, computer, or computer system may be any kind of device, machine, or specialized circuit, or a collection or portion thereof, having processing capabilities that enable it to execute instructions. A processor may be any kind of general-purpose or specialized processor, such as a CPU, GPU, system on a chip, state machine, media processor, application-specific integrated circuit (ASIC), programmable logic array, field-programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0181] The present invention is also intended to encompass software that defines the configuration of hardware as described herein, such as hardware description language (HDL) software, for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided having computer-readable program code encoded thereon in the form of an integrated circuit definition data set that, when processed (i.e., executed) in an integrated circuit manufacturing system, configures the system to manufacture coarse depth test logic or graphics processing systems configured to perform any of the methods described herein, or to manufacture coarse depth test logic or graphics processing systems that include any of the devices described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0182] Thus, a method of manufacturing a coarse depth test logic or graphics processing system as described herein at an integrated circuit manufacturing system may be provided. Furthermore, an integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, enables the method of manufacturing a coarse depth test logic or graphics processing system to be performed.

[0183] The integrated circuit definition data set may be in the form of computer code, for example, as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in the integrated circuit, including as register transfer level (RTL) code, as a high-level circuit representation (such as Verilog or VHDL), and as a low-level circuit representation (such as OASIS (RTM) and GDSII). Higher-level representations that logically define hardware suitable for fabrication in the integrated circuit (such as RTL) may be processed on a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining these elements to generate a manufacturing definition of the integrated circuit defined by the representation. As is typical with software executed on a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of the integrated circuit, to execute the code that defines the integrated circuit, and thereby generate the manufacturing definition of the integrated circuit.

[0184] Now about Figure 24 An example of processing an integrated circuit definition data set at an integrated circuit fabrication system to configure the system to fabricate coarse depth test logic or a graphics processing system is described.

[0185] Figure 24An example of an integrated circuit (IC) manufacturing system 2402 is shown, which is configured to manufacture coarse depth test logic or a graphics processing system as described in any of the examples herein. In particular, the IC manufacturing system 2402 includes a layout processing system 2404 and an integrated circuit generation system 2406. The IC manufacturing system 2402 is configured to receive an IC definition data set (e.g., defining a coarse depth test logic or a graphics processing system as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., which embodies the coarse depth test logic or the graphics processing system as described in any of the examples herein) based on the IC definition data set. The processing of the IC definition data set configures the IC manufacturing system 2402 to manufacture an integrated circuit embodying the coarse depth test logic or the graphics processing system as described in any of the examples herein.

[0186] The layout processing system 2404 is configured to receive and process an IC definition data set to determine a circuit layout. Methods for determining a circuit layout based on an IC definition data set are known in the art and may, for example, involve synthesizing RTL code to determine a gate-level representation of the circuit to be generated, such as for logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout can be determined based on the gate-level representation of the circuit. This can be done automatically or with user participation to optimize the circuit layout. When the layout processing system 2404 determines the circuit layout, it can output the circuit layout definition to the IC generation system 2406. The circuit layout definition can be, for example, a circuit layout description.

[0187] As is known in the art, IC generation system 2406 generates an IC based on a circuit layout definition. For example, IC generation system 2406 may implement a semiconductor device manufacturing process for generating an IC, which may include a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that can be used in a photolithography process to generate an IC based on the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 2406 may be in the form of computer-readable code, which IC generation system 2406 may use to generate a suitable photomask for generating the IC.

[0188] The different processes performed by IC manufacturing system 2402 can all be implemented in a single location, e.g., by one party. Alternatively, IC manufacturing system 2402 can be a distributed system such that some processes can be performed in different locations and by different parties. For example, some of the following stages can be performed in different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of a circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) generating a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0189] In other examples, processing an integrated circuit definition data set at an integrated circuit manufacturing system may configure the system to manufacture a coarse depth test logic or graphics processing system without processing the IC definition data set to determine the circuit layout. For example, the integrated circuit definition data set may define the configuration of a reconfigurable processor such as an FPGA, and processing the data set may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading the configuration data into the FPGA).

[0190] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set may enable the integrated circuit manufacturing system to generate an apparatus as described herein. Figure 24 The configuration of an integrated circuit manufacturing system in the manner described can be used to manufacture the devices described herein.

[0191] In some examples, an integrated circuit definition data set may include software that runs on, or in combination with, the hardware defined by the data set. Figure 24 In the example shown, the IC generation system can be further configured by the integrated circuit definition dataset to load firmware onto the integrated circuit when manufacturing the integrated circuit according to the program code defined in the integrated circuit definition dataset, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0192] Compared to known embodiments, the implementation of the concepts set forth in this application in devices, equipment, modules and / or systems (and in the methods implemented herein) can result in performance improvements. Performance improvements can include one or more of increased computing performance, reduced latency, increased throughput and / or reduced power consumption. During the manufacture of such devices, equipment, modules and systems (e.g., in integrated circuits), a trade-off can be made between performance improvements and physical implementations to improve manufacturing methods. For example, a trade-off can be made between performance improvements and layout area to match the performance of known embodiments, but using less silicon. For example, this can be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of a device, device, module and / or system. In contrast, the concepts set forth in this application that result in improvements to the physical implementations of devices, equipment, modules and systems (e.g., reduced silicon area) can be weighed against performance improvements. For example, this can be accomplished by manufacturing multiple instances of a module within a predefined area budget.

[0193] The applicant hereby independently discloses each individual feature described herein, as well as any combination of two or more such features, so that such feature or combination can be implemented according to the common general knowledge of a person skilled in the art and based on the entire specification, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be clear to a person skilled in the art that various modifications can be made within the scope of the present invention.

Claims

1. A graphics processing system (300) wherein a rendering space is subdivided into a plurality of tiles and each tile comprises a plurality of pixel samples, the graphics processing system comprising hidden surface removal logic (314, 2008), the hidden surface removal logic (314, 2008) being configured to: receiving a primitive fragment from a set of primitive fragments associated with a tile from the plurality of tiles, the primitive fragment corresponding to pixel samples of the tile; receiving information indicating whether the primitive fragment requires a depth buffer read for full-resolution depth testing; If the primitive fragment is the first primitive fragment in the set, initializing a current best depth value buffer for the tile and a depth value update map for the tile, wherein the current best depth value buffer for the tile includes a depth value for each pixel sample of the tile, the depth value update map indicates which values in the current best depth value buffer have been updated, and the depth value update map is initialized to indicate that no depth values in the current best depth value buffer have been updated; determining whether the primitive fragment has a best depth value for the pixel sample corresponding to the primitive fragment according to a depth comparison mode; as well as In response to determining that the primitive fragment has the best depth value for the pixel sample corresponding to the primitive fragment, updating the depth value of the pixel sample in the current best depth value buffer to the depth of the primitive fragment, and updating the depth value update map to indicate that the depth value of the pixel sample has been updated; Wherein, when the first primitive fragment does not require depth buffer reading, initializing the current best depth value buffer includes initializing each depth value in the current best depth value buffer to a worst depth value according to the depth comparison mode, and when the first primitive fragment requires depth buffer reading, initializing the current best depth value buffer includes initializing each depth value in the current best depth value buffer to a corresponding depth value in the depth buffer of the tile block.

2. The graphics processing system (300) according to claim 1, wherein: The hidden surface removal logic (314, 2008) is further configured to: if the primitive fragment is not the first primitive fragment in the set but is the first in the set to require a depth buffer read for full resolution depth testing, update all depth values in the current best depth value buffer except those depth values identified as having been updated in the depth value update map, wherein corresponding depth values in the depth buffer of the tile are stored in memory.

3. The graphics processing system (300) according to claim 1, wherein: The hidden surface removal logic (314, 2008) is configured to determine whether the primitive fragment has a best depth value for the pixel sample corresponding to the primitive fragment by comparing the depth of the primitive fragment to depth values of the pixel samples in the current best depth value buffer.

4. The graphics processing system (300) according to claim 1, wherein: The hidden surface removal logic (314, 2008) is configured to: receiving information indicating whether full-resolution depth testing needs to be performed on the primitive fragment; and Determining whether the primitive fragment has the best depth value for the pixel sample corresponding to the primitive fragment is performed by: If full-resolution depth testing does not need to be performed on the primitive fragment, determining that the primitive fragment has a best depth value for the pixel sample corresponding to the primitive fragment, and If full-resolution depth testing needs to be performed on the primitive fragment, the depth of the primitive fragment is compared with the depth value of the pixel sample in the current best depth value buffer.

5. The graphics processing system (300) according to claim 3 or claim 4, wherein: The hidden surface removal logic (314, 2008) is configured to determine that the primitive fragment has a best depth value for the pixel sample corresponding to the primitive fragment if the primitive fragment is determined from the comparison according to the depth comparison mode to have a better depth value than the depth value of the pixel sample in the current best depth value buffer.

6. The graphics processing system (300) according to claim 5, wherein: The depth comparison mode is a less than depth comparison mode, and the hidden surface removal logic (314, 2008) is configured to: determine that the primitive fragment has a better depth value than the depth value of the pixel sample in the current best depth value buffer if the depth of the primitive fragment is determined from the comparison to be less than the depth value of the pixel sample in the current best depth value buffer.

7. The graphics processing system (300) according to any one of claims 1 to 4, wherein: The hidden surface removal logic (314, 2008) is further configured to discard the primitive fragment in response to determining that the primitive fragment does not have an optimal depth value for a corresponding pixel sample.

8. The graphics processing system (300) according to any one of claims 1 to 4, wherein: The hidden surface removal logic (314, 2008) is further configured to, in response to determining that the primitive fragment has the best depth value for the corresponding pixel sample, send the primitive fragment for further processing.

9. The graphics processing system (300) of claim 8, wherein sending the primitive fragment for further processing comprises sending an identifier of the primitive fragment to a tag buffer.

10. The graphics processing system (300) according to any one of claims 1 to 4, wherein: The hidden surface removal logic (314, 2008) is further configured to write each depth value in the current best depth value buffer that the depth value update map indicates has been updated to a depth buffer in memory if the primitive fragment is the last primitive fragment in the set of primitive fragments.

11. The graphics processing system (300) according to any one of claims 1 to 4, further comprising coarse depth test logic (320) comprising: Hidden depth test logic (404), configured to: receiving a set of one or more primitives associated with one of the plurality of tiles; obtaining a depth range for the tile, the depth range for the tile being based on a depth range of a primitive identified previously processed for the tile; as well as For at least one primitive in the set of one or more primitives: determining, based on a depth range of the tile, whether all or a portion of the primitive is hidden in the tile, wherein if at least a portion of the primitive is determined to be hidden in the tile, not performing a full-resolution depth test on the portion of the primitive associated with the tile; as well as In response to determining that at least a portion of the primitive is not hidden in the tile, outputting at least the portion of the primitive; as well as Front depth test logic (406) configured to receive primitives output by the hidden depth test logic (404), or one or more primitive fragments generated therefrom, and for at least one of the received primitives or at least one of the primitive fragments: determining, based on the depth range of the tile, whether the primitive or primitive fragment has a better depth than a previously processed primitive for the tile according to the depth comparison mode; as well as In response to determining that the primitive or primitive fragment has a better depth than a primitive previously processed for the tile, the primitive or primitive fragment is identified as not requiring a depth buffer read to perform a full-resolution depth test.

12. The graphics processing system (300) of claim 11, wherein: The front depth test logic (406) is further configured to: maintaining a record of each pixel sample in the tile for which the best depth value was obtained (1410, 1412); In response to determining that a primitive or primitive fragment has a better depth than a previously processed primitive for the tile: determining whether the record indicates that the best depth value is available for each pixel sample in the tile associated with the primitive or the primitive fragment (1406); In response to determining that the record indicates that the best depth value is not available for any pixel samples in the tile associated with the primitive or the primitive fragment, identifying the primitive or primitive fragment as not requiring full-resolution depth testing (1408); and updating the record to indicate that the best depth value is available for each pixel sample in the tile associated with the primitive or the primitive fragment (1410); and In response to not identifying the primitive or primitive fragment as not requiring a depth buffer read to perform full-resolution depth testing, updating the record to indicate that the best depth value is available for each pixel sample of the tile (1412).

13. The graphics processing system (300) of claim 11, wherein: The front depth test logic (406) is further configured to: maintaining a record of the best available depth value for each pixel sample in the tile; In response to determining that a primitive or primitive fragment has a better depth than a previously processed primitive for the tile: determining whether the record indicates that the best depth value is available for each pixel sample in the tile associated with the primitive or the primitive fragment; For each pixel sample in the tile associated with the primitive or primitive fragment for which the best depth value is not available, identifying the corresponding primitive fragment as not requiring a full-resolution depth test; and updating the record to indicate that the best depth value is available for each pixel sample in the tile associated with the primitive or the primitive fragment; as well as In response to not identifying the primitive or primitive fragment as not requiring a read of the depth buffer to perform full-resolution depth testing, updating the record to indicate that the best depth value is available for each pixel sample of the tile.

14. The graphics processing system (300) according to any one of claims 1 to 4, further comprising: a priority queue (2004) for storing primitive fragments; a non-priority queue (2006) for storing primitive fragments; as well as Logic (2002), which is configured to: receiving a plurality of primitive fragments, each primitive fragment corresponding to a pixel sample in a tile; determining whether a depth buffer read is to be performed for full resolution depth testing of one or more of the primitive fragments; and sorting the primitive fragments into the priority queue (2004) and the non-priority queue (2006) based on a depth buffer read determination; wherein the primitive fragment received by the hidden surface removal logic (2008) is a primitive fragment selected by the hidden surface removal logic (2008) from one of the priority queue (2004) and the non-priority queue (2006) in the following manner: primitive fragments in the priority queue (2004) are given priority.

15. The graphics processing system (300) according to any one of claims 1 to 4, wherein: The hidden surface removal logic (314, 2008) is embodied in hardware on an integrated circuit.

16. A method of performing hidden surface removal processing on a primitive fragment in a graphics processing system, wherein a rendering space is subdivided into a plurality of tiles and each tile includes a plurality of pixel samples, the method comprising: receiving a primitive fragment from a set of primitive fragments associated with a tile from the plurality of tiles, the primitive fragment corresponding to pixel samples of the tile; receiving information indicating whether the primitive fragment requires a depth buffer read for full-resolution depth testing; If the primitive fragment is the first primitive fragment in the set, initializing a current best depth value buffer for the tile and a depth value update map for the tile, wherein the current best depth value buffer for the tile includes a depth value for each pixel sample of the tile, the depth value update map indicates which values in the current best depth value buffer have been updated, and the depth value update map is initialized to indicate that no depth values in the current best depth value buffer have been updated; determining whether the primitive fragment has a best depth value for the pixel sample corresponding to the primitive fragment according to a depth comparison mode; as well as In response to determining that the primitive fragment has the best depth value for the pixel sample corresponding to the primitive fragment, updating the depth value of the pixel sample in the current best depth value buffer to the depth of the primitive fragment, and updating the depth value update map to indicate that the depth value of the pixel sample has been updated; Wherein, when the first primitive fragment does not require depth buffer reading, initializing the current best depth value buffer includes initializing each depth value in the current best depth value buffer to a worst depth value according to the depth comparison mode, and when the first primitive fragment requires depth buffer reading, initializing the current best depth value buffer includes initializing each depth value in the current best depth value buffer to a corresponding depth value in the depth buffer of the tile block.

17. A graphics processing system configured to execute the method of claim 16.

18. A computer-readable storage medium having computer-readable instructions stored thereon, which, when executed at a computer system, cause the computer system to perform the method of claim 16.

19. A computer-readable storage medium having stored thereon a computer-readable description of the graphics processing system (300) according to any one of claims 1 to 15, wherein the computer-readable description, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the graphics processing system (300).

Images