Coarse depth culling during binning

Abstract

Aspects of the present invention include a binning unit for coarse depth culling during the binning of pixel geometries. The binning unit includes a rasterizer for receiving primitives and generating pixel coverage information and depth information. The binning unit includes one or more local culling stages for performing local culling within a window of primitives. The local culling unit outputs a set of viable coverage and viable depth information. The binning unit includes one or more global culling stages that use the set of viable coverage information and viable depth information to perform further culling based on all of the previously received coverage information and depth information.

Description

Technology Field

[0001] The present invention relates to graphics processing units (GPUs), and more specifically, to a method and system for coarse depth culling during binning. Background Technology

[0002] Graphics Processing Units (GPUs) are specialized devices designed to accelerate the processing of computer-generated graphics. GPUs are also used in various modern computing environments, such as neural networks, artificial intelligence (AI), high-performance systems, autonomous vehicles, mobile devices, and gaming systems.

[0003] Hidden Surface Removal (HSR) methods refer to removing processing of surfaces that are hidden or obscured from the camera by other surfaces closer to the camera. Desktop GPUs maintain a depth buffer that enables the culling of quads (i.e., 2x2 pixel blocks), where the depth of a quad indicates that it is obscured by other already processed quads. The impact of this technique depends on the degree to which surfaces are sorted front-to-back.

[0004] Existing HSR methods primarily aim to remove hidden quads, rather than targeting the constituent vertices and primitives of the hidden faces for removal. Mobile GPUs can generate all output properties of front-end passes, typically vertex shading, and read those properties back. The available resources and energy are used to process a large portion of completely occluded primitives and their vertices that do not ultimately result in visible quads. GPUs generally have limited ability to cull quads that will eventually be obscured by subsequent quads. One common approach involves buffering quads before pixel shading to identify subsequent quads from a buffer that obscures previous quads. However, this approach is limited by practical, cost-effective buffer sizes.

[0005] Most tile-based deferred rendering (TBDR) GPUs execute the front-end stages once per primitive per image, cache the results in an intermediate buffer, and read from the intermediate buffer once per tile to execute the fragment / pixel stages. Some of these TBDR GPUs use an approach similar to that for HSTs. Tile-based GPUs include a binning stage where geometry is sorted by the tiles of pixels it affects. A single tile is a rectangular block of pixels. A binning unit (sometimes referred to as a tiler) generates a list of draws and primitives that are projected (occurred) on each tile of pixels. Primitives are geometric shapes in a coordinate system, usually triangles. Tiles are groups of pixels. The binning unit allows rendering to operate on a tile-by-tile basis by ensuring that only the primitives affecting a tile are processed. General binning uses only spatial (special) classification and does not consider visibility. In other words, primitives within a single tile that are obscured by other primitives are not excluded.

[0006] Not including visibility causes overdraw or repeated shading of specific pixels within an image. By using visibility culling, the amount of repeated shading of pixels can be reduced, and the corresponding pixel shader invocations can also be reduced. The problem to be solved

[0007] The objective of the present invention is to solve the technical problem described above, and the objective of the present invention is to provide a method and system for coarse depth curling during binning. means of solving the problem

[0008] Some embodiments include a binning unit for coarse depth culling during the binning of pixel geometries. The binning unit includes a rasterizer that receives primitives and generates pixel coverage information and depth information. The binning unit includes one or more local culling stages for performing local culling within a window of primitives. The local culling unit outputs a set of viable coverage and viable depth information. The binning unit includes one or more global culling stages that use the set of viable coverage and viable depth information to perform further culling based on all of the previously received coverage information and depth information. Effects of the invention

[0009] According to an embodiment of the present invention, a binning unit may be provided in which memory bandwidth consumed during binning is reduced, pixel shader calls are reduced, state management overhead is reduced, and overdraw rate is reduced. Accordingly, the cost and time required for image processing may be reduced and the performance of image processing may be improved. Brief explanation of the drawing

[0010] The foregoing and additional features and advantages of the principles of the present invention will become more apparent from the following detailed description generated with reference to the accompanying drawings: FIG. 1 is an exemplary diagram of a binning unit according to some embodiments. Figure 2 is an exemplary diagram illustrating a Hidden Surface Removal (HSR) technique. FIG. 3 is an exemplary diagram of {primate, tile}({prim, tile}) culling and quad culling according to some embodiments. FIG. 4 is an exemplary diagram of a depth and coverage structure stored in memory according to some embodiments. FIG. 5 is an exemplary diagram of cases for implementing depth and coverage merging using a local culling stage according to some embodiments. FIG. 6 is a diagram including a legend (600) for the various blocks shown in FIG. 5. FIG. 7 is an exemplary diagram of a depth test module according to some embodiments. FIG. 8 is an exemplary diagram of a set tester of the depth test module of FIG. 7 according to some embodiments. FIG. 9 is an exemplary diagram of a depth update logic section according to some embodiments. FIG. 10 is an exemplary block diagram of a GPU including the binning unit of FIG. 1 according to some embodiments. Specific details for implementing the invention

[0011] The embodiments disclosed below will be referenced in detail, and examples thereof are illustrated in the accompanying drawings. In the following detailed description, various specific details are described to ensure a thorough understanding of the present disclosure. However, a person skilled in the art will understand that the disclosed aspects may be practiced without such specific details. In other examples, well-known methods, procedures, components, and circuits are not described in detail so as not to obscure the invention disclosed herein.

[0012] Although terms such as first, second, etc. may be used herein to describe various elements, it should be understood that these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, the first primitive may also be referred to as the second primitive, and similarly, the second primitive may be referred to as the first primitive without departing from the scope of the invention.

[0013] The terms used in the following description of the invention are intended to describe specific embodiments and are not intended to limit the invention. As used in the description of the invention and in the appended claims, singular expressions are intended to include plural expressions as well, unless the context clearly indicates otherwise. Additionally, the term “and / or” will be understood to refer to and include all possible combinations of one or more of the elements listed below. Furthermore, the terms “comprising” and / or “comprising” as used herein will be further understood to specify the presence of the mentioned features, integers, steps, actions, elements, and / or components, but not to exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and / or groups thereof. The components and features of the drawings are not necessarily drawn to scale.

[0014] Some embodiments include an augmented binning unit capable of culling draws and primitives from per-tile lists based on visibility. The binning unit disclosed below can generate a coarse approximation of the final depth representation at the pixel (or group of pixels) level granularity. The binning unit can also minimize memory bandwidth consumed during the binning process. The binning unit can reduce work by culling primitives and draw calls from being processed in tile passes. The binning unit can improve the culling performance of existing “Early-Z” hardware by preloading the coarse depth representation, resulting in fewer pixels and / or fragments being shaded. “Initial-Z” is a form of depth processing that is shaded per pixel.

[0015] For each primitive, the binning unit disclosed herein may rasterize the primitive at the required granularity (e.g., samples or pixels). If there is only one sample per pixel, then the sample is equal to the pixel. Although it is not necessary for there to be only one sample per pixel, the terms “sample” and “pixel” are used interchangeably below. The binning unit may calculate a depth range for each primitive for each block of pixels of a predetermined size of blocks. The binning unit may use this primitive-per {coverage, depth range} information to maintain an intermediate {coverage, depth range} representation of the image, which ends in a final {coverage, depth range} representation. The binning unit may maintain the {coverage, depth range} representation in a compressed manner. The binning unit may use the intermediate {coverage, depth range} representation to culle primitives from one or more tiles.

