Hidden surface removal in graphics processing systems

Abstract

The present disclosure relates to hidden surface removal in a graphics processing system. In particular, a graphics processor performs early depth testing of primitives with respect to tiles of a rendered output, and depth testing of sample locations of the rendered output, maintains a per-tile depth buffer that stores depth values of a tile for use in the early depth testing of the tile, and a per-sample depth buffer. When processing of the rendered output is stopped before completion of the rendered output, per-sample depth values in the per-sample depth buffer are written to storage so that the per-sample depth values can be recovered, but per-tile depth value information in the per-tile depth buffer is discarded. Then, when resuming processing of the rendered output, the per-sample depth buffer values are loaded into the per-sample depth buffer, and the loaded per-sample depth buffer values are also used to recover the per-tile depth buffer for use in continuing processing of the rendered output.

Description

Technical Field

[0001] The techniques described in this article relate to computer graphics processing, and in particular to hidden surface removal in graphics processing. Background Technology

[0002] Normally, graphics processing begins by dividing the graphics processing (rendering) output (such as a frame to be displayed) into multiple similar basic components (so-called "primitives") to make graphics processing operations easier. These "primitives" are usually in the form of simple polygons, such as triangles.

[0003] Typically, the graphics processor's driver generates primitives for output (such as frames to be displayed) based on graphics drawing instructions (requests) received from applications that require graphics processing (such as games).

[0004] At this level, each primitive is typically defined and represented by a set of vertices. Each vertex of a primitive is already associated with a dataset representing that vertex (such as position, color, texture, and other attribute data). This data is then used, for example, when rasterizing and rendering the vertices (and the primitives associated with those vertices), for display purposes.

[0005] Once primitives and their vertices are generated and defined, they can be processed by a graphics processor to, for example, display the frame.

[0006] This process essentially involves determining which sample points in an array of sample points covering the area of ​​the rendered output to be processed are covered by primitives, and then determining the representation that each sample point should have (e.g., based on its color, etc.) to represent the primitive at that sample point. These processes are collectively referred to as rasterization and rendering, respectively.