[0016] In some embodiments, the binning unit may maintain a {coverage, depth range} representation as a hierarchy. In some embodiments, the hierarchy may be maintained in hardware circuitry. Subsequent steps in the hierarchy may use the same coverage granularity or be coarsen. Each step may maintain a {coverage, depth range} representation for one or more primitives, a window of primitives, or a subset of all primitives shown so far. Some steps may maintain this {coverage, depth range} representation only on-chip (e.g., by using hardware circuitry), whereas other steps may have on-chip caches backed by memory.

[0017] An exemplary layer may include a first step of maintaining on-chip a {coverage, depth range} representation of a window of primitives, wherein the coverage is maintained at the sample / pixel granularity, respectively, for anti-aliased / aliased rendering. A second step may maintain a {coverage, depth range} representation of all primitives shown so far, with exclusions if necessary, in memory along with an on-chip cache. The coverage may be maintained at pixels or blocks of pixels, respectively, for anti-aliased or aliased rendering. In some embodiments, a block of pixels may be a quad, for example, a block of 2x2 pixels.

[0018] The first stage of an exemplary hierarchy may cull incoming primitives based on depth from the window of current primitives. In some embodiments, the first stage may cull the entire window of current primitives based on depth from the incoming primitives. The second stage of an exemplary hierarchy may cull incoming primitives, or a window of primitives, based on previous primitives. In some embodiments, the second stage may cull all previous primitives based on depth from the incoming primitives or the window of primitives.

[0019] Disclosed in this document is a coarse depth-based hidden surface removal technique that operates in a binning pass, which can generate a compressed count stream representation indicating which primitives and draw calls affect a particular tile, and may not require including most of the primitives and draw calls that are not visible in the final rendered image. The disclosed technique can also generate an approximate compressed depth and coverage representation for an image used as a preloaded depth buffer to increase pixel culling by existing depth culling hardware required by graphics application specific interfaces (or Application Programming Interfaces; APIs). For each block of pixels, a coarse coverage mask may be generated in combination with a dictionary of depth ranges at the granularity of a single pixel or a block of pixels. In some embodiments, each covered entity (i.e., a pixel or a block of pixels) may be ensured to have depth values ​​within a specific depth range in the dictionary.

[0020] The disclosed binning unit can culle primitives in the binning pass, thereby reducing the number of primitives processed during the color pass. This technique can reduce the processing of primitives per tile by the front-end pipelines of the Graphics Processing Unit (GPU) during the color passes. This technique can also reduce the overall front-end shading cost when the binning pass is run with reduced shaders that generate only positional information for vertices and primitives. The binning unit can culle draws if all primitives within a draw are culled due to depth considerations, thereby reducing the performance impact and overhead of state management. The binning unit can use a coarse depth-coverage representation to culle pixels and pixel-quads during the color pass, thereby reducing the number of pixel shader invocations and the overall pixel processing costs.

[0021] In some embodiments, the binning unit uses a hierarchy of {coverage, depth} representations, which may be stored in hardware circuitry such as a cache. In some embodiments, the binning circuit culls subsequent primitives using the depth from the previous primitives. In some embodiments, the binning unit culls ranges of previous primitives using the depth from the subsequent primitives.

[0022] Some embodiments described herein include coarse visibility culling structures for effective 3D rendering for tile-based deferred rendering (TBDR) GPUs. At least two inefficiencies of typical TBDR GPUs are addressed: 1) unnecessary overdraw and 2) the handling of unnecessary primitives during rendering after binning or tiling. The methods and systems described herein augment a binner or tiler that determines a list of primitives and draw calls affecting a specific tile using a coarse visibility culling step to minimize the amount of overdraw.

[0023] The methods and systems described herein may include an augmented binning or tiler unit (generally referred to as the “binning unit”) that, in addition to generating a list of draws and primitives incident on each tile, culls the draws and primitives from such lists if all fragments generated by the draws / primitives are obscured by previous draws / primitives. Furthermore, the methods and systems described herein minimize overdraw by generating a coarse representation of the depth at each pixel of the image during binning and preloading that representation into a depth buffer so that Early-Z hardware can remove fragments that would be obscured by subsequent fragments.

[0024] By using the methods and systems described herein, the GPU can minimize the amount of wasted work, namely, wasted work in processing primitives in the front-end pipeline including vertices and subsequent shaders, and wasted work in processing pixel quads in the back-end pipeline including pixel shaders.

[0025] By processing post-transform primitives during the binning pass, the methods and systems described herein generate an intermediate representation of the range of visible depth in the image upon receipt of each primitive, which culminates in a final depth representation that can be preloaded during image rendering in the color pass. Additionally, some embodiments may maintain the intermediate depth representation as a compressed representation to reduce the memory footprint of the representations. Additionally, some embodiments may maintain the depth representation in multiple sets with a per-pixel or per-quad selector that selects a set of depths to ensure good depth resolution even when multiple faces are active within a single block. Additionally, some embodiments may use the intermediate depth representation to culle all primitives during the binning pass itself. Furthermore, the final depth representation may be preloaded as a depth buffer that starts during the color pass to culle individual pixels and quads. The methods and systems described herein may use alternative or complementary approaches that are not limited to identifying such quads within a limited window determined by a cost-effective buffer size. Instead, the methods and systems described herein may generate a coarse depth buffer during the binning used.

[0026] Some embodiments disclosed herein include a coarse depth-based hidden surface removal method operating in a binning pass. The binning pass can generate a compressed count stream representation indicating which primitives and draw calls affect a particular tile, and does not include most of the primitives and draw calls that are not visible in the final rendered image. The binning pass can generate an approximate compressed depth and coverage representation for the image to be used as a preloaded depth buffer to increase pixel culling by existing depth culling hardware known by graphics APIs. Some embodiments can generate a coarse coverage mask at the grain of the pixels or blocks of pixels, combined with a dictionary of depth ranges for each block of pixels. In some embodiments, each covered object (pixel or block of pixels) is guaranteed to have depth values ​​within a specific depth range in the dictionary. Some embodiments use the coarse depth-coverage representation to culle primitives in the binning pass, thereby reducing the number of primitives processed during the color pass. This, in turn, can reduce the overall front-end shading cost when the processing of primitives per tile by the front-end pipelines of color passes, and the binning pass are executed with reduced shaders that generate only location information for vertices and primitives.

[0027] When all primitives within a draw are culled due to depth considerations, some embodiments cull the draws to reduce the performance and overhead impact of state management. Some embodiments use a coarse depth-coverage representation to cull pixels and pixel-quads in the color path, thereby reducing the number of pixel shader calls and the overall pixel processing cost.

[0028] Some advantages of the binning unit disclosed herein are that it does not rely on front-to-back application sorting geometry, and that the binning circuit can successfully cull most occluded quads even when the geometry is submitted back-to-front. Another advantage is that the binning unit disclosed herein does not require a large buffer to hold quads and is not affected by the latency of holding quads that enables culling. Another advantage is reduced pixel shader calls during rendering of any image with significant depth complexity due to the culling of primitives and quads based on an approximate depth buffer. Another advantage is reduced front-end shading work and associated vertex-shading, setup, and rasterization due to the culling of primitives with completely occluded quads. Another advantage is reduced state-management overhead resulting from culling specific draws that do not affect arbitrary visible quads. Auxiliary benefits include reduced shader calls, including reduced memory bandwidth for textures, vertex properties, and associated fixed-function processing. Additionally, a reduced overdraw rate during rendering is achieved, leading to a reduction in wasted pixel shading work.

[0029] FIG. 1 is an exemplary diagram of a binning unit (100) according to some embodiments. The binning unit (100) may perform some approximate or conservative HSR during the binning pass to avoid the complexity and cost of executing additional passes to do the same thing. Consequently, the additional complexity of performing the technique is localized to the binning unit (100) itself. The binning unit (100) may obtain a stream of primitives and draw calls within an image and generate compressed count streams—one per tile per entity (wherein an entity is one primitive or one draw call)—and perform the binning operation on a GPU. Binning may be performed at a single-tile granularity or, generally, at a multi-tile granularity. The result of binning may be the generation of compressed count streams for all binning tiles within a single image. The binning unit (100) may perform two types of HSR: 1) {Prim, Tile} culling and 2) quad culling.

[0030] {Prim, Tile} culling involves removing primitives from the compressed count streams of specific tiles, which reduces work for front-end and back-end processing. The abbreviation “prim” used here refers to one or more primitives. Tiles are rectangular blocks of pixels that are rendered by the GPU as a single transaction. The compressed count streams indicate whether an entity affects the rendered results of a tile, where the entity can be a primitive, a draw call, or something else.

[0031] Quad culling can generate an approximate Z-buffer for preloading. This reduces the number of quads in pixel shader calls during the color pass. Quads are 2x2 rectangular pixel blocks, and they are rendered together to allow access to textures. The disclosed technique handles cases where quads are occluded by subsequent quads, and therefore, the disclosed technique is not dependent on front-to-back classification for occlusion.

[0032] At a high level, the binning unit (100) can coalesce coverage and depth across primitives, cull {Prim, Tile} into the resulting structure, and store the coarse depth in memory. The binning unit (100) may include a rasterizer (105) capable of generating coverage information at the sample grain size along with interpolating depth within samples within the coarse range. The rasterizer (rasterizer) (105) may include a first-stage coarse rasterizer (110) capable of receiving primitives and / or vertex data (102) and calculating coverage at the grain size of a block of pixels. This first stage may be augmented with depth interpolation logic (120) capable of calculating a range of depth at the corners of a block of pixels. The coarse rasterizer (110) can output intermediate rasterizer information (122) containing edge equations and values ​​at 2x2 tile edges or blocks, along with depth information at that grain size. The 2x2 tile edges or blocks can be reordered in place of the runs of tiles. This maximizes locality for the stream accumulator entries (hereinafter SA entries; 135) described below. The rasterizer (105) may also include a second stage fine rasterizer (115) capable of receiving the intermediate rasterizer information (122) and calculating coverage at the grain size of pixels. The coarse rasterizer (110) can calculate rasterization and depth at the grain size of blocks. A fine rasterizer (115) can calculate pixel / sample coverage when given a coarse rasterization result (or intermediate rasterizer information, 122) from a coarse rasterizer (110).The rasterizer (105) can output {prim, tile, block} information (125) such as depth and pixel coverage.

[0033] One or more local culling stages (130) of the binning unit (100) can perform coverage and depth-based culling. The local culling stage (130) can perform local culling operating within a window of primitives and draw calls using fine-grained coverage granularity without any backing state. This stage operates on a window of primitives and draw calls within a tile and uses only depth from these primitives to culle primitives within the window. This culling can use subsequent primitives to culle previous primitives, or vice versa. That is, this stage can culle looking ahead or looking behind in order. The local culling stage (130) may include a plurality of SA entries (135), one or more accumulators (140), and flush control logic (145). SA entries (135) can generate ORed coverage masks and maintain the depth-range of each block.

[0034] The binning unit (100) may operate on blocks of pixels smaller than tiles, referred to as “blocks” as used herein. A {coverage, depth range} representation may be referred to as a “node” here. A node may define pixel / quad coverage in a block along with a depth range in which pixels / quads fall within. The dimensions of the block and the size of the depth dictionary may be selected at design to minimize hardware costs. Other embodiments may choose to dynamically change the block dimensions and the size of the depth dictionary.

[0035] The local culling stage (130) can operate on a local state in the recent window of primitives and can culle past and present primitives. Thus, the local culling stage (130) can culle some or all of the past K primitives or present primitives within a block using coverage and depth information from past K primitives. The local culling stage (130) does not require any knowledge of any primitives beyond this window. The size of the window can define on-chip hardware costs and can be selected at the time of design. Other embodiments may select different sizes or dynamic sizing.

[0036] The binning unit (100) may include one or more global culling stages (or global culling logics; 150) capable of updating the output (155) of a local culling stage (130). For example, the global culling stage (150) may culle a window of primitives from a first stage local culling stage (130), and may use those primitives to culle the entire previously seen coverage using incoming coverage / depth information (i.e., output (155)) from the first stage (i.e., 130), or vice versa. The global culling stage (150) may include optional extensions to improve the culling operation. For example, the global culling stage (150) can handle special culling actions to perform inside-outside tests for specific geometries, such as cones or spheres in 3D space, by implementing context-dependent culling actions, such that a triangle that is part of a cone can be culled if all pixels covered by the triangle lie on one face of the triangle, for example, on a face following the triangle's normal. If the image preloads a depth buffer generated as the output of another image, then the global culling stage (150) can be used as a starting point for this subsequent image to improve culling performance. Accordingly, one or more custom extensions for workload-specific culling may be used, which do not necessarily have to be visibility culling or hidden face removal. Global or local culling stages may use one or more custom extensions.

[0037] The global culling logic (150) may include a depth test module (705) described below. In some embodiments, the global culling stage (150) includes optional components subsumed to the existing binning / tiling logic. For example, the global culling stage (150) may include a reordering queue (160) that prioritizes transactions for backing data to reside in on-chip memory, e.g., an on-chip buffer (165). In some embodiments, the global culling stage (150) includes binning logic (182) capable of generating a stream of covered draw calls and primitives to be consumed by subsequent stages of GPU rendering. Memory for this stream may be provided by an allocator unit (170), and the data may be written to the stream by a merge logic section (175). The merge logic section (175) may be implemented on-chip. The merge logic section (175) may receive count write requests (180) from the local culling stage (130) and update compressed count streams using memory allocated by the allocation unit (170). In some embodiments, the global culling stage (150) includes wide and narrow Network-on-Chip (NOC; 185) to communicate with the system memory cache layer and / or memory subsystem (not shown).

[0038] The on-chip buffer (165) may include prefetch queues (162), descriptor data (164), compressed count stream data or bitstream data (166), and global culling data (168), such as coarse depth information. The prefetch queues (162) may include a latency First-In-First-Out (FIFO) to ensure maximum utilization of the on-chip buffer (165). In other words, such transactions with on-chip data may be given priority over other transactions requesting data to be fetched from the memory subsystem. The on-chip buffer (165) may be combined with a Level 2 (L2) cache (190). The global culling data (168) may include a depth update logic section (905) described below.

[0039] The global curling stage (150) may use coarse and / or fine depth information and coverage information from all past primitives to curl a set of current primitives obtained from the local curling stage (130). The global curling stage (150) is capable of curling sets of past and present primitives.