[0007] Rasterization determines the sampling points that should be used for primitives (i.e., the (x, y) positions of the sampling points to represent primitives in the rendered output (e.g., the frame to be displayed). This is typically done using the positions of the primitive's vertices.

[0008] The rendering process then exports the data necessary to represent the primitives at the sampled points (i.e., the individual sampled points "shaded"), such as red, green, and blue (RGB) color values, and "alpha" (transparency) values. This may involve applying textures, blending sampled point data values, etc.

[0009] (In graphics literature, the term "rasterization" is sometimes used to refer to the conversion of primitives into sample locations and rendering. However, in this paper, "rasterization" simply refers to the conversion of primitive data into sample point addresses.)

[0010] These processes are typically performed by testing multiple groups of one or more sample points, and then, for each group of sample points found to include a sample point that is inside (covered) the primitive in question, generating a discrete graphics entity, often referred to as a "fragment," for which a graphics processing operation (such as rendering) is performed. Thus, the covered sample points are effectively processed into fragments that will be used to render the primitive at the sample point in question. A "fragment" is a graphics entity that has undergone rendering processing (rendering pipeline). Depending on how the graphics processing is configured, the individual fragments generated and processed can, for example, represent a single sample point or a group of multiple sample points.

[0011] (Therefore, a "fragment" is actually a set of graphical data (as associated with it), which is interpolated to one or more output space sampling points of the primitives. A fragment may also include per-primitive and other state data required to color the primitive at the sampling point in question (fragment location). The size and position of individual graphical fragments can generally be the same as the "pixels" of the output (e.g., the output frame) (because pixels are singularities in the final display, there can be a one-to-one mapping between the "fragments" operated on (rendered) by the graphics processor and the pixels of the display). However, there may be cases where there is no one-to-one correspondence between fragments and display pixels, for example, when a particular form of post-processing (such as downsampling) is performed on the rendered image before the final image is displayed.)

[0012] (There is also the case where, because multiple fragments at a given location (e.g., from different overlapping primitives) may influence each other (e.g., due to transparency and / or blending), the final pixel output may depend on multiple or all of the fragments at that pixel location.)

[0013] (Correspondingly, there may be a one-to-one correspondence between sampled points and display pixels, but more typically, there may not be a one-to-one correspondence between sampled points and display pixels, because rendered sample values ​​may be downsampled to generate output pixel values ​​used to display the final image. Similarly, in cases where multiple sampled point values ​​at a given location (e.g., from different overlapping primitives) influence each other (e.g., due to transparency and / or blending), the final pixel output will also depend on multiple overlapping sample values ​​at that pixel location.)

[0014] Some graphics processing systems use so-called "tile-based" or "deferred" rendering. In tile-based rendering, instead of processing the entire render output (e.g., a frame) all at once, the render output (e.g., a frame to be displayed) is divided into multiple smaller regions, commonly called "tiles." Each tile (region) is rendered individually (usually one after another), and then the rendered tiles (sub-regions) are recombined to provide the complete render output, such as a frame for display. In such an arrangement, the render output is typically divided (by area) into render regions (tiles) of regular size and shape (which are typically squares or rectangles). However, this is not always necessary.

[0015] (Other terms commonly used for “tiling” and “tile-based” rendering include “chunking” (rendering tiles is called a “chunk”) and “bucket” rendering. For convenience, the terms “tile” and “tiling” will be used in this document. However, it should be understood that these terms are intended to cover all alternative and equivalent terms and techniques in which the rendering output is rendered as a series of smaller areas.)

[0016] One problem with current graphics processing systems is that, because primitives are processed sequentially, and often not in a perfectly sequential order, a given sample point (and therefore fragments and pixels) may be colored multiple times as the output is processed (e.g., for display). This occurs when the first primitive received and rendered is subsequently overwritten by a later primitive, making the first rendered primitive actually invisible at the pixel (and sample point) in question. Primitives can be overwritten multiple times in this way, which can result in multiple redundant rendering operations being performed on the various rendering outputs being rendered (e.g., frames). This phenomenon is commonly referred to as "overdraw."

[0017] The result of performing such redundant operations is a reduced frame rate and increased storage bandwidth requirements (e.g., due to fetching data for primitives that will be overwritten by later primitives). Both of these are undesirable and degrade the overall performance of the graphics processing system. These problems tend to become more severe as rendering outputs (such as frames to be rendered) become larger and more complex (because there will be more surfaces in the potentially visible view) and as the use of programmable fragment shading increases.

[0018] In an effort to reduce the amount of “overdrawing”, the applicant has previously proposed, for example, in its U.S. Patent 9,558,585 (which is incorporated herein by reference in its entirety), to perform some form of early depth (Z) test before sending primitives and / or fragments for rendering to see if the primitive or fragment will be occluded by primitives that have already been rendered (in which case, there is no need to render the new fragment and / or primitive).

[0019] These arrangements attempt to identify sample points for new primitives that will be occluded by primitives that have already been processed (and therefore do not require further processing) before being emitted to the rendering pipeline at a later sample point. In these arrangements, for the current "output" primitive at the sample location in question, the depth value of the new primitive to be processed at those sample locations is compared to the depth values ​​of those sample locations to see if the new primitive is occluded at the sample location in question. This helps avoid sending fragments occluded by already processed primitives through the rendering pipeline.

[0020] The applicant believes that there is still room for improvement when performing hidden surface removal in a graphics processing system. Summary of the Invention

[0021] According to one aspect of this disclosure, a method of operating a graphics processor is provided, the graphics processor comprising:

[0022] A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; and

[0023] A renderer that processes the fragments generated by the rasterizer to generate output fragment data;

[0024] When the rasterizer receives a primitive to be rasterized, it tests the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block.

[0025] The graphics processor also includes:

[0026] An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and

[0027] A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives;

[0028] The method includes the following steps: when processing primitives to generate rendering output, the following operations are performed:

[0029] A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and

[0030] A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated;

[0031] The method further includes the following steps:

[0032] The graphics processor stops processing the rendering output, and when the graphics processor does so, it performs the following operations:

[0033] The per-sample depth value in the per-sample depth buffer is written to storage so that the per-sample depth value can be recovered when processing the rendering output continues, but the per-block depth value information in the per-block depth buffer is discarded.

[0034] and

[0035] The graphics processor resumes the processing of the rendered output; and when the graphics processor does so, it performs the following operations:

[0036] The per-sample depth buffer values ​​to be written to storage are loaded into the per-sample depth buffer for use when processing the rendering output continues; and

[0037] Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives while continuing the processing of the rendering output.

[0038] According to another aspect of this disclosure, a graphics processor and a non-transitory computer-readable storage medium for storing computer software code are also provided. Attached Figure Description

[0039] Now, by way of example only and with reference to the accompanying drawings, several embodiments of the technology described herein will be described, wherein:

[0040] Figure 1 An embodiment of a graphics processor that can operate according to the techniques described herein is illustrated schematically;

[0041] Figure 2 The subdivision processing used by the rasterizer is illustrated in the described embodiments of the technology described herein;

[0042] Figure 3 and Figure 4 The determination of depth values ​​in embodiments of the techniques described herein is illustrated; and

[0043] Figure 5 Operation in an implementation of the technology described herein is illustrated.

[0044] Where appropriate, use the same labels for the same features and components in the diagram. Detailed Implementation

[0045] A first embodiment of the technology described herein includes a method of operating a graphics processor, the graphics processor comprising:

[0046] A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; and

[0047] A renderer that processes the fragments generated by the rasterizer to generate output fragment data;

[0048] When the rasterizer receives a primitive to be rasterized, it tests the patch relative to the primitive for each patch in one or more patches representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the patch.

[0049] The graphics processor also includes:

[0050] An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and

[0051] A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives;

[0052] The method includes the following steps: when processing primitives to generate rendering output, the following operations are performed:

[0053] A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and

[0054] A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated;

[0055] The method further includes the following steps:

[0056] The graphics processor stops processing the rendering output, and when the graphics processor does so, it performs the following operations:

[0057] The per-sample depth value in the per-sample depth buffer is written to storage so that the per-sample depth value can be recovered when processing the rendering output continues, but the per-block depth value information in the per-block depth buffer is discarded.

[0058] and

[0059] The graphics processor resumes the processing of the rendered output; and when the graphics processor does so, it performs the following operations:

[0060] The per-sample depth buffer values ​​to be written to storage are loaded into the per-sample depth buffer for use when processing the rendering output continues; and

[0061] Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives while continuing the processing of the rendering output.

[0062] A second embodiment of the technology described herein includes a graphics processor, the graphics processor comprising:

[0063] A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; and

[0064] A renderer that processes the fragments generated by the rasterizer to generate output fragment data;

[0065] The rasterizer is configured to, when receiving a primitive to be rasterized, test the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block.

[0066] The graphics processor also includes:

[0067] An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and

[0068] A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives;

[0069] The graphics processor is also configured to perform the following operations when processing primitives to generate rendering output:

[0070] A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and

[0071] A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated;

[0072] The graphics processor is further configured to perform the following operations when it stops processing the rendering output before completing the rendering output:

[0073] The per-sample depth value in the per-sample depth buffer is written to memory so that the per-sample depth value can be recovered when processing the rendering output continues, but the per-block depth value information in the per-block depth buffer is discarded; and

[0074] The graphics processor is also configured to perform the following operations when it resumes processing of previously stopped rendering output:

[0075] The per-sample depth buffer value of the rendered output to be written to storage is loaded into the per-sample depth buffer for use when processing the rendered output continues; and

[0076] Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives while continuing the processing of the rendering output.

[0077] The technique described herein relates to a graphics processor in which primitives to be rendered undergo early depth testing with respect to blocks representing regions of output being rendered, and individual sampled locations of primitives undergo per-sampled-location depth testing.

[0078] To support these two different depth testing operations, both a "per-block" depth buffer and a per-sample-position depth buffer are maintained when generating the render output. The per-block depth buffer stores appropriate depth value information about the blocks in the render output that can be used to perform earlier per-block depth testing, while the per-sample-position depth buffer stores the depth values ​​of each sample position of the render output being generated.

[0079] The techniques described in this article specifically address situations where the generation of rendering output can be stopped and resumed at a later time (e.g., because it is necessary to switch to processing another rendering output, and / or because it is necessary to generate and / or provide additional data to enable processing of more of that rendering output).

[0080] In the technique described herein, when it is desired to pause the generation of rendering output, the per-sample depth buffer is written to storage (e.g., memory) so that the per-sample depth buffer can be restored when the generation of rendering output is resumed.

[0081] On the other hand, instead of writing the per-block-depth buffer to memory, the per-block-depth buffer is simply discarded (without being written to memory (e.g., storage)).

[0082] Then, when it is time to restart the processing of the rendering output, the per-sample depth buffer is restored using the per-sample depth values ​​stored in the memory, and a new version of the per-block depth buffer is generated using the restored (previously stored) per-sample depth values ​​for use when continuing to process the rendering output.

[0083] The applicant has recognized that this is the case when it may be necessary to stop and resume processing a given render output during graphics processing. For example, in cases where limited storage space is reserved for the data structures required to process the render output, that storage space may be filled before the complete data structure of the render output is generated. In this case, it may be desirable to process the existing data structures of the render output (in order to effectively “flush” those data structures in storage), and then generate the new data structure of the render output in question, and so on. Therefore, in this case, the render output being generated may, for example, be generated as a series of “incremental” processes, wherein the first portion of the render output data is processed, followed by a pause and / or processing of some other render output, and then a return to the initial render output to complete (or at least continue processing of that initial render output).

[0084] For example, this might occur in tile-based graphics processing systems, where processing of one tile might be paused and then switched to processing of another tile, and so on, with processing alternating between different tiles, for example, because different tile data structures are generated and used.

[0085] The applicant further recognizes that, in cases where a given render output may only be partially processed, it is necessary to restore the processing of that render output at a later time. Then, it may be necessary to retain the data structures generated so far as part of the processing of the render output so that when the processing of the render output in question is restored, the generated data structures can be reused and the process can continue.

[0086] The applicant further recognizes that, on the one hand, the rendering output has been partially processed, and it is desired to continue processing that rendering output at a later time; and on the other hand, it is desired to preserve depth values ​​relative to the partially processed rendering output for use when resuming processing of the rendering output. The technique described herein solves this problem by storing the depth values ​​generated from the partially processed rendering output to a memory when processing of the partially completed rendering output is stopped, so that those depth values ​​can then be recovered when resuming processing of the rendering output.

[0087] However, instead of simply saving all the depth values ​​generated so far for both the per-sample depth test and the per-block depth test, the technique described in this paper simply writes out the per-sample depth values ​​and, instead, uses those per-sample depth values ​​to recover the per-block depth values ​​during the process of restoring the rendered output.

[0088] The applicant has recognized that it is possible and feasible to recover the depth value of each block from the depth value of each sample in a sufficiently efficient manner, so that writing out the depth value of each block can be omitted for later (re)use. This has the advantage of reducing storage requirements and bandwidth needed when processing of rendering output is interrupted midway, thus making the overall processing more efficient.

[0089] The graphics processors described in this article include: rasterizers, renderers, and per-block depth testing and per-sample location depth testing.

[0090] The rasterizer (rasterizer circuitry) can be configured to operate in any suitable and desired manner, for example, as in a known rasterization layout. The rasterizer should generate the graphic fragments for processing based on which sample points (or sets of sample points) in the sample point array are covered (at least partially) by the area, given primitives, etc., of the rendered output received by the rasterizer.

[0091] In an implementation, the rasterizer generates graphic fragments of individual sample points covered by the primitives (and each) being rasterized, and / or graphic fragments of multiple groups of sample points (e.g., sample masks): the multiple groups of sample points found to include sample points covered by the primitives (and each) being rasterized (as well as sample points that were originally not removed from processing for another reason, such as because the primitives failed an early depth test). Accordingly, the fragments generated by the rasterizer can represent a single sample point (or associated with that sample point) or multiple sample points as needed. In an implementation, the fragments represent a group of multiple sample points, in which a group of four sample points (and in which, in another implementation, a 2 × 2 array of sample points) is used.

[0092] In the techniques described herein, a rasterizer works to determine whether a primitive being rasterized at least partially covers a corresponding block of the rendered output to be generated. At this point, the rasterizer could simply divide the test rendered output into a single set of blocks. However, in this implementation, the rasterizer is a hierarchical rasterizer that works to iteratively test primitives for the following blocks of the rendered output (sampling location): the size of the blocks is progressively reduced until a given (selected in this implementation, predetermined in this implementation) minimum block size is reached, discarding any blocks not at least partially covered by the primitive; then one or more fragments are generated for rendering, these fragments corresponding to the one or more blocks at the sampling location found to be at least partially covered by the primitive (and passing an earlier depth test).

[0093] The rasterizer can test primitives against blocks of the rendered output in any suitable and desired manner to determine whether primitives cover blocks (at least partially). For example, edge equations for primitive edges can be derived and then tested against blocks of the rendered output to see if those blocks are covered by primitives.

[0094] The graphics processor's renderer (renderer circuitry) should be operable to render (color) graphics fragments received by the renderer to generate desired output graphics fragment data. The renderer can contain any suitable and desired rendering components and can be configured in any suitable and desired manner. Thus, for example, the renderer may include a fixed-function rendering pipeline, including one or more fixed-function rendering stages (circuits), such as texture mappers, mixers, fog units, etc. In implementations, the renderer includes fragment shaders (shader pipelines) (i.e., programmable processing circuitry operable and programmable to perform fragment coloring procedures on fragments to render those fragments).

[0095] The renderer processes the received fragments and then generates output rendered fragment data. In this implementation, the rendered fragment data is then written to an output buffer (such as a frame buffer) in external memory for use (e.g., to display the frame on a monitor). The rendered fragment data can be written to the (external) output buffer via an intermediate buffer such as a tile buffer (as is the case in tile-based graphics processing systems).

[0096] The per-block depth testing of the technology described in this article includes “early” depth testing, which is a depth test performed before rendering (before the fragment is sent to the renderer for processing).

[0097] The sampling point depth test (and maintains a per-sample-point depth buffer for it) can also be an "early" depth test or a "late" depth test, that is, the sampling point depth test is performed after rendering (after the fragment has been rendered) (and, for example, in an implementation, as a final check to determine whether the rendered sampled position of the primitive is stored as part of the rendered output).

[0098] In implementation, the graphics processor performs and includes both an "early" per-sample depth test and a "late" per-sample depth test. The graphics processor can be configured to perform only one or the other of the early and late per-sample depth tests, or both, as needed, for any given render output, primitive sampling points, etc.

[0099] In cases where the graphics processor performs both early per-sample depth testing and late per-sample depth testing, in the implementation, those early and late per-sample depth tests share (commonly use) (and jointly update) the same per-sample depth buffer (i.e., there are no separate "early" per-sample depth buffers and separate "late" per-sample depth buffers).

[0100] Therefore, in the implementation, the graphics processor includes both early depth testing of the blocks of the rendered output, and early depth testing of individual sample points, and also includes late depth testing of individual sample points.

[0101] For example, one or more early depth tests can be implemented as part of the rasterizer, or after the rasterizer (but before the renderer), or as a combination of the early depth tests (e.g., in the case of having more than one early depth test). In an implementation, the early depth test or these early depth tests are implemented as part of the rasterization process, and / or after the rasterizer but before the remainder of the graphics processing pipeline executed by the graphics processor. Thus, in an implementation, the rasterizer and rasterization process are configured to also perform early depth (Z) tests on blocks of the rendered output that are being tested against primitives (to see if the blocks of the rendered output can be discarded from further processing based on the early depth tests).

[0102] The rendering output to be generated (and divided into tiles, etc.) can include any rendering output to be generated by the graphics processor. Therefore, the rendering output to be generated can, for example, include all or part of the tiles to be generated in a tile-based graphics processor, and / or frames of fragment data to be output.

[0103] In this implementation, the generated rendering output is a tile (region) of the overall output (such as a frame to be displayed) generated by a graphics processor (therefore, a tile-based graphics processor).

[0104] The applicant has recognized that in a tile-based graphics processing system, it may be desirable to switch from processing one tile to processing another or more tiles, and then return to continue processing the earlier tiles, and so on. This may occur, for example, when the amount of memory available for the tile data structures to be used when rendering the tiles is limited, making it possible, for example, to process tiles whose relevant data structures have only been partially completed in order to free up the memory space occupied by those data structures. However, this means that only the tile has been partially processed, and therefore it may be necessary to resume processing of the tile at a later time, for example, when a new data structure containing previously unprocessed new data of the tile has been generated, and so on.

[0105] The rendered output can be selectively divided into blocks for rasterization and early per-block depth testing, as needed. In this implementation, the block for which early (per-block) depth testing is performed corresponds to the following block of the rendered output: the block that the rasterizer tests for rasterization processing.

[0106] In this implementation, all blocks have the same shape and cover (include) the area of ​​a regular shape in the rendered output. In this implementation, the blocks are rectangular (including squares). In this implementation, the blocks are square.

[0107] In this implementation, the blocks correspond to multiple sampling locations in the rendered output to be generated. In this implementation, the blocks considered for (per-block) depth testing include blocks (sets) of multiple fragments. For example, where the rasterizer can rasterize primitives into blocks of multiple fragments, then such blocks as a whole can undergo (per-block) (early) depth testing. Therefore, in this implementation, (per-block) early depth testing tests blocks (sets) of multiple fragments.

[0108] In this implementation, there are multiple (layered) levels of blocks for depth testing, where each block level contains smaller blocks compared to the previous higher or larger block level. In this implementation, each larger block of the rendered output is divided into a corresponding set containing multiple smaller blocks of the rendered output (this set can contain any desired number of smaller blocks of the rendered output). In this implementation, each set of multiple smaller blocks contained in a given larger, higher-level block includes an integer number of smaller blocks. In this implementation, each larger block is divided into a set of four smaller blocks for depth testing. In this implementation, each larger block is divided into a set (array) of 2 × 2 smaller blocks.

[0109] Therefore, in this implementation, the blocks are configured such that larger blocks (and each larger block) contain (and will be correspondingly subdivided into) a set of four smaller blocks, each smaller block being one-quarter the size of the larger block. Varying the block size by a factor of four in each successive subdivision level is a particularly convenient arrangement for progressively reducing the block size as rasterization and depth testing processes proceed. However, this is not necessary, and other arrangements can be used as needed.

[0110] Each block (within a given level of the block) should (and indeed in the implementation) represent a different region (area) of the rendered output to be generated.

[0111] In this implementation, each block of the rendered output being tested corresponds to an integer number of fragments, such as 16 × 16, 8 × 8, 4 × 4, and / or 2 × 2 fragments. In this implementation, the largest block corresponds to a 16 × 16 fragment, and the next smaller second-level block is an 8 × 8 fragment, while the third-level smaller block is a 4 × 4 fragment (and so on, as needed).

[0112] In the implementation, all blocks of a given subdivision level have the same size and are also the same shape as each other (i.e., in the implementation, they cover the same number of sampling locations in the rendering output).

[0113] In the techniques described herein, both the per-block depth buffer and the per-sample depth buffer are maintained when generating rendering output. These depth buffers should be stored in appropriate (local) memory of the graphics processor and / or accessible by the graphics processor, such as, and in embodiments, the graphics processor's (local) RAM or (local) RAM associated with the graphics processor. These buffers may be stored in different physical memories, but in embodiments, they are stored in the same physical memory.

[0114] The per-sample depth buffer stores the depth values ​​to be used for per-sample depth testing and can be configured in any suitable and desired manner. This per-sample depth buffer should, and in implementations, store the depth values ​​of each sample location of the rendered output (e.g., tiles) being generated. Therefore, the per-sample depth buffer should, and in implementations, store the current depth value of each sample location within the rendered output (which can then be compared with the depth values ​​of later primitives covering the sample location in question (and subjected to per-sample depth testing)). As primitives and sample locations are processed and depth tested for the rendered output being generated, the depth values ​​stored in the per-sample depth buffer should be stored and updated, and in implementations, are stored and updated.

[0115] The per-sample depth test can be performed using the per-sample depth values ​​stored in the per-sample depth buffer in any suitable and desired manner (such as, and in implementations, according to the normal operation of such per-sample depth testing in the graphics processor and graphics processing system discussed). Therefore, in an implementation, the depth value of the sampling location associated with a primitive is compared with the current depth value of the sampling location in the per-sample depth buffer to see if a new primitive is occluded at that sampling location.

[0116] In the implementation, depth testing is performed in an appropriately conservative manner to avoid any risk of errors.

[0117] Accordingly, in the implementation, the result of the depth test for the sampling location is either that the new primitive passes the test for the sampling location (and is therefore sent forward in the pipeline for processing of that sampling location), or that the primitive fails the depth test at the sampling location in question (in which case, in the implementation, the primitive for the sampling location in question is discarded (no further processing is performed for the rendering output sampling location in question)).

[0118] Accordingly, if the primitive being tested for the sampling location passes the per-sample depth test, then in this implementation, the depth value stored for the sampling location in question is updated (where appropriate) to account for the new primitive. In this implementation, this update is performed in an appropriately conservative manner to avoid any risk that the update might cause errors in future primitive processing, etc.

[0119] The per-block depth buffer stores the depth value information of the blocks to be used for early depth testing of each block, and can be configured accordingly in any suitable and desired manner. This per-block depth buffer should, and indeed in implementations, store the depth value information of each block of the rendered output being generated (against which per-block depth testing can be performed).

[0120] Therefore, the per-block depth buffer should, and indeed in the implementation, store depth value information for the blocks (and individual blocks) for which per-block depth testing can be performed (particularly, and in the implementation, for the individual blocks for which the rasterizer can test primitives). Thus, in the implementation, the per-block depth buffer will have entries for the individual blocks of the rendered output, which will be considered when generating the rendered output. Therefore, in this case, where there are blocks at a single level for rasterization and early per-block depth testing processing, the per-block depth buffer will contain a set of entries corresponding to the blocks at that level.

[0121] Accordingly, where the rasterizer and early depth testing per block operate in a hierarchical manner, in the implementation, the per-block depth buffer correspondingly stores a set of depth value information for the hierarchical arrangement of blocks. Thus, for example, the per-block depth buffer will store, and in the implementation stores, appropriate depth value information for each of the various "largest" blocks that can be considered, and then also store depth value information for each of the smaller blocks within the larger blocks, and so on.

[0122] As primitives are processed and depth tests are performed on the rendering output being generated, the depth value information stored in the depth buffer of each block should be stored and updated, and is stored and updated in the implementation.

[0123] Therefore, the per-block depth buffer should, and in practice, store the current depth value information of each block within the rendering output (which can then be used to perform a per-block depth test of a later primitive that at least partially covers the block in question).

[0124] The depth value information stored for blocks (and individual blocks) for use by the block early depth testing circuitry when performing block early depth testing on primitives with respect to the block can include any suitable and desired depth value information that can be used for this purpose. In an embodiment, the block depth value information enables the determination of one or more depth values ​​for the block to be used for performing block early depth testing. Therefore, in an embodiment, the block depth value information indicates and includes one or more depth values ​​to be used for that block.

[0125] The depth values ​​of blocks (individual blocks) stored in the block depth buffer can be indicated and represented as needed.

[0126] For example, the depth value of a block can be represented by a function of the depth value (a function representing the depth value), such as a layer function (plane function) that describes the depth value within the block in question.

[0127] However, in this implementation, the block depth value is represented as a range of depth values ​​to be used for the block in question, and in this implementation, it is represented as the minimum and maximum depth values ​​to be used for the block in question. (Correspondingly, in this implementation, the block depth test uses multiple depth value ranges for the blocks in the rendered output.)

[0128] Representing the depth value per block as a range of depth values ​​(represented as the minimum and maximum depth values ​​of the block) helps to refill (restore) the per-block depth buffer using the per-sample depth buffer value when restoring the rendered output.

[0129] Accordingly, in the implementation, one or more depth value ranges are stored for some blocks (and in the implementation, all blocks) of the rendered output that can be considered (early depth testing). In this case, in the implementation, the minimum and maximum depth values ​​of the blocks (and each block) are stored and used.

[0130] Therefore, in this case, when performing early depth testing for each block in a hierarchical configuration for blocks, the depth value range of each “largest” block to be considered in the stored rendering output will be included, along with the depth value range of any smaller blocks within the larger blocks (the depth value range of the smaller blocks will be within the depth value range of their “parent” larger blocks).

[0131] Early-stage depth testing of primitives can be performed on a per-block basis (based on the block's depth value) in any suitable and desirable manner. In this implementation, the test is performed only on blocks of the rendered output that have been found by rasterization to be at least partially covered by the primitives in question.

[0132] Therefore, in one implementation, one or more depth values ​​associated with the new primitive being processed are compared with one or more current depth values ​​of the rendered output block to see if the new primitive is occluded. In this implementation, this is done by deriving appropriate depth values ​​for the corresponding sampling locations within the block in question. In this implementation, the sampling locations correspond to the grid of selected sampling locations within the block, for example, to the corresponding corner of the block in question.

[0133] For primitives, a depth function of the primitive can be used, for example, in the implementation, to determine the depth value at the location of the block sampling point.

[0134] For a block, the depth value to be used should be determined, and in the implementation, based on (and on) the depth value information stored for that block. Therefore, in the case where the block depth value is represented as a range of depth values ​​(minimum depth value and maximum depth value), then in the implementation, a corresponding minimum depth value and maximum depth value are assigned to each block sampling location, and two depth tests are performed: one for the minimum depth value at each block location, and the other for the maximum depth value at each block sampling location.

[0135] Other arrangements are certainly possible.

[0136] The depth test itself can be performed in any suitable and desirable manner using depth values ​​of the determined relevant locations of the primitives and blocks under consideration, for example, in a normal manner for the graphics processor and graphics processing system in question. In the implementation, these depth tests are performed in a suitably conservative manner.

[0137] In this implementation, the result of the depth test for a block is either that the primitive (entirely or partially) passes the test (and is therefore forwarded in the pipeline for processing of the area of ​​the block it covers), or that the depth test for the primitive across the area of ​​the block it covers fails (in which case, in this implementation, the primitive corresponding to the rendered output area of ​​the block is discarded (no further processing is performed on the rendered output area in question)).

[0138] If the primitives being tested against a block partially or fully pass the block depth test, in this implementation, the depth value information stored (and associated with) that block will be updated (where appropriate) to account for the new primitives. In this implementation, this update is performed in an appropriately conservative manner to avoid any risk that the update might cause errors in future primitive processing, etc.

[0139] Therefore, if the early depth test of a block passes, in the implementation, similarly, for example, and in the implementation, the per-block depth buffer entries of the block (and any associated (overlapping) blocks) are updated using the relevant depth values ​​associated with the primitives that passed the early depth test.

[0140] The techniques described herein specifically address situations where a rendering output (such as tiles of a frame being generated by a graphics processor) has only been partially processed (not yet complete), and processing of the rendering output (e.g., tiles) needs to be stopped (e.g., so that another rendering output (e.g., tiles from that frame) can be processed instead). This situation may arise when there is a limitation on the amount of data that can be stored for the rendering output, before new space for new data to be used for the rendering output needs to be freed up, as discussed above.

[0141] Therefore, in the technique described herein, the processing of the rendering output will stop for some reason (but not completed) (only partially completed). At this point, for the rendering output, there will be both a per-sample depth buffer that stores the per-sample depth values ​​of the rendering output and a per-block depth buffer that stores the per-block depth information (values) of the rendering output (to date).

[0142] According to the technique described herein, when processing of the rendering output is stopped (but not completed, and therefore to be resumed), the per-sample depth buffer is written to memory so that it can be recovered when processing of the rendering output is resumed. However, instead of writing the per-block depth buffer information (values) to memory (e.g., storage), it is simply discarded.

[0143] The process of stopping the rendering output can be triggered in any suitable and desired manner, thereby triggering storage from the per-sample depth buffer (but not the per-block depth buffer).

[0144] For example, this halt can be triggered by the exhaustion of the current data structure of the rendering output being processed. For instance, in the case of a tile-based graphics processing system, various data structures for a tile are prepared to enable its generation. When the graphics processor is triggered to process a tile, the tile's data structure may be incomplete (not containing all the data required to fully process the tile). Therefore, in this case, the graphics processor will process the (incomplete) data structure of the tile it receives, but once these data structures are complete, the graphics processor then needs to wait for a new data structure containing further data for the tile to become available (to be processed) before it can continue processing the tile.

[0145] For example, this stop can be triggered when the graphics processor needs to switch to generate different overall rendering outputs (e.g., frames). This might occur, for instance, in the case of background switching for virtual reality time warp operations, where, for example, a "time warp" frame is rendered at full frame rate (e.g., 60 fps), and the full frame of the VR application is rendered during the "time warp" shutdown period, then the time warp is preempted as needed. Then, when preemption occurs, a partial frame will be encountered. This operation can also be triggered by interaction with other data, such as geometry caches, for example, when it is desirable to keep geometry in the cache at the expense of pixel traffic.

[0146] When processing of the rendering output in question is stopped, a write-out of the per-sample depth buffer value to memory is triggered. This operation can be performed in any suitable and desired manner, for example, and in the implementation, this operation is performed in the normal manner for the graphics processor and graphics processing system in question.

[0147] Accordingly, the memory to which the per-sample depth buffer value is written can be any suitable and desired memory of the graphics processor (and graphics processing system), or any suitable and desired memory available to the graphics processor (and graphics processing system). In an embodiment, this memory is a suitable memory (main memory) of the graphics processor or a suitable memory (main memory) available to the graphics processor, for example, as part of an overall graphics processing system (data processing system) in which the graphics processor is a part. Thus, in an embodiment, the per-sample depth value from the per-sample depth buffer is written to a suitable DRAM (or other main memory) of the overall graphics (data) processing system. Other arrangements are, of course, also possible.

[0148] Similar to the per-sample depth buffer, in this implementation, when processing of the rendering output is stopped before the rendering output is completed, any other data structures that need to be restored when processing of the rendering output is resumed (such as color buffers (tile buffers) corresponding to the overall output of graphics processing and one or more multisample buffers) are also appropriately written to memory.

[0149] Once the graphics processor stops processing the rendering output in question (and the data structures have been written to memory), the graphics processor can then perform other processing, such as some or all of the processing of another rendering output (such as different tiles of a frame).

[0150] Then, at a later point in time, the graphics processor will be triggered to resume processing of the rendering output, which has only been partially completed. Again, this resumption of processing of the rendering output can be triggered as needed, for example, based on the existence of a new data structure containing new data for the rendering output (e.g., tiles) now ready for processing, a background switch based on VR time warp, etc.

[0151] When processing of the rendered output region resumes, the graphics processor recreates (restores) the per-sample depth buffer and per-block depth buffer of that rendered output so that those buffers can be used when processing of the rendered output continues.

[0152] In the case of a per-sample depth buffer, its re-creation can be accomplished, and in an implementation, by loading the saved per-sample depth buffer values ​​back into the depth buffer for use when processing the rendering output continues. This will recreate the per-sample depth buffer accordingly, in the state it was in when processing the rendering output stopped.

[0153] The per-block depth buffer is also created (restored) based on the previously saved per-sample depth value that is loaded back to repopulate the per-sample depth buffer.

[0154] The previously saved per-sample depth values ​​can be used to create a per-block depth buffer for use as the processing of the output continues in any appropriate and desired manner.

[0155] In this implementation, appropriate block depth information (one or more block depth values) is generated for each block whose value is stored in the block depth buffer, using (based on) per-sample depth values, and this block depth information is stored in the block depth buffer to be used when continuing to render the output. In this implementation, all per-sample depth values ​​falling within a block are considered when generating the depth value information (one or more depth values), which is stored for that block in the recreated block depth buffer.

[0156] If the block depth buffer also stores the depth value range (minimum depth value and maximum depth value) of each block, then, for example, each block entry in the block depth buffer can be set to the default maximum depth value of the block, and then the minimum depth value of the block can be set to the minimum depth value among any of the following per-sample depth values: said per-sample depth value has been restored to the per-sample depth buffer that falls within the block in question, or correspondingly, each block entry in the block depth buffer can be set to the default minimum depth value of the block, and then the maximum depth value of the block can be set to the maximum depth value among any of the following per-sample depth values: said per-sample depth value has been restored to the per-sample depth buffer that falls within the block in question.

[0157] In one implementation, when the depth value range (maximum depth value and minimum depth value) of each block is stored in the per-block depth buffer, the minimum depth value of a block in the recovered per-block depth buffer is set to the minimum per-sample depth value that has been recovered to the per-sample depth value of the sampling position falling within that block. Correspondingly, the maximum depth value of a block in the recovered per-block depth buffer is set to the maximum per-sample depth value that has been recovered to the per-sample depth value of the sampling position falling within that block.

[0158] To facilitate this operation, in one implementation, the per-block depth buffer recovers all per-sample depth values ​​of the scanned block and sets the block depth value accordingly.

[0159] In this implementation, the depth values ​​of each sample in the block are read in and compared sequentially with the current maximum depth buffer value and minimum depth buffer value already set for the block. Based on the comparison, the current maximum block depth value and minimum block depth value are updated or not updated until all sampling positions falling within the block have been taken into account.

[0160] In this implementation, DMA (direct memory access) processing is used to read in the per-sample depth values ​​to be read in to refill the per-sample depth buffer. This is because, as the depth values ​​are read in and stored in the per-sample depth buffer, it is helpful to examine the individual depth values ​​among these depth values, thereby also setting the block depth values ​​accordingly in the per-block depth buffer. The processing core (shader core) of the graphics processor can also perform the loading of the depth buffer.

[0161] In this implementation, the per-sample depth values ​​read to refill the per-sample depth buffer are read in an order corresponding to the layout of the blocks storing the per-block depth values, to facilitate more efficient refilling of the per-block depth buffer. Thus, in this implementation, per-sample depth values ​​are read on a block-by-block basis to refill both the per-sample depth buffer and the per-block depth buffer (i.e., sequentially for that block, all per-sample depth values ​​of the first block are read first, then any samples of another block are read, followed by all per-sample depth values ​​of the next block, and so on). In this implementation, the per-sample depth values ​​are read by traversing the sampling positions in the per-sample depth buffer in an order that matches the order used to recover the values ​​(blocks) in the per-block depth buffer.

[0162] In this implementation, the recovery of the per-block depth buffer also takes into account, and in this implementation, indicates, locations within the block where sampling positions are not covered by primitives. Therefore, for example, and in this implementation, the block can be encoded both for a range of depth values ​​(e.g., the minimum and maximum depth values ​​of the block) and for an indication of which portion(s) of the block the range of depth values ​​(minimum and maximum depth values) applies to. Accordingly, in this implementation, it can be indicated which portions of the block store depth data and which portions of the block do not contain depth data. This can be indicated in any suitable and desired manner. For example, locations within the block where no defined depth values ​​exist can be identified as needed, for example, and in this implementation, based on whether the per-sample depth value at said location in the block is indicated as not covered by primitives (e.g., and in this implementation, represented by having a specific, selected, and predefined depth "clear" value). In this case, each sampling position in the per-sample depth buffer with the depth clear value will then be indicated as not covered by primitives of the block (and therefore without a corresponding, for example, minimum and maximum depth value). Therefore, for example, in the case of an 8 × 8 block, only half of the positions in the block are covered by primitives. Then, in the implementation, the depth buffer of each block is encoded: the "uncovered" half of the block has no depth data, and the remaining covered half of the block has a minimum depth value and a maximum depth value.

[0163] In this implementation, the use of a special value refers to a "clear value," rather than storing the clear value directly in the per-block depth buffer.

[0164] In an implementation, corresponding bits (e.g., in a tile buffer) can be configured to indicate whether a sample location is covered or uncovered, indicating coverage of the corresponding sample location (or a set of sample locations). Then, during write-out, in an implementation, the key value is encoded to indicate uncovered when appropriate, and a depth-cleared value is used.

[0165] Other arrangements are certainly possible.

[0166] In the case where the per-block depth buffer is configured to store the depth values ​​of the hierarchical layout of the blocks (as discussed above), then, in the implementation, the per-block depth buffer is appropriately refilled across all levels of that hierarchy based on the per-sample depth buffer value. In the implementation, to facilitate this refilling, the memory layout of the per-block depth buffer is configured to facilitate more efficient reconstruction. Thus, in the implementation, the per-block depth buffer is configured to store the smaller blocks (lower levels) in a specific, predefined, and appropriately fixed pattern relative to the larger blocks containing the smaller blocks (therefore, for example, the per-block depth buffer will store the largest 16 × 16 block in a fixed pattern as a 2 × 2 region).

[0167] Accordingly, in this implementation, the per-block depth buffer is refilled to facilitate more efficient reconstruction of per-block data for layering. Thus, in this implementation, a minimum (e.g., 2 × 2) block depth value is generated (in this implementation and within the coverage area), and then when considering 4 × 4 blocks in the next layer, the minimum depth of the four 2 × 2 blocks within the 4 × 4 block becomes (set to) the minimum depth of the 4 × 4 block, and the maximum depth of the four 2 × 2 blocks becomes (set to) the maximum depth of the 4 × 4 block. Coverage data from the base 2 × 2 blocks is also propagated up to the 4 × 4 layer. This operation is then repeated for each subsequent higher (larger block) layer as appropriate.

[0168] Therefore, with the per-block depth buffer configured to store the depth values ​​of the hierarchical layout of blocks (as discussed above), then, in the implementation, the per-sample depth values ​​read back are used to set and fill the per-block depth values ​​of the lowest-level blocks (the smallest blocks in the block subdivision hierarchy), and then the per-block depth values ​​of the higher-level (larger blocks) are set based on the per-block depth values ​​of the lower-level (smaller) blocks contained in the higher-level (larger) blocks in the block hierarchy.

[0169] Other arrangements are certainly possible.

[0170] Like the depth buffer, in the implementation, any other data structures that need to continue processing the rendering output (e.g., tiles) (such as the current color (tile) buffer of the rendering output when processing of the rendering output stops) are also restored from their previously saved values ​​in the appropriate time and in the appropriate manner.

[0171] Once the depth buffer and any other data structures (such as color buffers (tile buffers), any multisample buffers, etc.) of the rendered output being processed have been properly created (restored), the processing of the rendered output can then be resumed in the implementation. Therefore, once the graphics processor loads the per-sample depth buffer values ​​written to memory into the per-sample depth buffer for use during continued processing of the rendered output, and has used the restored per-sample depth buffer values ​​to store a set of per-block depth value information in the block depth buffer for use by the block early depth test circuitry when performing block early depth testing of the primitives during continued processing of the rendered output, the graphics processor will resume the processing of the primitives of the rendered output, including performing block early depth testing on the primitives of the rendered output using the block depth value information of the rendered output in the (restored) per-block depth buffer, and performing depth testing on the primitives with respect to the sampling positions of the rendered output being generated using the depth values ​​of the sampling positions of the rendered output being generated in the (restored) per-sample depth buffer.

[0172] As can be appreciated from the above, at least in the implementation, the techniques described herein will involve partially processing a first rendering output (e.g., a tile), then pausing the processing of the first rendering output while processing another rendering output (e.g., a tile), and then resuming the processing of the first rendering output, and so on, for example, in which switching repeatedly occurs between processing different rendering outputs.

[0173] Therefore, in implementation, the method of the technique described herein includes (and the graphics processor is configured accordingly):

[0174] The graphics processor stops processing the first rendering output, and while the graphics processor does so, it performs the following operations:

[0175] Write the per-sample depth value in the per-sample depth buffer of the first rendering output to the storage so that the per-sample depth value can be recovered when processing of the first rendering output continues, but discard the per-block depth value information in the per-block depth buffer of the first rendering output.

[0176] After stopping the processing of the first rendering output, the graphics processor performs the following operations:

[0177] The steps of processing primitives to generate a second, different rendering output include:

[0178] A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the second rendering output being generated, for use by the block early depth testing circuitry when performing block early depth testing of primitives with respect to that block; and

[0179] A per-sample depth buffer stores the depth values ​​of one or more sampling locations of the second rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the second rendering output being generated;

[0180] The graphics processor stops processing the second rendering output, and while the graphics processor does so, it performs the following operations:

[0181] Write the per-sample depth value in the per-sample depth buffer of the second rendering output to the storage so that the per-sample depth value can be recovered when processing of the second rendering output continues, but discard the per-block depth value information in the per-block depth buffer of the second rendering output.

[0182] After stopping the processing of the second rendering output, the graphics processor performs the following operations:

[0183] The processing of the first rendered output is restored; and when the graphics processor does so, the following operations are performed:

[0184] The per-sample depth buffer value to be written to the memory of the first rendering output is loaded into the per-sample depth buffer for use while processing the first rendering output continues; and

[0185] Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the block early depth test circuit when performing block early depth testing of primitives while continuing the processing of the first rendering output.

[0186] In this case, in the implementation, the first rendering output and the second rendering output include corresponding different tiles of the overall rendering output being generated (loaded frames to be displayed).

[0187] Accordingly, the processing of two or more render outputs (e.g., tiles) can be interleaved in this way. Similarly, the processing of a given render output can be stopped and resumed multiple times (more than once), for example, until the render output is complete.

[0188] Although the techniques described herein have been described above with reference to writing out and then restoring the depth buffer during graphics processing, the applicant recognizes that the idea of ​​constructing a per-block depth buffer from a per-sample depth buffer in the manner described herein can also be useful in other contexts where a per-block depth buffer is required, such as, and in particular, where a “pre-computed” depth buffer can be provided to the graphics processor (but not a corresponding “pre-computed” per-block depth buffer).

[0189] For example, the applicant has recognized that it is possible for applications requiring graphics processing to provide pre-generated (pre-computed) depth buffers for use by the graphics processor, and / or for depth buffers to be provided from non-GPU sources. In this case, the per-sample depth buffer may be generated, for example, on the CPU of the graphics processing system, or generated by the graphics processor but outside of normal rendering processing (e.g., as a prior computation pass or an unrelated rendering pass), and / or otherwise provided or downloaded from mass storage devices for use by the graphics processor.

[0190] Therefore, in this case, a pre-generated per-sample depth buffer will be provided. However, the applicant has recognized that it can still be useful in this case to construct a per-block depth buffer from the provided per-sample depth buffer, for example, for use in layered depth testing processing. Moreover, the applicant has recognized that this generation of a per-block depth buffer from the provided per-sample depth buffer can be advantageously accomplished in a manner described herein as above.

[0191] Therefore, the technique described in this paper is also extended to the concept of recovering a per-sample per-block buffer from a provided per-sample depth buffer in the manner discussed above.

[0192] Therefore, another embodiment of the technology described herein includes a method of operating a graphics processor, the graphics processor comprising:

[0193] A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; and

[0194] A renderer that processes the fragments generated by the rasterizer to generate output fragment data;

[0195] When the rasterizer receives a primitive to be rasterized, it tests the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block.

[0196] The graphics processor also includes:

[0197] An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and

[0198] A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives;

[0199] The method includes the following steps:

[0200] The graphics processor performs the following operations:

[0201] The per-sample depth buffer value is loaded into the per-sample depth buffer for use during the processing of the rendering output. The per-sample depth buffer stores the depth values ​​at various sampling locations within one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuitry when performing primitive depth testing with respect to the sampling locations of the rendering output being generated; and

[0202] Using the loaded per-sample depth buffer values, a set of per-block depth value information is stored in a per-block depth buffer for use by the early block depth test circuit when performing early block depth tests during the processing of the rendering output. The per-block depth buffer stores the depth value information of each block in one or more blocks representing a different region of the rendering output being generated, for use by the early block depth test circuit when performing early block depth tests on primitives for that block.

[0203] Another embodiment of the technology described herein includes a graphics processor, the graphics processor comprising:

[0204] A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; and

[0205] A renderer that processes the fragments generated by the rasterizer to generate output fragment data;

[0206] The rasterizer is configured to, when receiving a primitive to be rasterized, test the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block.

[0207] The graphics processor also includes:

[0208] An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and

[0209] A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives;

[0210] The graphics processor is also configured to perform the following operations when processing primitives to generate rendering output:

[0211] A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and

[0212] A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated;

[0213] The graphics processor is also configured to perform the following operations:

[0214] Load the per-sample depth buffer values ​​of the rendered output into the per-sample depth buffer for use when processing the rendered output; and

[0215] Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output.

[0216] As will be apparent to those skilled in the art, these aspects of the technology described herein may, and in one embodiment, include any one or more or all of the features of the technology described herein. Therefore, in particular, the per-block depth buffer in the embodiment has the form discussed above, and the process of constructing the buffer from the provided per-sample depth buffer is performed in the manner discussed above in the embodiment.

[0217] Accordingly, in these embodiments of the technology described herein, the per-sample depth buffer is provided to the graphics processor as a pre-generated (pre-computed) depth buffer, for example from a non-graphics processor source (or from previous operations of the graphics processor) (rather than a per-sample depth buffer that is partially completed due to interruption of graphics processor operations).

[0218] Other arrangements and sources of the per-sample depth buffer are of course also possible.

[0219] Like rasterizers, depth testers, and renderers, graphics processors and their graphics processing pipelines may include and should include graphics processors and other processing circuitry and stages typically present in the processing pipeline, such as tile buffers (and other buffers), write-back units, mixers, etc.

[0220] The graphics processor may also include, and in some embodiments, one or more memory and / or memory devices for storing data described herein (such as fragment data, rendered fragments and output data, block and sampled location depth data (depth value data, etc.), and other state information, and / or storing software for performing the processing described herein, and / or communicating with said one or more memory and / or memory devices. The graphics processor may also communicate with a host microprocessor and / or with a display for displaying images based on data generated by the graphics processor.

[0221] The techniques described herein can be used regardless of the form of output that the graphics processor can provide. Therefore, for example, it can be used when the rendered output is intended to form an image (frame) for display (e.g., on a screen or printer) (and this is the case in the implementation). However, the techniques described herein can also be used when the rendered output is not intended for display, for example, when the rendered output is a texture that the graphics processor is using to generate (e.g., in a "render to texture" operation), or, in fact, when the output that the graphics processor is using to generate is any other form of data array.

[0222] The various functions of the technology described herein can be performed in any desired and suitable manner. For example, the functions of the technology described herein can be implemented in hardware or software as needed. Thus, for example, the various functional components, processing levels, and “means” of the technology described herein can include suitable one or more processors, one or more controllers, functional units, circuits, circuit systems, processing logic, microprocessor layouts, etc., capable of performing various functions, such as dedicated hardware components (processing circuits / circuit systems) and / or programmable hardware components (processing circuits / circuit systems) that can be programmed to operate in a desired manner.

[0223] It should also be noted that, as those skilled in the art will recognize, the various functions of the techniques described herein can be copied and / or executed in parallel on a given processor. Similarly, various processing levels can share processing circuitry / systems, etc., if desired.

[0224] The techniques described herein can be applied to graphics processing systems, graphics processors, and graphics processing pipelines of any suitable form or configuration. The techniques described herein are particularly applicable to tile-based graphics processors and graphics processing systems. Thus, in this embodiment, the graphics processor is a tile-based graphics processor.

[0225] For any hardware subject necessary to perform the specific functions discussed above, a graphics processor may otherwise include one or more or all of the common functional units, circuits, etc., included in that graphics processor.

[0226] Those skilled in the art should also recognize that all the described embodiments of the technology described herein may, where appropriate, include any one or more or all of the features described herein.

[0227] The methods described herein can be implemented at least in part using software (e.g., computer programs). Thus, it can be seen that, when viewed from other embodiments, the techniques described herein provide computer software, which, when installed on a data processor, is specifically adapted to perform the methods described herein; a computer program component comprising computer software code for performing the methods described herein when the program component is run on a data processor; and a computer program comprising software code adapted to perform all steps of the methods described herein, or all steps of one of the methods, when the program is run on a data processing system. The data processing system may be a microprocessor, a programmable FPGA (Field-Programmable Gate Array), etc.

[0228] The techniques described herein are also extended to computer software carriers that, when used to operate a graphics processor, renderer, or microprocessor system including a data processor, cause the steps of the methods described herein to be performed in conjunction with said data processor, said processor, renderer, or system. Such computer software carriers can be physical storage media, such as ROM chips, CD-ROMs, RAM, flash memory, or disks, or they can be signals, such as electronic signals transmitted through wires, optical signals such as satellite signals, or radio signals.

[0229] It should also be understood that not all steps of the method described herein need to be performed by computer software, and thus, according to another broad implementation, the technology described herein provides computer software for performing at least one step of the method described herein and such software installed on a computer software carrier.

[0230] Therefore, the techniques described herein can be suitably implemented as computer program products for use with computer systems. Such implementation may include a series of computer-readable instructions fixed on a tangible medium such as a non-transitory computer-readable medium (e.g., floppy disk, CD-ROM, ROM, RAM, flash memory, or hard disk). Such implementation may also include a series of computer-readable instructions that can be invisibly transmitted to a computer system via a modem or other interface device through a tangible medium (including, but not limited to, optical or analog communication lines) or using wireless technologies (including, but not limited to, microwave, infrared, or other transmission technologies). This series of computer-readable instructions specifically implements all or part of the functions previously described herein.

[0231] Those skilled in the art will recognize that such computer-readable instructions can be written in many programming languages ​​for use with many computer architectures or operating systems. Furthermore, such instructions can be stored using any current or future memory technology (including, but not limited to, semiconductor, magnetic, or optical memory technologies), or transmitted using any current or future communication technology (including, but not limited to, optical, infrared, or microwave communication technologies). It is envisioned that such computer program products can be distributed as a removable medium (e.g., shrink-wrapped software) with accompanying printed or electronic documentation, pre-installed with a computer system (e.g., on a system ROM or hard drive), or distributed from a server or electronic bulletin board via a network (e.g., the Internet or the World Wide Web).

[0232] Several implementations of the technology described herein will now be described.

[0233] Figure 1 A graphics processor 1 is schematically shown that performs a graphics processing pipeline and can operate according to the techniques described herein.

[0234] Figure 1 The main components and pipeline stages of the graphics processor 1 related to the operation of this embodiment are shown. As those skilled in the art will appreciate, there may be… Figure 1 Other components of the graphics processor not shown in the diagram. It should also be noted here that... Figure 1 This is merely illustrative, and in practice, for example, the functional units and pipeline stages shown can share effective hardware circuitry, even when... Figure 1 They are schematically shown as separate levels. It should also be recognized that, as Figure 1 Each of the stages, components, and units of the graphics processor shown can be implemented as needed, and accordingly, for example, includes appropriate circuitry / circuit systems and / or processing logic for performing the necessary operations and functions.

[0235] Figure 1 The graphics processor shown is a tile-based processor. Therefore, graphics processor 1 generates a tile-based array of rendering output data, such as the output frame to be generated (where each tile corresponds to a different region (e.g., a square region) of the overall output frame). (The techniques described herein are also applicable to other systems, such as real-time rendering systems.) The output data array can typically be an output frame intended for display on a display device (such as a screen or printer), but can also include, for example, the graphics processor's "render to texture" output.

[0236] Figure 1 The pipeline stage is schematically shown after the generation of graphic primitives (polygons) 2 for input to rasterization processing. Thus, at this point, the graphic data (vertex data) has undergone transformation and lighting operations (not shown), and the primitive setting stage (not shown) has set the primitives to be rendered in response to commands provided to the graphics processor 1 and the vertex data.

[0237] like Figure 1 As shown, this part of the processing pipeline of the graphics processor 1 includes multiple processing stages, including: a rasterizer 10 including a rasterization circuit 3 and an early layered ZS (depth and stencil) test circuit 4, an early Z (depth and stencil) test circuit 9, a rendering circuit 6 in the form of a programmable fragment shader, and a late ZS (depth and stencil) test circuit 7.

[0238] The graphics processor 1 also includes and / or has access to (communicate with) appropriate (local) storage (buffers) for storing data that it will use and / or generate, including: a "per-block" layer depth and stencil buffer 11, a per-sample location depth and stencil buffer 5, a tile (color) buffer 8, etc.

[0239] As needed, these buffers can be kept in the appropriate local storage of the graphics processor (e.g., RAM) or in the appropriate local storage accessible to the graphics processor (e.g., RAM), and can be stored in the same or different physical storage devices (e.g., RAM).

[0240] The graphics processor 1 can also access (communicate with) the main memory 12, which can store data such as tiles and depth generated by the graphics processor, for example, for later use.

[0241] Rasterizer 10 operates to rasterize the primitives that make up the rendered output (e.g., tiles of an image to be displayed) into individual graphic fragments for processing. To do this, rasterizer 10 receives the graphic primitive 2 to be rendered, rasterizes the primitive for sampling points, and generates graphic fragments with appropriate positions (representing appropriate sampling locations) for rendering the primitive. In this embodiment, each graphic fragment generated by rasterizer 10 represents (and is associated with) multiple (typically four) sampling locations. (Other arrangements are, of course, possible). Each graphic fragment has an associated overlay mask that indicates which sampling points of the multiple sampling locations represented by the fragment are actually being used for rendering (i.e., are actually covered by the primitives in question).

[0242] In this embodiment, rasterizer 10 is a layered rasterizer that operates to iteratively test primitives for the following blocks (regions) (and thus, correspondingly, fragment blocks) of the rendered output (target) area: the size of the block is progressively reduced until a minimum block size, which in this embodiment corresponds to a 2 × 2 fragment group (i.e., an array of sample points corresponding to a 2 × 2 fragment group to be rasterized), discarding any blocks not covered (at least partially covered) by the primitive. The individual blocks being tested correspond to a given set of fragments.

[0243] The rasterization circuit 3 of rasterizer 10 performs the render output block test. To do this, the rasterizer starts with a larger block of the render output (render target) area and tests the block against the edges of the primitive in question to determine whether the primitive at least partially covers any block of the render output (render target area) that divides the larger block into (contains) a set of smaller blocks of 2 × 2.

[0244] The edges of primitives are represented by appropriate line (edge) equations derived from the vertices of the primitives, and a sampling point mesh is derived for the block being tested (and for each block). The block sampling points are then used with the line equations representing the edges of the primitives in question to perform edge testing on the edges to determine whether the block is at least partially covered by the primitive.

[0245] In this embodiment, the rasterization circuit 3 determines that a block of the rendered output is at least partially covered by primitives if at least one of the following conditions is met: at least one edge of the block is inside a primitive; at least one edge of the block intersects with an edge of a primitive; at least one vertex of a primitive is inside the block; or at least one vertex of a primitive is on an edge of the block, and if the vertex is on an edge of the block, then another vertex of the primitive is on another edge of the block, or if the vertex is on a corner of the block, then another vertex is on a opposite corner of the block or on one of the opposite edges of the block.

[0246] Other arrangements are certainly possible.

[0247] If a larger block is found to be completely covered by primitives, then no further processing will be done on that block (i.e., the entire block will be discarded for that primitive), and another (next) larger block will be tested for that primitive, and so on.

[0248] On the other hand, if a primitive is found to at least partially cover any of the smaller blocks in a set of multiple smaller blocks contained in (i.e., subdivided into) a larger block in the rendered output (i.e., the primitive is found to at least partially cover the larger block), the larger block is subdivided into its four smaller blocks, and then each such covered smaller block (“sub-block”) is tested against the primitive and processed in the same way (i.e., discarded, or subdivided into a set of even smaller blocks depending on whether the smaller block is covered by the primitive).

[0249] Continue this process of testing, discarding, or subdividing blocks until the minimum block size is reached.

[0250] This implementation supports four levels of subdivision (three subdivision iterations), thus starting with a larger block corresponding to a 16 × 16 segment, and then subdividing the larger block (if appropriate) into four 8 × 8 segment blocks. Then, each of those 8 × 8 segment blocks is subdivided into a corresponding 4 × 4 segment block (if appropriate). Finally, each 4 × 4 segment block is subdivided into a corresponding 2 × 2 segment block (if appropriate). As in this implementation, the 2 × 2 segment block is the smallest block size used, at which point the (potential) subdivision process stops. Other arrangements are, of course, also possible.

[0251] Figure 2 The subdivision process is illustrated and a top-level 16 × 16 segment is shown, progressively subdividing the block down to the smallest block size of a 2 × 2 segment.

[0252] Once the minimum block size has been reached (i.e., a block of at least 2 × 2 segments that partially cover primitives has been identified), the rasterization circuit 3 then tests individual sample points within that final block to see if they are covered by primitives. The rasterizer 10 then generates and outputs individual segments (four segments if all 2 × 2 segments in the minimum-size block are at least partially covered by primitives) corresponding to the sample points found to be covered by primitives for rendering.

[0253] Rasterizer 10 also associates each fragment with an overlay mask in the form of a sample bitmap, which indicates whether a sample location is covered (i.e., whether the fragment is actually being used to render the sample point (i.e., whether the fragment's data should be stored for the sample point)) for each sample location in the sample location set associated with the fragment.

[0254] In this embodiment, the rasterization process sequentially tests each largest block for the primitive, then subdivides the block, and then tests the related smaller blocks (sub-blocks) within the largest block, and so on, until all subdivisions and tests for the largest block have been completed.

[0255] Once the segmentation and testing are complete, the rasterization process moves to the next first level, the largest block, and tests that block, and so on.

[0256] Other arrangements are certainly possible.

[0257] In this embodiment, each primitive to be rasterized is tested for each first-level (larger-sized) block of the rendered output that at least partially falls within the bounding box generated for the primitive (i.e., is at least partially covered by the bounding box). Other arrangements are of course also possible.

[0258] Once all the highest-level, largest-size blocks of the rendered output have been tested for primitives (and subdivided or discarded as appropriate), the rasterization process moves on to the next primitive in the rendered output being generated, and so on.

[0259] In this embodiment, rasterizer 10 is configured to include and process multiple blocks in a pipeline simultaneously. Rasterizer 10 is also configured to generate multiple fragments at once (simultaneously) (e.g., when primitives are found to completely cover a block of the rendered output containing multiple fragments (e.g., multiple sample points or sets of sample points). These fragments are still processed separately by the fragment processing portion of the pipeline (such as a renderer (fragment shader)). Enabling the rasterizer to generate multiple fragments simultaneously helps create backpressure, thus keeping the rendering pipeline "full" of fragments.

[0260] Other arrangements are certainly possible.

[0261] like Figure 1 As shown, the rasterizer 3 also has an associated early per-block “layering” depth (Z) and stencil testing circuit 4. This layering depth and stencil testing circuit 4 performs “early” depth and stencil testing on the blocks generated by the rasterizer 3 to see if those blocks can be discarded.

[0262] To achieve this, the individual blocks of the rendered output generated at rasterization level 3 are sent to the early layer depth and stencil test circuit 4, which then performs a Z (depth) test on the blocks of the rendered output to see if the block can be discarded (culled) at that level. Simultaneously, an early stencil test is performed.

[0263] To do this, the early per-patch depth and stencil tester 4 uses the per-patch depth and stencil values ​​stored in the hierarchical per-patch depth and stencil buffer 11.

[0264] Each block layer depth and stencil buffer 11 stores a set of depth value information that can divide the rendering output into individual blocks, as part of the rasterization process (essentially, a set of depth value information (size and position) that the rasterization circuit 3 can generate for each block of the tile being processed). (Therefore, in this embodiment, as...) Figure 2 The depth values ​​of each block are shown. Then, the layered early depth and template tester 4 uses the stored depth value information to perform depth tests on the portions of the rasterized primitives that are found to fall into the blocks.

[0265] In this embodiment, the depth value information stored for each block includes an indication of the depth value range of the block, and adopts the form of the minimum depth value and the maximum depth value of the block.

[0266] The depth value range stored for each block is initially set to a default value, or, if the depth value range of the block can be determined, to the expected depth value range. (In some arrangements, the possible depth values ​​that a primitive of a block may have can be known in advance. These possible depth values ​​can then be used to populate the per-block depth buffer 11 using the expected depth value range of the block in question.) As discussed further below, the stored block depth value range is then updated as primitives being tested by the earlier per-block layered depth and template test circuit 4 pass the depth test.

[0267] It also stores the corresponding template value set for each block to be used for template testing.

[0268] When a block is to undergo the Early Per-Block Layered Depth and Template Test 4, the Early Per-Block Depth and Template Test 4 uses the stored block depth and template test information stored in the Layered Per-Block Depth and Template Buffer 11 to perform the test. If appropriate (essentially, if the new primitive at least partially passes the depth and template test), then the stored depth and template test information of the block in question is also updated. (The template test can also trigger a "failed" update.)

[0269] (If the depth test for a primitive fails, the existing depth value information for the block in question is retained.)

[0270] To perform a depth test on a block, the corresponding depth values ​​for each corner of the block are determined for the block and for the primitive being tested, and then compared in the depth test.

[0271] In this embodiment, since the block depth value is represented as a minimum and a maximum value, it is assumed that each corner of the block has a corresponding minimum and maximum depth value. Figure 3 This is illustrated, and the corresponding depth values ​​derived for the corners of the block are shown.

[0272] The depth values ​​used to test the primitives are derived using a depth function defined for the primitives in question. As in this embodiment, the block depth values ​​are in the form of minimum and maximum depth values, and the depth function of the primitives is used to determine the appropriate minimum and maximum depth values ​​for the primitives at each corner of the block. Figure 4 This is illustrated, showing the depth values ​​derived for the corners of a block. The process can also consider any requirements that force the depth values ​​of the primitives to other values, for example, depending on the source of the depth and template values ​​and whether the depth and template values ​​of the primitives are unknown.

[0273] Once the depth values ​​of blocks and primitives have been determined, these depth values ​​can be used to perform depth tests.

[0274] In this embodiment, a min / max z-test is performed, which is applied to [z... buf_lo , z buf_hi To compare [z] lo , z hi ], to find the [z lo , z hi Is it greater than, less than, or overlapping? buf_lo , z buf_hi ]:

[0275] zrange_greater_than = z lo > z buf_hi

[0276] zrange_less_than = z hi < z buf_lo

[0277] zrange_equal = (z lo == z hi == z buf_lo == z buf_hi )

[0278] zrange_overlap = !( zrange_greater_than || zrange_less_than ||zrange_equal)

[0279] The result of this test is then used to determine whether the z-test passes, fails, or is indeterminate; for example, based on a depth test function defined for the rendered output and / or primitives.

[0280] The result of the depth test will be one of the following: pass; partially pass; or fail.

[0281] If all tests pass and the rasterizer mask is full, the block is fully covered; otherwise, it will be partially covered or uncovered. The overlap range indicates partial coverage.

[0282] Other arrangements for per-block depth testing are certainly possible.

[0283] As needed, per-block template tests can be performed accordingly. When performing per-block template tests, the template values ​​for each corner of the block of the graphic element and the template values ​​for each corner of the block of the graphic element can be derived in a corresponding manner based on how the template values ​​are defined for the graphic element and the block in question.

[0284] Configure the early layer depth and template tester 4 to operate in an appropriately conservative manner.

[0285] In response to depth and stencil tests, the buffer will be updated as appropriate, and if stencil_fail or z_fail, the block is discarded (stopping block processing), or if stencil_pass and z_pass, the block is retained.

[0286] For each block of the rendered output that is found to be at least partially covered by the primitive in question, the process will be repeated, and then the process will be repeated for the next primitive of the rendered output that has been processed, and so on.

[0287] As discussed above, any block that passes the early depth and stencil test of each block is returned to the rasterization circuit 3 for further subdivision into smaller blocks (“sub-blocks”). The individual (covered) “sub-blocks” are then returned to the early depth and stencil tester 4 for testing, and so on, until the minimum block size is reached.

[0288] Once the minimum block size is reached (a 2 × 2 segment block in this embodiment), the rasterizer 10 sends the segment of the representation block (and thus the sampling points) through the early layering Z and stencil test 4 to the rest of the graphics processing pipeline for processing.

[0289] Therefore, in this embodiment, the rasterization process begins with the following steps: testing primitives against a first large set of blocks in the rendered output, then subdividing the larger blocks in that set that are found to be at least partially covered by primitives (and for that larger block, at least a portion of the primitives within that block has passed an early depth test (and any other early culling test)) into smaller sets of blocks in the rendered output until a minimum block size is reached. One or more fragments are then generated for rendering blocks that are found to be at least partially covered by the primitives in question (and for that block, at least a portion of the primitives within that block has passed an early depth test (and any other early culling test)).

[0290] The first part of the process is to subject the individual segments emitted (output) by the rasterizer 10 to per-sample early depth and stencil testing in the per-sample early depth and stencil testing circuit 9. The per-sample early depth and stencil testing circuit 9 performs depth and stencil testing at individual (covered) sampling locations (i.e., at per-sample resolution) associated with the segments emitted by the rasterizer 10.

[0291] To achieve this, the per-sample early depth and template tester 9 uses the per-sample location depth and template values ​​stored in the per-sample depth and template buffer 5. Therefore, the depth and template buffer 5 stores the appropriate depth (Z) value and template value for each sampling location represented by the buffer (essentially, each sampling location of the tile being processed). These values ​​are stored in the depth and template buffer 5 when the sampling point being tested by the per-sample early depth and template test circuit 9 and the per-sample late depth and template test circuit 7 passes the corresponding depth and template test (template values ​​can also be stored / updated when the test fails).

[0292] Configure the early per-sample depth and template tester 9 to operate in an appropriately conservative manner.

[0293] Then, the fragments that have passed the early per-sample depth and stencil test 9 (i.e., fragments with at least one associated covered sampling position passed by the early per-sample depth and stencil test 9) are forwarded to the fragment shading circuit 6 (renderer), as follows: Figure 1 As shown.

[0294] (Segments that failed the early per-sample depth and template test 9 were removed by the early per-sample depth and template test 9.)

[0295] The fragment coloring circuit 6 performs appropriate fragment processing (rendering) operations on the received fragment in order to process the fragment and generate appropriate fragment data, etc., for rendering output (e.g., for displaying the fragment).

[0296] The fragment processing can include any suitable and desired fragment shading processing, such as executing fragment shader programs on the fragment, applying textures to the fragment, applying blending, fogging, or other operations to the fragment to generate appropriate fragment data. In this embodiment, the fragment shading circuit 6 takes the form of a programmable fragment shader that executes a shader pipeline; however, it is also possible, as needed, to use fixed-function fragment shading units or other arrangements that replace fixed-function shading units.

[0297] Therefore, there is a “late” per-sample depth and stencil test circuit 7, which (assuming that this test circuit is to be performed, for example, in the case that the fragment has not actually undergone the early per-sample Z and stencil tests) performs pipeline depth tests at the end, especially on the tinted fragments (on the covered sample points associated with the tinted fragments), to determine whether the sample points represented by the rendered fragments will overdraw the fragments whose values ​​are currently stored in the tile buffer 5 (i.e., to determine whether the fragment data of the fragments emitted from the fragment tinting pipeline 6 should be stored in the tile buffer 8 (which should replace or modify the fragment data in the tile buffer of the already rendered fragments)).

[0298] To do this, the late per-sample depth test circuit 7 compares the depth value of the covered sampling position of the fragment emitted from the fragment coloring circuit 6 (the depth value associated with that sampling position) with the (per-sample position) depth value of the sampling position in question stored in the per-sample depth buffer 5. The depth value of the sampling point obtained by the late per-sample depth test 7 is also appropriately written to the per-sample Z buffer 5 to update it.

[0299] The post-sample depth and template test 7 also performs any required post-sample alpha and / or template tests on the fragment.

[0300] Then, the segment that will pass the later per-sample test 7 is subjected to any remaining operations necessary for that segment, such as mixing with the frame buffer, dithering, etc. (not shown).

[0301] Finally, the output fragment data values ​​are written to the appropriate tile buffer (color buffer) 8, which stores the appropriate (e.g., color) values ​​for each sample position represented by the buffer (essentially the sample positions of the tile being processed (rendered output)).

[0302] Once each tile has been processed, the tile's data is exported from the tile buffer 8 to the main memory 12 (e.g., to the frame buffer in the main memory) for storage, and then another tile is processed, and so on, until enough tiles have been processed to generate all the rendering output (e.g., the frame (image) to be displayed).

[0303] Other arrangements for fragment processing are also possible.

[0304] This embodiment specifically relates to the operation of the graphics processor 1 when the processing of a tile being rendered is interrupted, requiring resumption of that processing at a later time. This is, for example, in incremental tile rendering (e.g., using per-tile multiprocessing), where the multiprocessing steps for a tile are distributed across the processing of other tiles. This operation can occur, for example, when the amount of data that can be generated to process a tile is limited, such that tile processing begins only after some, but not all, of the data required to fully process the tile has been generated, and that once the initially generated data structure has been used, tile processing must be paused, resumed when further data for processing the tile is generated, and once more data for processing the tile has been generated, and so on. This operation can be repeated for multiple tiles that make up the overall rendering output (e.g., a frame to be displayed).

[0305] Figure 5 The operation in this embodiment is illustrated, wherein the process is stopped before the processing of the tiles is completed. Figure 1 The graphics processor shown processes the tile and then restores it to complete the processing of the tile. Figure 5 This example illustrates a scenario where two processing passes are required to complete the processing of a block. However, two processing passes may be necessary, and in this case, Figure 5 The illustrated operations will be similarly applied to the corresponding (partial) processing steps of the block.

[0306] Figure 5 The operation of the first processing step 50 is first shown when the processing of the block begins.

[0307] like Figure 5 As shown, in the first processing step 50, the processing of the tile begins, and all buffers to be used when processing the tile (including the layer per block depth and template buffer 11, the per sample depth and template buffer 5, and the tile (color) buffer 8) are initialized (cleared) to their respective default values ​​(step 51).

[0308] Then, the processing of the primitives of the block begins (step 52). This processing is based on the above reference. Figures 1 to 4 The method discussed is used for execution.

[0309] Then, determine whether to stop processing the tile, for example, because all current data used to process the tile has been processed (used). In this case, since the processing of the entire tile has not yet been completed, the tile buffer will need to be available when resuming tile processing. To facilitate this, such as... Figure 5 As shown, the contents of the tile (color) buffer are written to memory 12 (step 54) so ​​that they can be restored during the tile restoration process.

[0310] Accordingly, the contents of the per-sample depth buffer 5 are written to the memory 12 (step 55) so that the per-sample depth buffer can be restored again during the process of restoring the tiles.

[0311] However, instead of writing the contents of the layer depth and template buffer 11 for each block to memory 12, the buffer is discarded (invalidated) (step 56).

[0312] At a later time, in the second processing pass 60, the graphics processor will resume processing of the interrupted tiles. (During this period, the graphics processor may, for example, switch to processing one or more other tiles of the rendered output, while generating further data about the tiles whose processing had been stopped.)

[0313] When the processing of the block is resumed in the subsequent processing step 60, the depth and stencil buffers and the block (color) buffer must be restored to their state (their contents) when the processing of the block was stopped (so that the processing of the block can continue correctly).

[0314] Therefore, as Figure 5 As shown, in the subsequent processing step 60, when the processing of the tile is restored, the previously stored contents of the tile (color) buffer are loaded from the memory into the tile (color) buffer 8 (step 61).

[0315] Accordingly, the previously stored contents of the per-sample depth and template buffer 5 are loaded from memory 12 into the per-sample depth and template buffer 5 (step 62).

[0316] like Figure 5 As shown, the per-sample depth buffer values ​​loaded into the per-sample depth and template buffer 5 are also used to reconstruct (repopulate) the per-block layer depth and template buffer 11 (step 63). This then allows the “current” state of the per-block layer depth and template buffer 11 to be reconstructed for use in the second processing step 60 when the processing of the tiles is resumed, although the contents of the buffer are discarded when the processing of the tiles is stopped (in the first processing step 50).

[0317] To reconstruct the layered depth and template buffer values ​​for each block, the per-sample depth values ​​(in step 62) of the per-sample depth and template buffer 5, which are used to repopulate the buffer, are used to determine the minimum and maximum depth values ​​for each block. The per-block layered depth and template buffer 11 stores the depth value range for that block. The thus determined minimum and maximum depth values ​​for each block are then appropriately loaded into the per-block layered depth and template buffer 11 to repopulate the buffer for use when continuing the processing of the blocks.

[0318] In this embodiment, since the block depth buffer stores the maximum and minimum depth values ​​of each block, the minimum depth value of a block in the recovered block depth buffer is set to the minimum per-sample depth value of the sampling position falling within the block that has been recovered to the per-sample depth value of the per-sample depth buffer. Correspondingly, the maximum depth value of a block in the recovered block depth buffer is set to the maximum per-sample depth value of the sampling position falling within the block that has been recovered to the per-sample depth value of the per-sample depth buffer.

[0319] To achieve this, in this embodiment, DMA (direct memory access) is used to process the sequential reading of each per-sample depth value of the block and compare it with the current maximum depth per block buffer value and minimum depth per block buffer value already set for the block. Based on this comparison, the current maximum block depth value and minimum block depth value are updated or not updated until all sampling positions falling within the block have been considered.

[0320] The per-sample depth values ​​that are read in to refill the per-sample depth buffer are read in block by block in an order corresponding to the layout of the blocks that store the per-block depth values.

[0321] Since the per-block depth buffer is configured to store the depth values ​​of the hierarchical layout of blocks (as discussed above), in this embodiment, the per-sample depth values ​​read back are used to set and fill the per-block depth values ​​of the lowest-level blocks (the smallest blocks in the block subdivision hierarchy), and then the per-block depth values ​​of higher-level blocks are set based on the per-block depth hierarchy of the lower-level blocks contained in the higher-level (larger) blocks in the block hierarchy.

[0322] The per-sample depth values ​​read to repopulate the per-sample depth buffer are read in an order corresponding to the layout of the blocks storing the per-block depth values, in order to facilitate more efficient repopulation of the per-block depth buffer. The per-sample depth values ​​are read by traversing the sampling positions in the per-sample depth buffer in an order that matches the order in which the values ​​(blocks) in the per-block depth buffer are recovered.

[0323] The recovery of the depth buffer for each block also takes into account areas within the block where sampling locations are not covered by primitives. Therefore, it is possible to indicate which portions of the block store depth data and which portions do not contain depth data. Locations within the block where no defined depth value exists can be identified as needed, for example, based on whether the per-sample depth value for said location in the block is indicated as not covered by primitives (e.g., and in implementations, represented as having a specific depth "clear" value).

[0324] Therefore, the depth value and coverage of the smallest (e.g., 2 × 2) block are first generated. Then, when considering a 4 × 4 block in the next level of the hierarchy, the minimum depth of the four 2 × 2 blocks within the 4 × 4 block becomes the minimum depth of the 4 × 4 block, and the maximum depth of the four 2 × 2 blocks becomes the maximum depth of the 4 × 4 block. Coverage data from the base 2 × 2 block is also propagated up to the 4 × 4 layer. This operation is then repeated for each subsequent higher (larger) block layer as appropriate.

[0325] Once the tile (color) buffer 8, the per-sample depth and template buffer 5, and the per-block layer depth and template buffer 11 have been recovered in this manner, the processing of primitives for the tiles can then be resumed (step 64). Again, this is done in the manner discussed above.

[0326] exist Figure 5 In the arrangement shown, it is assumed that the second processing step 60 has completed the processing of the block (i.e., processed all the elements of the block in question).

[0327] Therefore, when primitive processing is complete, the tile (color) buffer will be written to memory (step 65). It will also be determined whether the per-sample depth and template buffers should be written to memory (e.g., for further processing or later use) (step 66). If so, the contents of the per-sample depth and template buffers are also written to memory (step 67).

[0328] Finally, with the processing of the tiles completed, the layer depth and template buffer values ​​for each block are discarded (invalidated), so the per-sample depth values ​​are no longer needed (step 68).

[0329] Then, the graphics processor can start processing another tile and / or a new frame, etc., as needed.

[0330] As discussed above, Figure 5 The diagram illustrates the scenario where the second processing step (pass) 60 completes the processing of the tile. On the other hand, if the second processing step 60 is interrupted before all the primitives of the tile have been processed, the color buffer and per-sample depth buffer of the processing step are written out, and the per-block depth buffer, such as that used in the first processing step 50, is discarded. Then, the processing of the tile is resumed in another processing step corresponding to the second processing step 60, and so on, until all the primitives of the tile have been processed.

[0331] Although this embodiment has been described above with reference to writing out and then restoring the depth buffer during graphics processing, the process of constructing a per-block depth buffer from a per-sample depth buffer in this embodiment can also be used in other contexts where a per-block depth buffer is required, such as when a “pre-computed” depth buffer is provided to the graphics processor (but no corresponding “pre-computed” per-block depth buffer is provided), or when a pre-generated (pre-computed) depth buffer is provided for use by the graphics processor in an application that requires graphics processing.

[0332] As can be seen from the above, the technology described herein, at least in its embodiments, provides a mechanism for handling the interruption and resumption of processing of rendering output during the execution of early per-block depth tests. This mechanism facilitates the execution of early depth tests in those cases while reducing the storage bandwidth, memory, etc., required for this purpose. This is achieved in these embodiments of the technology described herein by at least the following steps: reconstructing the per-block depth buffer value from a previously saved per-sample depth buffer value, rather than automatically storing the per-block depth buffer value when processing of rendering output is stopped. A similar arrangement can be used to generate the per-block depth buffer from a provided, pre-computed per-sample depth buffer.

[0333] While the foregoing detailed description has been presented for purposes of illustration and description, it is not intended to be exclusive or to limit the technology described herein to the precise forms disclosed. Many modifications and variations are possible in light of the foregoing teachings. The described embodiments were chosen to best illustrate the principles of the technology described herein and its practical application, thereby enabling others skilled in the art to best utilize the technology described herein in various embodiments and with various modifications as suited to the intended particular use. The scope of protection is intended to be defined by the appended claims.

Claims

1. A method of operating a graphics processor, the graphics processor comprising: A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; as well as A renderer that processes the fragments generated by the rasterizer to generate output fragment data; When the rasterizer receives a primitive to be rasterized, it tests the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block. The graphics processor also includes: An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives; The method includes the following steps: when processing primitives to generate rendering output, the following operations are performed: A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated; The method further includes the following steps: The graphics processor stops processing the rendering output, and when the graphics processor does so, it performs the following operations: Write the per-sample depth value in the per-sample depth buffer to memory so that the per-sample depth value can be recovered when processing the rendering output continues, but discard the per-block depth value information in the per-block depth buffer. and The graphics processor resumes the processing of the rendered output; and when the graphics processor does so, it performs the following operations: The per-sample depth buffer values ​​to be written to storage are loaded into the per-sample depth buffer for use when processing the rendering output continues; and Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives while continuing the processing of the rendering output.

2. The method according to claim 1, wherein, The rasterizer is a layered rasterizer that operates to iteratively test primitives for the following blocks of the rendered output: the size of the blocks is gradually reduced until a minimum block size is reached, and the blocks of the rendered output to which the early depth test is performed correspond to the following blocks of the rendered output: the blocks that the rasterizer tests for the purpose of rasterization.

3. The method according to claim 1, wherein, The depth buffer for each block stores the minimum and maximum depth values ​​of each block: the depth value information of each block has been stored.

4. The method according to claim 3, wherein, Using the loaded per-sample depth buffer values, storing a set of per-block depth value information in a per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output includes the following steps: The minimum depth value of a block in the recovered per-block depth buffer is set to the minimum per-sample depth value of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer; and the maximum depth value of a block is set to the maximum per-sample depth value of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer.

5. The method according to claim 1, wherein, The step of loading the per-sample depth buffer value into the per-sample depth buffer for use when processing the rendered output includes: The per-sample depth value is loaded using direct memory access processing.

6. The method according to claim 1, wherein, The step of loading the per-sample depth buffer value into the per-sample depth buffer for use when processing the rendered output includes: The depth values ​​for each sample are loaded in block-by-block order.

7. The method according to claim 1, wherein, The per-block depth buffer is configured to store the depth values ​​of the hierarchical layout of the blocks; and wherein, Using the loaded per-sample depth buffer values, storing a set of per-block depth value information in a per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output includes the following steps: Using the loaded per-sample depth buffer values, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output, thereby setting the per-block depth value of the smallest block in the block subdivision hierarchy; and The block depth value of the larger block is set based on the block depth value of each smaller block contained in the larger block at the block level.

8. The method according to claim 1, wherein: The graphics processor is triggered to stop processing the rendering output because the current data structure to be processed of the rendering output is exhausted; and The graphics processor is triggered to resume processing the rendering output because a new data structure containing new data is available for the rendering output to be processed.

9. The method according to claim 1, wherein, The rendered output to be generated includes tiles of the overall output generated by the graphics processor.

10. A method of operating a graphics processor, the graphics processor comprising: A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; as well as A renderer that processes the fragments generated by the rasterizer to generate output fragment data; When the rasterizer receives a primitive to be rasterized, it tests the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block. The graphics processor also includes: An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives; The method includes the following steps: The graphics processor performs the following operations: The per-sample depth buffer value is loaded into the per-sample depth buffer for use during the processing of the rendering output. The per-sample depth buffer stores the depth values ​​at various sampling locations within one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuitry when performing primitive depth testing with respect to the sampling locations of the rendering output being generated; and Using the loaded per-sample depth buffer values, a set of per-block depth value information is stored in a per-block depth buffer for use by the early block depth test circuit when performing early block depth tests during the processing of the rendering output. The per-block depth buffer stores the depth value information of each block in one or more blocks representing a different region of the rendering output being generated, for use by the early block depth test circuit when performing early block depth tests on primitives for that block.

11. The method according to claim 10, wherein, The depth buffer for each block stores the minimum and maximum depth values ​​of each block: the depth value information of each block has been stored.

12. The method according to claim 11, wherein, Using the loaded per-sample depth buffer values, storing a set of per-block depth value information in a per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output includes the following steps: The minimum depth value of a block in the recovered per-block depth buffer is set to the minimum per-sample depth value of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer; and the maximum depth value of a block is set to the maximum per-sample depth value of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer.

13. The method according to claim 12, wherein, The step of loading the per-sample depth buffer value into the per-sample depth buffer for use when processing the rendered output includes: The per-sample depth value is loaded using direct memory access processing.

14. The method according to claim 12, wherein, The step of loading the per-sample depth buffer value into the per-sample depth buffer for use when processing the rendered output includes: The depth values ​​for each sample are loaded in block-by-block order.

15. The method according to claim 10, wherein, The per-block depth buffer is configured to store the depth values ​​of the hierarchical layout of the blocks; and wherein, Using the loaded per-sample depth buffer values, storing a set of per-block depth value information in a per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output includes the following steps: Using the loaded per-sample depth buffer values, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output, thereby setting the per-block depth value of the smallest block in the block subdivision hierarchy; and The block depth value of the larger block is set based on the block depth value of each smaller block contained in the larger block at the block level.

16. The method of claim 10, wherein: The graphics processor is triggered to stop processing the rendering output because the current data structure to be processed of the rendering output is exhausted; and The graphics processor is triggered to resume processing the rendering output because a new data structure containing new data is available for the rendering output to be processed.

17. The method according to claim 10, wherein, The rendered output to be generated includes tiles of the overall output generated by the graphics processor.

18. A graphics processor, the graphics processor comprising: A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; as well as A renderer that processes fragments generated by the rasterizer to generate output fragment data; The rasterizer is configured to, when receiving a primitive to be rasterized, test the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block. The graphics processor also includes: An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives; The graphics processor is also configured to perform the following operations when processing primitives to generate rendering output: A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated; The graphics processor is further configured to perform the following operations when it stops processing the rendering output before completing the rendering output: The per-sample depth value in the per-sample depth buffer is written to memory so that the per-sample depth value can be recovered when processing the rendering output continues, but the per-block depth value information in the per-block depth buffer is discarded; and The graphics processor is also configured to perform the following operations when it resumes processing of previously stopped rendering output: The per-sample depth buffer value of the rendered output to be written to storage is loaded into the per-sample depth buffer for use when processing the rendered output continues; and Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives while continuing the processing of the rendering output.

19. The graphics processor of claim 18, wherein, The rasterizer is a layered rasterizer that operates to iteratively test primitives for the following blocks of the rendered output: the size of the blocks is gradually reduced until a minimum block size is reached, and the blocks of the rendered output to which the early depth test is performed correspond to the following blocks of the rendered output: the blocks that the rasterizer tests for the purpose of rasterization.

20. The graphics processor of claim 18, wherein, The depth buffer for each block stores the minimum and maximum depth values ​​of each block: the depth value information of each block has been stored.

21. The graphics processor of claim 20, wherein, The graphics processor is configured to use the loaded per-sample depth buffer values ​​to store a set of per-block depth value information in a per-block depth buffer for use by the early block depth testing circuit when performing early block depth testing of primitives during the processing of the rendering output: The minimum depth value of a block in the recovered per-block depth buffer is set to the minimum per-sample depth value of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer; and the maximum depth value of a block is set to the maximum per-sample depth of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer.

22. The graphics processor of claim 18, wherein, The graphics processor is configured to load the per-sample depth buffer value into the per-sample depth buffer for use when processing the rendered output by the following steps: The per-sample depth value is loaded using direct memory access processing.

23. The graphics processor of claim 18, wherein, The graphics processor is configured to load the per-sample depth buffer values ​​into a per-sample depth buffer in a block-by-block order for use when processing the rendering output.

24. The graphics processor of claim 18, wherein: The per-block depth buffer is configured to store the depth values ​​of the hierarchical layout of the blocks; and The graphics processor is configured to use the loaded per-sample depth buffer values ​​to store a set of per-block depth value information in a per-block depth buffer for use by the early block depth testing circuit when performing early block depth testing of primitives during the processing of the rendering output: Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth test of primitives during the processing of the rendering output, thereby setting the per-block depth value of the smallest block in the block subdivision level. as well as The block depth value of the larger block is set based on the block depth value of each smaller block contained in the larger block at the block level.

25. The graphics processor of claim 18, wherein: The graphics processor is triggered to stop processing the rendering output because the current data structure to be processed of the rendering output is exhausted; and The graphics processor is triggered to resume processing the rendering output because a new data structure containing new data is available for the rendering output to be processed.

26. The graphics processor of claim 18, wherein, The rendered output to be generated includes tiles of the overall output being generated by the graphics processor.

27. A graphics processor, the graphics processor comprising: A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; as well as A renderer that processes the fragments generated by the rasterizer to generate output fragment data; The rasterizer is configured to, when receiving a primitive to be rasterized, test the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block. The graphics processor also includes: An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives; The graphics processor is also configured to perform the following operations when processing primitives to generate rendering output: A per-block depth buffer stores the rendering output, wherein each block depth buffer stores depth value information for each block in one or more blocks representing a corresponding different region of the rendering output being generated, for use by the early block depth testing circuitry when performing early block depth testing of primitives with respect to that block; and A per-sample depth buffer stores the depth values ​​of each of one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuit when performing primitive depth testing with respect to the sampling locations of the rendering output being generated; The graphics processor is also configured to perform the following operations: Load the per-sample depth buffer values ​​of the rendered output into the per-sample depth buffer for use when processing the rendered output; and Using the loaded per-sample depth buffer value, a set of per-block depth value information is stored in the per-block depth buffer for use by the early block depth test circuit when performing early block depth testing of primitives during the processing of the rendering output.

28. The graphics processor according to claim 27, wherein, The depth buffer for each block stores the minimum and maximum depth values ​​of each block: the depth value information of each block has been stored.

29. The graphics processor according to claim 28, wherein, The graphics processor is configured to use the loaded per-sample depth buffer values ​​to store a set of per-block depth value information in a per-block depth buffer for use by the early block depth testing circuit when performing early block depth testing of primitives during the processing of the rendering output: The minimum depth value of a block in the recovered per-block depth buffer is set to the minimum per-sample depth value of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer; and the maximum depth value of a block is set to the maximum per-sample depth of the sampling position falling within the block that has been loaded into the per-sample depth value of the per-sample depth buffer.

30. The graphics processor according to claim 29, wherein, The graphics processor is configured to load the per-sample depth buffer value into the per-sample depth buffer for use when processing the rendered output by the following steps: The per-sample depth value is loaded using direct memory access processing.

31. The graphics processor according to claim 27, wherein, The graphics processor is configured to load the per-sample depth buffer values ​​into a per-sample depth buffer in a block-by-block order for use when processing the rendering output.

32. The graphics processor according to claim 27, wherein: The graphics processor is triggered to stop processing the rendering output because the current data structure to be processed of the rendering output is exhausted; and The graphics processor is triggered to resume processing the rendering output because a new data structure containing new data is available for the rendering output to be processed.

33. The graphics processor according to claim 27, wherein, The rendered output to be generated includes tiles of the overall output being generated by the graphics processor.

34. A non-transitory computer-readable storage medium storing computer software code, which, when executed on a graphics processor, performs a method for operating graphics processing, the graphics processor comprising: A rasterizer that rasterizes input primitives to generate graphic fragments to be processed, each graphic fragment having one or more sampling points associated with it; as well as A renderer that processes the fragments generated by the rasterizer to generate output fragment data; When the rasterizer receives a primitive to be rasterized, it tests the block relative to the primitive for each block in one or more blocks representing different regions of the rendering output to be generated, in order to determine whether the primitive at least partially covers the block. The graphics processor also includes: An early depth testing circuit for blocks is configured to perform an early depth test of primitives with respect to the following blocks of the rendered output: where the rasterizer finds that the primitives at least partially cover the block; and A sample depth testing circuit is configured to perform a depth test on a sampling location found to be covered by primitives; The method includes the following steps: The graphics processor performs the following operations: The per-sample depth buffer value is loaded into the per-sample depth buffer for use during the processing of the rendering output. The per-sample depth buffer stores the depth values ​​at various sampling locations within one or more sampling locations of the rendering output being generated, for use by the sample depth testing circuitry when performing primitive depth testing with respect to the sampling locations of the rendering output being generated; and Using the loaded per-sample depth buffer values, a set of per-block depth value information is stored in a per-block depth buffer for use by the early block depth test circuit when performing early block depth tests during the processing of the rendering output. The per-block depth buffer stores the depth value information of each block in one or more blocks representing a different region of the rendering output being generated, for use by the early block depth test circuit when performing early block depth tests on primitives for that block.

Images