[0040] FIG. 2 is an exemplary diagram (200) showing Hidden Surface Removal (HSR) technology. HSR assumes that all primitives under discussion are opaque and reduces the time and resources required to render primitives that will ultimately not be visible. Most modern GPUs include some Hidden Surface Removal technology. As shown in Phase (210), the rendering queue (202) holds primitives 0, 1, 2, and 3, and the screen (205) is initially empty. In Phase (215), primitives 0 and 1 are shown on the screen (205), and primitives 2 and 3 remain in the rendering queue (202). In Phase (220), the rendering queue (202) is empty, and primitives 2 and 3 are obscured by primitives 0 and 1 on the screen (205). In other words, primitives 2 and 3 have a greater depth than primitives 0 and 1, which have a closer depth. Accordingly, the surfaces of primitives 2 and 3 can be removed to reduce the time and resources required to render such primitives.

[0041] FIG. 3 is an exemplary diagram (300) of {prim, tile} culling and quad culling according to some embodiments. During the binning pass, subsequent primitives may be completely hidden by depth information from preceding primitives. A binning unit (e.g., 100 in FIG. 1) may collect this information in a rough manner and use this information to culle primitives from all of the tiles within the binning pass. This kind of culling means that both front-end (VS, vertex shader) and back-end processing (PS, pixel shader) can be reduced in the color pass and can be represented as the compressed count stream itself.

[0042] A secondary form of culling that can be performed by the binning unit (100) includes providing a coarse depth representation of the image to increase the effectiveness of the initial-Z culling. Accordingly, a final or near-final version of the depth buffer may be generated. The final or near-final version may be preloaded before the full color pass execution. This form of culling reduces back-end operations (PS) but still incurs a penalty of front-end (VS) execution for these primitives.

[0043] As illustrated in FIG. 3, a tile (305) may be composed of blocks of 16x16 pixels (e.g., 310). The tile (305) may have other sizes such as 32×16, 32×32, 64×32, 64×64, etc. It will be understood that other suitable tile sizes may be used. As illustrated in phase (330), primitives 0 and 1 may be processed. A binning unit (e.g., 100 in FIG. 1) may rasterize primitives 0 and 1 and accumulate coarse coverage and depth information. The depth information may be a depth within a range between a predetermined minimum and maximum value. In phase (335), the binning unit (100) may identify subsequent primitives (e.g., primitives 2 and 3) respectively for the coarse coverage and depth information. The binning unit (100) can reject primitives 2 and 3 from the tile (305). This rejection can be written to the compressed count stream. In other words, the entirety of primitives 2 and 3 can be culled. {Prim, tile} culling occurs during the binning pass as illustrated in 315, which is one of the benefits (320).

[0044] In phase (340), the binning unit (100) can write coarse coverage and depth information to memory. The binning unit (100) can preload the coarse coverage and depth information into the tile buffer (350) during the color pass. The tile buffer (350) is sometimes referred to here as the depth buffer. The tile buffer (350) can retain all color and depth (Z) information for the tiles during the color passes. Preloading the depth buffer before the start of the color pass allows the GPU to use the depth buffer for initial-Z culling to test opaque objects to see whether the opaque objects are visible in the final image. In phase (345), the initial-Z logic present in the tile buffer (350) can reject additional pixels or quads during the color pass. For example, multiple pixels or quads of primitive K can be culled by initial-Z based on the depth information. This phase is referred to as quad culling (325) during the color pass, which is one of the benefits (320). Two bolded pixels / quads (355) failed, and thus primitive K may lose some pixels, thereby reducing pixel shading work. Three dashed pixels / quads (360) were passed and will be rendered.

[0045] The binning unit (100) may operate in different modes. For example, the binning unit (100) may operate in a mode where the local culling stage (130) and the global culling stage (150) are enabled. In another mode, the local culling stage (130) and the global culling stage (150) may be disabled, but full rasterization may still be performed. In yet another mode, the local culling stage (130) and the global culling stage (150) may be enabled, and full rasterization may also be performed. The depth to be used when preloading the depth buffer into the tile buffer (350) may be determined based on a predetermined minimum depth and a predetermined maximum depth. For example, the minimum depth may be set to 0, and the maximum depth may be set to 1. According to another example, the minimum depth can be set to 0.3, and the maximum depth can be set to 0.6, and anything outside this range is invisible. According to another example, a depth range of 0.5 to 0.6 will make processing cheaper. The number of samples per pixel can also be predetermined or set.

[0046] The binning unit (100) can internally maintain coverage at pixel particle size, but can store coverage in memory at quad particle size. This can be done to reduce memory usage. Due to the coarsening of coverage to quad particle size when storing, partially covered quads may be omitted. As a result, the binning unit (100) can reduce the occurrence of partially covered quads by reordering {prim, tile} to increase the locality of coverage for the tiles.

[0047] Since each comparison incurs non-trivial energy and throughput costs, efforts are made to reduce the number of depth comparisons. Consequently, depth tests are performed on clusters of primitives rather than on individual primitives. Depth updates can also be performed implicitly at the cluster level, as efforts are made to gather all quads before testing. Significant effort is made to reduce the number of depth updates going from the on-chip buffer (e.g., 165 in FIG. 1) to memory (e.g., 190 in FIG. 1). Similar effort is made to reduce the per-tile usage of coarse depth data by the binning unit (100) to minimize the increase in memory traffic.

[0048] FIG. 4 is an exemplary diagram (400) of node depth and coverage structures stored in memory according to some embodiments. Although the binning unit (100) may internally maintain depth and coverage information in different formats, when written to memory, the information may be arranged in the format shown in FIG. 4. A node may include a pad (e.g., 4 bytes), and thus each node is 32 bytes in total. Depth information may be placed in the upper 16 bytes (with 4 bytes of padding), and coverage information may be placed in the lower 16 bytes. The nodes shown in FIG. 4 are not necessarily drawn in a stacked manner. Multiple nodes may be placed in memory consecutively, without any empty space between any two nodes.

[0049] The following pseudo-code shows a logic flow that determines different controls for the operation of the local culling stage (130) and the global culling stage (150).

[0050] If the status is activated, enable depth testing and updates in that case.

[0051] bool DepthModeEnable = (State.Mode == ENABLE_FULLRAS_ENABLE);

[0052] / / / Control variables

[0053] / / / Whether depth testing is enabled

[0054] bool depthTestEnable = DepthModeEnable;

[0055] / / / If depth testing is disabled (i.e., depthTestEnable == false), then

[0056] / / / What depth testing resolves. True: Always pass, False: Always discard

[0057] bool alwaysPass = true;

[0058] / / / Whether depth updates are enabled, i.e., whether depth can be updated

[0059] bool depthUpdateEnable = DepthModeEnable;

[0060] / / / Step 1, controlled by State.DepthTestModule

[0061] / / / Notation overload, means true if the LHS is equal to any of the values ​​inside {}.

[0062] depthTestEnable &= (State.DepthTestMode == {EARLYZ, LATEZ_WITH_EARLYZ_COMPARE});

[0063] depthUpdateEnable &= (State.DepthTestMode == EARLYZ);

[0064] / / / Auxiliary step, changing whether we always pass or not

[0065] alwaysPass = (State.DepthFunc != NEVER);

[0066] / / / Step 2, controlled by other State fields

[0067] / / / If an arbitrary State indicates that the PS(pixel shader) can modify coverage,

[0068] Although we cannot update the depth, we can still perform depth testing.

[0069] / / / Notation Note: ! represents the Boolean not operation.

[0070] depthUpdateEnable &= (!State.PSUsesDiscard && !State.PSWritesCoverage &&

[0071] !State.SampleAlphaToCoverage);

[0072] If an arbitrary State says that PS uses the Z value, then in that case, it cannot rely on the interpolated Z, and

[0073] / / / If Z writing is disabled, we cannot update

[0074] depthTestEnable &= (!State.PSWritesZ);

[0075] depthUpdateEnable &= (!State.PSWritesZ && State.DepthWriteEnable);

[0076] / / / If an arbitrary stencil test is enabled, we have coverage

[0077] Cannot guarantee equality with rasterized coverage at the ends. However, it can still be culled using depth tests.

[0078] depthUpdateEnable &= (!State.StencilTestEnable);

[0079] If blending is enabled, then we can “see through” the objects.

[0080] The DSA / local culling stage must enable depth testing if (depthTestEnable && (State.BlendEnable == 0)), and only in that case (if and only if; iff).

[0081] / / / Merge enables depth testing if iff (depthTestEnable), and only in that case (iff)

[0082] / / depthTestEnable &= (State.BlendEnable == 0);

[0083] depthUpdateEnable &= (State.BlendEnable == 0);

[0084] / / / Step 3, controlled by the dominant driver

[0085] depthTestEnable &= (!State.SkipDepthTest);

[0086] depthUpdateEnable &= (!State.SkipDepthUpdate);

[0087] / / / complete

[0088] FIG. 5 is an exemplary diagram (500) of cases in which depth and coverage merging is implemented using a local culling stage (130, FIG. 1) according to some embodiments. FIG. 6 is a diagram containing a legend (600) for the various blocks illustrated in FIG. 5. FIG. 1, 5, and 6 are now referenced.

[0089] A number of abbreviations were used in Fig. 5. For example, some existing (“EX” coverage and depth from one or more primitives within an SA entry (e.g., 135) that is affected by the incoming (“IN” coverage and depth from a single primitive. In other words, “ ” is an abbreviation for existing coverage and / or depth, and “IN” is an abbreviation for incoming coverage and / or depth. Multiple equivalent abbreviations are used to describe merge categories (505). For example, X == Y means that X and Y cover exactly the same pixels / quads. X > Y means that the coverage of X is a strict superset of the coverage of Y, i.e., X covers all pixels / quads of Y plus some additional ones. X < Y means that the coverage of Y is a strict superset of the coverage of X, i.e., Y covers all pixels / quads of X plus some additional ones. Those that do not fit into the ==, >, or < operators It includes the ALL OTHERS category, which is a catch-all merged category.

[0090] The operation of the local culling stage (130) can be guided by coverage merging rules (510). The specific coverage merging rule applied may be based on merging categories (505) and depth information (515). For example, the local culling stage (130) may apply a coverage rule (520) when IN.Cov(Coverage) == EX.Cov and the existing depth is a superset of the incoming depth. In this example, the local culling stage (130) may “keep both special depth,” which is described in detail later with the respective definitions of other possible coverage merging rules with reference to FIG. 6. According to another example, the local culling stage (130) may apply a coverage merging rule (525) when IN.Cov < EX.Cov and the existing depth is better than the incoming depth. The coverage merging rule (525) of “keep both union depth” is described in more detail later with reference to FIG. 6.

[0091] The depth information (515) covers six possible columns, each illustrated in FIG. 5: 1) incoming depth is strictly better, 2) incoming depth is better, 3) existing depth is a superset, 4) incoming depth is a superset, 5) existing depth is better, and 6) existing depth is very better. Each of the possibilities illustrated in FIG. 5 is shown in relation to a range between minimum (MIN) depth and maximum (MAX) depth.

[0092] As illustrated in FIG. 6, the legend (600) provides additional descriptions for each coverage merging rule (510) of FIG. 5. FIG. 6 also shows the relevance of these rules in relation to culling performance. To maintain accuracy, the local culling stage (130) can make merging rule selections that maximize culling performance.

[0093] Rule type (605) is generalized as “discard X maintain Y.depth” (“discard X, maintain Y.depth”), where, as shown in FIG. 5, X represents either “EX” or “IN”, and Y represents the other of “EX” or “IN”. Similarly, rule type (610) is generalized as “keep both maintain X.depth” (“keep both, maintain X.depth”), where, as shown in FIG. 5, X represents either “EX” or “IN”. Rule type (615) is “keep both special depth” (“keep both, special depth”). And rule type (620) is “keep both union depth” (“keep both, union depth”).

[0094] Rule type (605) means “keep only one of the incoming or existing primitive coverage Y and discard X; copy depth from Y”, where X and Y are defined above. Rule type (610) means “keep both incoming and existing primitive coverage; copy depth from either one of {IN, EX}”, where X and Y are defined above.

[0095] Rule type (615) means “possessing both incoming and existing primitive coverage; Special depth: minDepth = min(IN.minDepth, EX.minDepth); maxDepth = min(IN.maxDepth, EX.maxDepth)”, where X and Y are defined above; minDepth is the determined minimum depth; min() is a function that determines the minimum value; min(IN.minDepth, EX.minDepth) is a function that determines the minimum value between IN.minDepth and EX.minDepth; IN.minDepth is the minimum depth of incoming coverage; EX.minDepth is the minimum depth of existing coverage; maxDepth is the determined maximum depth; min(IN.maxDepth, EX.maxDepth) is a function that determines the minimum value between IN.maxDepth and EX.maxDepth; IN.maxDepth is the maximum depth of incoming coverage; And EX.maxDepth is the maximum depth of the existing coverage.

[0096] Rule type (620) means “holding both incoming and existing primitive coverage; union depth: minDepth = min(IN.minDepth, EX.minDepth); maxDepth = max(IN.maxDepth, EX.maxDepth)”, where X and Y are defined above; minDepth is defined above; min() is defined above; min(IN.minDepth, EX.minDepth) is defined above; IN.minDepth is defined above; EX.minDepth is defined above; maxDepth is the determined maximum depth; max(IN.maxDepth, EX.maxDepth) is a function that determines the maximum value between IN.maxDepth and EX.maxDepth; IN.maxDepth is defined above; and EX.maxDepth is defined above.

[0097] FIG. 7 is an exemplary diagram (700) of a depth test module (705) according to some embodiments. FIG. 8 is an exemplary diagram of an assembly tester (720) of the depth test module (705) of FIG. 7 according to some embodiments. FIG. 7 and FIG. 8 are now referenced.

[0098] The depth test module (705) receives an input (710) and one or more coverage sets (e.g., 718). Each of the coverage sets (e.g., 718) may be stored in an on-chip buffer (715). The depth test module (705) may include one or more set testers (e.g., 720) capable of performing two separate checks for each corresponding coverage set (e.g., 718). First, the set tester (720) may use a depth tester (e.g., 740) to determine whether the depth range of the input (710) passes the depth range of the coverage set (e.g., 718). Secondly, the set tester (720) can use a coverage tester (e.g., 745) to determine whether the input (710) has a portion that overlaps with the coverage set (e.g., 718). Each output (e.g., 725) of the set tester (e.g., 720) can be fed with an AND operation (e.g., 730), and the depth test module (705) can output a depth test pass signal (735).

[0099] Referring to FIG. 8, the set tester (720) of the set test module (705) is shown in more detail. The set tester (720) can receive an input (710) and a coverage set (718), and can perform two separate checks for each of the corresponding coverage sets (e.g., 718). First, the set tester (720) can use a depth tester (740) to determine whether the depth range of the input (710) passes through the depth range of the coverage set (718). Second, the set tester (720) can use a coverage tester (745) to determine whether the input (710) has a portion that overlaps with the coverage set (718).

[0100] In relation to the first decision, the depth tester (740) selects the correct depth for the coverage set (e.g., 718) and the input (e.g., 710). In some embodiments, the depth tester (740) may use a Look-Up Table (LUT). The table below shows exemplary operation of the set tester (740).

[0101] Depth function (805) Input MUX Output (830) Set MUX output (815) Compare (825) Less minDepth maxDepth Input < Set LessEqual minDepth maxDepth Input <= Set Greater maxDepth minDepth Input > Set GreaterEqual maxDepth minDepth Input >= Set

[0102] Accordingly, the depth function (805) receives minDepth and maxDepth from the set (718) and controls a set multiplexer (MUX; 812) that outputs an output signal (815). The set depth (820) logic section sets the depth based on the output signal (815) and passes the depth to the comparison logic section (825). The depth function (805) also receives minDepth and maxDepth from the input (710) and controls an input multiplexer (828) that outputs an output signal (830). Based on the output signal (815) and the output signal (830), the comparison logic section (825) can perform a comparison operation according to Table 1 described above. The comparison logic section (825) outputs a set depth test pass signal (SET DEPTH TEST PASS; 860).

[0103] The depth functions Never, Always, Equal, and NotEqual do not necessarily need to be written in Table 1 because the Never cases are upstream, and the rest (i.e., Always, Equal, and NotEqual) always pass through the depth tester (740).

[0104] The coverage tester (745) is an overlap test that applies an AND operation (e.g., 845) to two coverage masks (e.g., 840 and 850) to determine whether they cover the same locations. The coverage tester (745) may apply an OR operation (not shown) to see if any overlap exists in the results. The output of the AND operation (845) is checked to see if it is not equal to 0 in 855, and subsequently, the coverage tester (745) outputs coverage overlap information (COVERAGE OVERLAP; 865). For masks of different particle sizes being compared (e.g., 840 and 850), the set coverage mask (880) is at quad particle size, while the input coverage mask (885) is at pixel particle size. As a result, for the coverage tester (745), the input coverage mask (885) is coarsend from 875. For example, if any pixel within a 2x2 quad has coverage, then the quad mask bit belonging to that quad is set to 1. Thus, the coarsening logic (875) is conservative and extends the coverage to the quad granularity. This is done to prevent any false negatives during testing.

[0105] The set depth test pass information (860) output from the depth tester (740) and the coverage overlap information (865) output from the coverage tester (745) can be used to determine the test pass result in 870. The set test pass result (Set Test Pass; 870) can be determined according to the following: SetTestPass = (CoverageOverlap AND SetDepthTestPass) OR NOT (CoverageOverlap).

[0106] FIG. 9 is an exemplary diagram of a depth update logic section (905) according to some embodiments. The depth update logic section (905) receives a range of primitives within a tile (e.g., 135 in FIG. 1) which may include a depth range (910) and a coverage mask (915). The depth update logic section (905) may process a range of primitives within a tile that survived a depth test (e.g., 740 in FIG. 8). The depth update logic section (905) considers a coarse coverage when a configuration with quad granularity is selected or when pixel granularity coverage is present. In contrast to the depth test, the coarseness of the depth update is performed by a bitwise AND of the pixel coverage, i.e., only when the entire quad is covered. Consequently, partially covered quads may be lost during the depth update. This loss of information increases hardware simplicity. The depth update logic section (905) receives a range of primitives within a tile, including a depth range (910) and a coverage mask (915) at a quad or pixel granularity based on a selected configuration. Here, coverage is generally assumed to be for quads, but it will be understood that the same technique can be applied to pixel coverage.

[0107] The depth update logic section (905) performs two update stages. The first stage overlaps the coverage between the range of primitives within the tile and the existing sets, and for each quad, determines whether the range or set of primitives within the tile should keep the quad for the best culling action. The second stage operates to reduce the number of sets to the allowed maximum, adding the remaining coverage as a new set if any exists. If a depth test (e.g., 740 in FIG. 8) is performed, the second stage of the depth update logic section (905) is guaranteed to exist with some coverage.

[0108] The following pseudocode covers the operation of the first stage of the depth update logic section (905). The following pseudocode relates to each node, that is, a block of pixels such as 8x8 or 16x16. The following pseudocode includes definitions outside the normal cases of other depth functions, such as cases where the coarse depth is not updated, such as EQUAL or NOT EQUAL.

[0109] / / / Defines which depth is “better” for more curling

[0110] / / / Uses two copies of the node depth - one from the start of the process, and

[0111] The other one is the current version. The former is used for comparisons and updating sets, while on the other hand

[0112] The latter is used as the current representation of the node's depth.

[0113] bool has_better_coverage (uint16 &nodeMinDepth, uint16 &nodeMaxDepth, pair<uint16, uint16> &setDepth, const uint16 initialNodeMinDepth, const uint16 initialNodeMaxDepth, DepthFunc f) {

[0114] bool entry_better = false;

[0115] switch (f) {

[0116] case LESS: / / < LESS implies the < or “less than” operation

[0117] case LEQUAL: / / < LEQUAL implies the <= or “less than or equal to”

[0118] / / / Prioritize the depth of the new primitive for sameness

[0119] entry_better = initialNodeMaxDepth <= setDepth.second;

[0120] If the entry is better, the set's minDepth should be taken as coverage, otherwise the opposite (vice versa).

[0121] if (entry_better) nodeMinDepth = min(nodeMinDepth, setDepth.first);

[0122] else setDepth.first = min(initialNodeMinDepth, setDepth.first);

[0123] break;

[0124] case GREATER: / / < GREATER implies the > or “greater than” operation

[0125] case GEQUAL: / / < GEQUAL implies the >= or “greater than or equal to” operation

[0126] / / / Prioritize the depth of the new primitive (prim) for sameness

[0127] entry_better = initialNodeMinDepth >= setDepth.first;

[0128] If the entry is better, the set's maxDepth should be taken as coverage, otherwise the opposite (vice versa).

[0129] if (entry_better) nodeMaxDepth = max(nodeMaxDepth, setDepth.second);

[0130] else setDepth.second = max(initialNodeMaxDepth, setDepth.second);

[0131] break;

[0132] };

[0133] return false;

[0134] }

[0135] / / / Function representing the Stage 1 depth update

[0136] void depth_update_stage1 (SAEntry &in, Node &curr, DepthFunc f) {

[0137] uint16 initialNodeMinDepth = in.minDepth;

[0138] uint16 initialNodeMaxDepth = in.maxDepth;

[0139] / / / Iterate through the coverage of SA entries -

[0140] / / / Assume it has already been downsampled if necessary

[0141] for (i = 0; i < NumCoverageBits; ++i) {

[0142] / / / Mandatory check only when covered, otherwise do nothing

[0143] if (in.covMask[i] == 1) {

[0144] / / / Check if an arbitrary set of the current (curr) node has coverage, i.e., if id != 0 is set.

[0145] if (curr.coverage[i] != 0) {

[0146] / / / Check if the set has “better” coverage or SAEntry

[0147] / / / Using the initial depths, the final result is

[0148] You must ensure that it does not depend on the sets, or the traversing order based on i.

[0149] bool entry_better = has_better_coverage (in.minDepth, in.maxDepth, curr.depth[curr.coverage[i]], initialNodeMinDepth,

[0150] initialNodeMaxDepth, f);

[0151] if (entry_better) {

[0152] Stealing cover from a set

[0153] / / / No changes are needed; we will modify curr.coverage[i] in Stage 2

[0154] } else {

[0155] / / / Remove coverage from SAEntry

[0156] in.covMask[i] = 0;

[0157] }

[0158] }

[0159] }

[0160] }

[0161] }

[0162] The first stage of the depth update logic section (905) ensures that the range of primitives within the tile only has coverage for the quads / pixels that are the better choice. One function of the second stage is to ensure that this new depth and coverage pair can be inserted into the coverage sets while maintaining a certain maximum number of sets presented by the configuration. The following pseudocode relates to the second stage of the depth update logic section (905) involving inserting the range of primitives within the tile into the node.

[0163] void insert_saentry(SAEntry &in, Node &curr, uint index) {

[0164] curr.depth[index] = make_pair(in.minDepth, in.maxDepth);

[0165] for (i = 0; i < NumCoverageBits; ++i) {

[0166] / / / Check only if covered, otherwise do nothing

[0167] if (in.covMask[i] == 1) curr.coverage[i] = index;

[0168] }

[0169] }

[0170] / / / Return the two candidates with the closest “better” depth

[0171] pair<uint, uint> find_candidates (Node &curr, SAEntry &in, DepthFunc f) {

[0172] int cand1 = 0, cand2 = 0;

[0173] uint16 mindiff = (1 << 16) - 1;

[0174] for (int i = 0; i < NumSets; ++i) for (int j = i+1; j <= NumSets; ++i) {

[0175] switch (f) {

[0176] case LESS:

[0177] case LEQUAL:

[0178] When DepthFunc is less (LESS) or similar, the nearest maximum depth is

[0179] / / / Have the best candidate

[0180] uint16 depth2 = (j == NumSets) ? in.maxDepth : curr.depth[j].second;

[0181] uint16 pair_diff = abs(curr.depth[i].second - depth2);

[0182] if (pair_diff < mindiff) { cand1 = i; cand2 = j;}

[0183] case GREATER:

[0184] case GEQUAL:

[0185] When DepthFunc is greater (GREATER) or similar, the nearest minimum depth is

[0186] / / / Have the best candidate

[0187] uint16 depth2 = (j == NumSets) ? in.minDepth : curr.depth[j].first;

[0188] uint16 pair_diff = abs(curr.depth[i].first - depth2);

[0189] if (pair_diff < mindiff) { cand1 = i; cand2 = j;}

[0190] };

[0191] }

[0192] return make_pair (cand1, cand2)

[0193] }

[0194] / / / Stage 2 depth update. Takes the (in, curr) pairs resulting from the Stage 1 update.

[0195] void depth_update_stage2 (SAEntry &in, Node &curr, DepthFunc f) {

[0196] if (curr.numActiveSets < NumSets) {

[0197] This assumes that all sets are packed into 0… (numActiveSets-1).

[0198] RTL can be selected to alleviate this limitation, and “holes”

[0199] / / / That is, empty sets that are not at the end of the set index range, the next empty

[0200] As long as there exists a method to find the set, it can have

[0201] insert_saentry(in, curr, numActiveSets++);

[0202] } else {

[0203] Find two sets to collapse, or one set to merge, and SAEntry

[0204] The function takes two indices representing two sets,

[0205] / / / Returns an SA entry with val == NumSets indicating that it is a candidate

[0206] pair<uint, uint> candidates = find_candidates (curr, in, f);

[0207] if (candidates.second == NumSets) {

[0208] / / / Merge the candidate with SAEntry

[0209] / / / Takes min of the minimum depths and max of the maximum depths

[0210] curr.depth[candidates.first].first = min(curr.depth[candidates.first].first, in.minDepth);

[0211] curr.depth[candidates.first].second = max(curr.depth[candidates.first].second, in.maxDepth);

[0212] / / / Mark the coverage for the first candidate set

[0213] for (i = 0; i < NumCoverageBits; ++i) {

[0214] if (in.covMask[i] == 1) curr.coverage[i] = candidates.first;

[0215] }

[0216] } else {

[0217] / / / Merge the two candidate sets

[0218] / / / Takes min of the minimum depths and max of the maximum depths

[0219] curr.depth[candidates.first].first = min(curr.depth[candidates.first].first, curr.depth[candidates.second].first);

[0220] curr.depth[candidates.first].second = max(curr.depth[candidates.first].second, curr.depth[candidates.second].second);

[0221] / / / Move coverage from candidate 2 to candidate 1

[0222] for (i = 0; i < NumCoverageBits; ++i) {

[0223] if (curr.coverage[i] == candidates.second) curr.coverage[i] = candidates.first;

[0224] }

[0225] / / / Merge complete, insert SAEntry into candidates.second

[0226] insert_saentry(in, curr, candidates.second);

[0227] }

[0228] }

[0229] }

[0230] The guiding principle after the second stage of merging sets of depth update logic section (950) is that when coarse-mold available information, for example, by merging information with similar “better” depths, loss is minimized. For a specific depth function, the best depth values ​​can be kept while maintaining coverage. Some information is lost, but hardware simplicity is improved.

[0231] Regarding the pseudocode for the second stage, for the LESS or LEQUAL depth functions, the logic attempts to minimize the maximum depth of the coverage sets over time for all covered pixels. This is done to maximize culling as the depth test logic tests the minimum depth of a new primitive against the maximum depth of the set. Conversely, for GREATER and GEQUAL, the logic attempts to maximize the minimum depth of the coverage sets over time for all covered pixels. This technique can operate crudely if the depth function changes its sign within the image, i.e., from {LESS, LEQUAL} within the image Switching to {GREATER, GEQUAL} can degrade data quality. Although expressed differently, this is the same logic as the merging of SA entry coverage. Fully covered blocks / nodes can be handled implicitly within the logic.

[0232] Optional performance enhancements include set merging code in the second stage that selects where to move the merged set and which set to free for use by the SA entry. For example, if the merged set always uses the lower index, then there is a possibility that Set 1 will continue to grow larger (e.g., in terms of coverage) and have a more diluted depth range. Consequently, a subsequent priority order is preferred, but any cyclical ordering is also suffice. If Sets 1 and 2 are merged, then write the merged set to Set 1. If Sets 1 and 3 are merged, then write the merged set to Set 3. If Sets 2 and 3 are merged, then write the merged set to Set 2. The incoming SA entry will correspondingly go to the other resulting freed set index or any other free set slot.

[0233] FIG. 10 is an exemplary block diagram of a GPU (1005) including a binning unit (100) according to some embodiments disclosed herein. The binning unit (100) may correspond to the binning unit of FIG. 1. The binning unit (100) may be electrically connected to one or more processor cores (1010). The GPU (1005) may also include a memory device (1015) which may be a random access memory (RAM), flash memory (1015), a solid state drive (SSD), etc.

[0234] Various operations of the methods described above may be performed by any suitable means, such as various hardware and / or software component(s), circuits, and / or modules, capable of performing the operations.

[0235] Blocks or steps of methods or algorithms and functions related to the embodiments disclosed herein may be directly implemented in hardware, software modules executed by a processor, or a combination of both. If implemented in software, the functions may be stored as one or more instructions or code on a tangible, non-transitory computer-readable medium, or transmitted therethrough. The software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0236] The following discussion is intended to provide a brief and general description of a suitable machine or machines in which specific aspects of the present invention may be implemented. Typically, the machine or machines include processors, memories, e.g., RAM, ROM, or other state-preserving media, storage devices, video interfaces, and a system bus for attaching input / output interface ports. The machine or machines may be controlled, at least partially, by input from conventional input devices such as keyboards, microphones, etc., as well as by directives received from other machines, interaction with a Virtual Reality (VR) environment, biometric feedback, or other input signals. As used herein, the term “machine” is intended to broadly include a single machine, a virtual machine, or machines, virtual machines, or devices operating together that are telecommunicationally coupled. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, portable devices, telephones, tablets, etc., as well as transportation devices such as personal or public transportation, e.g., automobiles, trains, cabs, etc.

[0237] Machines or machines may include embedded controllers such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits (ASICs), embedded computers, smart cards, etc. Machines or machines may utilize one or more connections to one or more remote machines through network interfaces, modems, or other communication couplings. Machines may be interconnected in physical and / or logical network modes such as intranets, the Internet, local area networks, and wide area networks. A person skilled in the art will understand that network communication may utilize various wired and / or wireless short- or long-range carriers and protocols, including radio frequency (RF), satellite, microwave, IEEE (Institute of Electrical and Electronics Engineers) 545.11, Bluetooth, optical, infrared, cable, laser, etc.

[0238] Embodiments of the present invention may refer to or be described in relation to related data, including functions, processes, data structures, application programs, etc., which enable the machine to perform tasks or define abstract data types or low-level hardware contexts when accessed by a machine. The related data may be stored, for example, in volatile and / or non-volatile memory, e.g., RAM, ROM, etc., or other storage devices and associated storage media, including hard drives, floppy disks, optical storage devices, tapes, flash memory, memory sticks, digital video discs, biological storage devices, etc. The related data may be transmitted through transmission environments, including physical and / or logical networks, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used as compressed or encrypted packets. The related data may be used in a distributed environment and may be stored locally and / or remotely for machine access.

[0239] Although the principles of the present invention have been described and illustrated with reference to the illustrated embodiments, it will be understood that the illustrated embodiments may be modified in arrangement and specific parts and may be combined in any desired manner without departing from such principles. Furthermore, although the foregoing discussion has focused on specific embodiments, other configurations are also considered. In particular, even though expressions such as “according to one embodiment of the present invention” are used herein, these phrases generally refer to the possibilities of embodiments and are not intended to limit the present invention to the configurations of specific embodiments. As used herein, these terms may refer to identical or different embodiments that can be combined with other embodiments.

[0240] Embodiments of the present invention may include non-volatile machine-readable media comprising instructions for performing the elements of the invention described herein, which are executable by one or more processors.

[0241] The exemplary embodiments described above should not be understood as limiting the concept of the invention. Although some embodiments have been described, those skilled in the art will readily understand that many modifications are possible to the embodiments without substantially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the invention as defined in the claims. Explanation of the symbols

[0243] 100: Binning Unit 105: Rasterizer 130: Local Curling Stage 150: Global Curling Stage 510: Coverage Merge Rules 600: Legend 705: Depth Test Module 905: Depth Update Logic Section 1005: GPU

Claims

Claim 1 A binning unit for performing coarse depth culling during the binning of pixel geometries, comprising: a rasterizer that receives one or more primitives, generates intermediate rasterizer information by calculating coverage at a block grain size, and generates pixel coverage information and depth information at a pixel grain size finer than the block grain size based on the intermediate rasterizer information; one or more local culling stages connected to the rasterizer, performing local culling within a window of primitives, and outputting a set of surviving coverage and surviving depth information; and a) one or more global culling stages connected to at least one of the one or more local culling stages or b) the rasterizer, and using the set of surviving coverage and surviving depth information to perform further culling based on all of the previously received pixel coverage information and depth information. Claim 2 In claim 1, the one or more local culling stages are binning units that use only depth information associated with the window of the primitives when performing the local culling of the one or more primitives within the window of the primitives. Claim 3 In claim 1, the one or more global culling stages further culle a set of survival coverage and survival depth information received from the one or more local culling stages using coverage information and at least one of a) coarse depth information or b) fine depth information from all past primitives. Claim 4 In claim 1, the rasterizer, the one or more local culling stages, and the one or more global culling stages minimize overdraw by generating a coarse representation of each pixel of the image during binning, and the binning unit preloads the coarse representation into a depth buffer before a full color pass so that Early-Z hardware removes fragments of the image that are occuluded by later fragments of the image. Claim 5 In claim 1: the one or more local culling stages perform the local culling within a window of the primitives in the tile, and the rasterizer, the one or more local culling stages, and the one or more global culling stages generate a binning unit that generates a representation indicating which primitives and drawcalls affect the tile. Claim 6 In claim 5, the above expression is a binning unit that does not include primitives and draw calls not visible in the last rendered image. Claim 7 In claim 1, the binning unit further comprises an on-chip buffer, wherein the one or more global culling stages include a reordering queue that prioritizes transactions for which backing data resides in the on-chip buffer. Claim 8 In claim 7, the one or more global curling stages are binning units that reorder the transactions based on memory residency in the on-chip buffer of the backing data. Claim 9 In claim 1, the one or more global culling stages comprise: binning logic that generates a stream of covered draw calls and primitives consumed by subsequent rendering stages of a graphics processing unit (GPU); and a binning unit comprising one or more custom extensions for workload-specific culling. Claim 10 In claim 1: the one or more local culling stages culle based on depth information of incoming primitives within the window of primitives, and the one or more global culling stages culle based on depth information of prior primitives within the window of primitives, a binning unit. Claim 11 In claim 1, the one or more global culling stages or the one or more local culling stages are a binning unit that culls all of the previously received coverage information and depth information using a window of the primitives. Claim 12 In claim 1, the one or more global culling stages or the one or more local culling stages are a binning unit that culls a window of the primitives using all of the previously received coverage information and depth information. Claim 13 A binning unit according to claim 1, further comprising one or more user extensions for workload-specific culling. Claim 14 In claim 13, one or more user extensions for workload-specific culling are binning units not based on visibility culling. Claim 15 In claim 14, the one or more local culling stages are binning units using the one or more user extensions. Claim 16 In claim 14, the one or more global curling stages are binning units using the one or more user extensions. Claim 17 A method for selecting coverage merging rules associated with depth culling during binning of pixel geometries, comprising: receiving one or more primitives; generating intermediate rasterizer information by calculating coverage at a block grain size based on the one or more primitives; generating incoming coverage information and depth information at a pixel grain size finer than the block grain size based on the intermediate rasterizer information; analyzing the depth information; classifying the depth information into a plurality of categories including 1) incoming depth is strictly good, 2) incoming depth is good, 3) existing depth is a superset, 4) incoming depth is a superset, 5) existing depth is good, and 6) existing depth is very good; and comparing the incoming coverage information with existing coverage information. A method comprising a step of selecting the coverage merging rule based on the step of classifying and the step of comparing, wherein the step of comparing includes a step of determining at least one of 1) whether the incoming coverage information is identical to the existing coverage information, 2) whether the incoming coverage is a strict superset of the existing coverage, or 3) whether the existing coverage is a strict superset of the incoming coverage. Claim 18 In claim 17: the comparing step further comprises the step of determining 1) that the incoming coverage information is not identical to the existing coverage information, 2) that the incoming coverage is not a strict superset of the existing coverage, and 3) that the existing coverage is not a strict superset of the incoming coverage, and the step of selecting the coverage merging rule further comprises the step of determining. Claim 19 In claim 17, the step of selecting the coverage merging rule further includes the step of selecting the first coverage merging rule from among a plurality of coverage merging rules. Claim 20 In claim 19, the step of selecting the coverage merging rule further includes the step of selecting a second coverage merging rule among the plurality of coverage merging rules.

Images