Fine-grained replay control in binning hardware

Abstract

Some embodiments provide systems, devices, and methods for rendering a plurality of primitives of a frame, where the plurality of primitives are divided into a plurality of batches of primitives and the frame is divided into a plurality of bins, and rendering at least one of the plurality of batches includes, for each of the plurality of bins, rendering a first sub-batch of primitives that rasterize into that bin, and for each of the plurality of bins, rendering a second sub-batch of primitives that rasterize into that bin.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 042,399, filed June 22, 2020, entitled "FINE GRAINED REPLAY CONTROL IN BINNING HARDWARE," and U.S. Patent Application No. 17 / 033,023, filed September 25, 2020, entitled "FINE GRAINED REPLAY CONTROL IN BINNING HARDWARE," the contents of which are incorporated herein by reference. [Background technology]

[0002] In computer graphics, objects are usually represented as groups of polygons, which in this context are usually called primitives. These polygons are typically triangles, each represented by three vertices. While other types of polygon primitives may be used, triangles are the most common example. Each vertex contains information that defines its location in three-dimensional (3D) space, and in some embodiments, other information such as color, normal vectors, and / or texture information.

[0003] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of an example device in which one or more features of the present disclosure may be implemented. [Figure 2] FIG. 2 is a block diagram of the device of FIG. 1 showing additional details. [Figure 3] FIG. 1 is a block diagram illustrating a graphics processing pipeline, according to an example. [Figure 4] FIG. 2 is a block diagram of an exemplary frame divided into bins. [Figure 5] FIG. 1 is a block diagram illustrating an example Z pre-pass (ZPP) operation with example batch breaks at Z function change boundaries. [Figure 6] FIG. 1 is a block diagram illustrating an example light-shaft optimization (LSO) with an example batch break at drawcall boundaries. [Figure 7] FIG. 10 is a block diagram illustrating an example ZPP operation with an example sub-batch break at a Z-function change boundary. [Figure 8] FIG. 10 is a block diagram illustrating an example LSO operation with an example sub-batch break at a draw call boundary. [Figure 9] 1 is a flowchart illustrating an example primitive batched binning (PBB). [Figure 10] 10 is a flowchart illustrating an example PBB with sub-batching. DETAILED DESCRIPTION OF THE INVENTION

[0005] In some embodiments, it is advantageous to render an entire frame in subsets, which may be called bins or tiles. For example, in some embodiments, the frame is divided into bins in the xy plane, and only primitives covered by pixels in the first bin are rendered before moving to the next bin. This approach is conveniently called binning. In some cases, this has the advantage of increasing cache locality and data reuse during rendering, and reducing the eviction rate of rendering data from the cache.

[0006] Some embodiments provide a processor configured to render a plurality of primitives of a frame. The processor includes circuitry configured to render the plurality of primitives of the frame. The plurality of primitives are divided into a plurality of batches of primitives. The frame is divided into a plurality of bins. Rendering at least one of the plurality of batches includes, for each of the plurality of bins, rendering a first sub-batch of primitives that rasterize into that bin, and, for each of the plurality of bins, rendering a second sub-batch of primitives that rasterize into that bin.

[0007] In some embodiments, the processor includes circuitry configured to cache primitives of at least one of the multiple batches before rendering the primitives of the first sub-batch and the second sub-batch. In some embodiments, the processor includes circuitry configured to evict primitives of a different one of the multiple batches before caching the primitives of the at least one of the multiple batches. In some embodiments, rendering the primitives of the first sub-batch includes dispatching primitives to a rendering pipeline in a first pass for a bin of the multiple bins and dispatching the primitives of the first sub-batch to a rendering pipeline in a second pass for the same bin of the multiple bins before moving to a next bin.

[0008] In some embodiments, the first pass includes rasterization and the second pass includes rendering. In some embodiments, the first pass includes a Z-test and the second pass includes rendering. In some embodiments, the second pass includes rendering based on results of the Z-test. In some embodiments, the processor includes circuitry configured to cache primitives of at least one batch of the multiple batches before rendering the primitives of the first sub-batch. In some embodiments, the first sub-batch includes primitives of an object and the second sub-batch includes primitives of a different object that are not present in the first sub-batch. In some embodiments, the first sub-batch includes primitives having a Z-function that is different from the Z-function in the second sub-batch.

[0009] Some embodiments provide a method for rendering a plurality of primitives of a frame, the method including rendering a plurality of primitives of the frame, the plurality of primitives being divided into a plurality of batches of primitives, and the frame being divided into a plurality of bins, wherein rendering at least one of the plurality of batches includes, for each of the plurality of bins, rendering a first sub-batch of primitives that rasterize into that bin, and, for each of the plurality of bins, rendering a second sub-batch of primitives that rasterize into that bin.

[0010] In some embodiments, the method includes caching primitives of at least one of the multiple batches before rendering the primitives of the first sub-batch and the second sub-batch. In some embodiments, the method includes evicting primitives of a different one of the multiple batches before caching the primitives of the at least one of the multiple batches. In some embodiments, rendering the primitives of the first sub-batch includes dispatching primitives to a rendering pipeline in a first pass for a bin of the multiple bins and dispatching the primitives of the first sub-batch to a rendering pipeline in a second pass for the same bin of the multiple bins before moving to a next bin.

[0011] In some embodiments, the first pass includes rasterization and the second pass includes rendering. In some embodiments, the first pass includes a Z-test and the second pass includes rendering. In some embodiments, the second pass includes rendering based on the results of the Z-test. In some embodiments, the method includes caching primitives of at least one batch of the multiple batches before rendering the primitives of the first sub-batch. In some embodiments, the first sub-batch includes primitives of an object and the second sub-batch includes primitives of a different object that are not present in the first sub-batch. In some embodiments, the first sub-batch includes primitives having a different Z-function than the second sub-batch.

[0012] 1 is a block diagram of an example device 100 capable of implementing one or more features of the present disclosure. Device 100 may include, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, or a tablet computer. Device 100 includes a processor 102, a memory 104, a storage device 106, one or more input devices 108, and one or more output devices 110. Device 100 may also optionally include an input driver 112 and an output driver 114. It should be understood that device 100 may include additional components not shown in FIG. 1 .

[0013] In various alternatives, processor 102 may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU located on the same die, or one or more processor cores, each of which may be a CPU or a GPU. In various alternatives, memory 104 may be located on the same die as processor 102 or may be located separately from processor 102. Memory 104 may include volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache).

[0014] Storage devices 106 include fixed or removable storage devices (e.g., hard disk drives, solid state drives, optical disks, flash drives). Input devices 108 include, but are not limited to, a keyboard, keypad, touch screen, touchpad, detector, microphone, accelerometer, gyroscope, biometric scanner, or network connection (e.g., wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals). Output devices 110 include, but are not limited to, a display, speaker, printer, haptic feedback device, one or more optics, antennas, or network connection (e.g., wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals).

[0015] The input driver 112 communicates with the processor 102 and the input device 108, allowing the processor 102 to receive input from the input device 108. The output driver 114 communicates with the processor 102 and the output device 110, allowing the processor 102 to send output to the output device 110. Note that the input driver 112 and the output driver 114 are optional components, and that the device 100 may operate in the same manner without the input driver 112 and the output driver 114. The output driver 114 includes an accelerated processing device ("APD") 116 coupled to a display device 118. The APD accepts computational and graphics rendering commands from the processor 102, processes those computational and graphics rendering commands, and provides pixel output to the display device 118 for display. As described in further detail below, the APD 116 includes one or more parallel processing units that perform computations according to the single-instruction-multiple-data ("SIMD") paradigm. Thus, although various functions are described herein as being performed by or in conjunction with APD 116, in various alternatives, the functions described as being performed by APD 116 may additionally or alternatively be performed by other computing devices having similar capabilities that are not driven by a host processor (e.g., processor 102) and provide graphical output to display device 118. For example, it is contemplated that any processing system that performs processing tasks according to the SIMD paradigm may perform the functions described herein. Alternatively, it is contemplated that computing systems that do not perform processing tasks according to the SIMD paradigm may perform the functions described herein.

[0016] FIG. 2 is a block diagram of device 100 showing additional details regarding the execution of processing tasks on APD 116. Processor 102 maintains, within system memory 104, one or more control logic modules for execution by processor 102. The control logic modules include operating system 120, kernel-mode driver 122, and applications 126. These control logic modules control various aspects of the operation of processor 102 and APD 116. For example, operating system 120 communicates directly with hardware and provides an interface to the hardware for other software executing on processor 102. Kernel-mode driver 122 controls the operation of APD 116, for example, by providing an application programming interface (API) to software executing on processor 102 (e.g., applications 126) to access various features of APD 116. Kernel-mode driver 122 also includes a just-in-time compiler that compiles programs for execution by processing components of APD 116 (such as SIMD unit 138, described in more detail below).

[0017] APD 116 executes commands and programs for selected functions, such as graphics and non-graphics operations that may be suitable for parallel processing. APD 116 may be used to perform graphics pipeline operations, such as pixel operations, geometric calculations, and rendering of images to display device 118, based on commands received from processor 102. APD 116 also performs computational operations not directly related to graphics operations, such as operations related to video, physics simulations, computational fluid dynamics, or other tasks, based on commands received from processor 102.

[0018] The APD 116 includes a computation unit 132 that includes one or more SIMD units 138 that, at the request of the processor 102, perform operations in a parallel manner according to the SIMD paradigm. The SIMD paradigm allows multiple processing elements to share a single program control flow unit and program counter, thus executing the same program but with different data. In one example, each SIMD unit 138 includes 16 lanes, each of which executes the same instruction simultaneously with other lanes in the SIMD unit 138 but can execute the instruction with different data. Lanes can be predictively switched off if not all lanes need to execute a given instruction. Prediction can also be used to execute programs with branching control flow. More specifically, for programs with conditional branches or other instructions where control flow is based on calculations performed by individual lanes, prediction of lanes corresponding to currently unexecuted control flow paths and serial execution of different control flow paths allows for arbitrary control flow.

[0019] The basic unit of execution within the compute unit 132 is the work item. Each work item represents a single instantiation of a program executing in parallel on a particular lane. Work items can execute simultaneously as a “wavefront” on a single SIMD unit 138. One or more wavefronts are included in a “workgroup,” which contains a collection of work items designated to execute the same program. A workgroup can be executed by executing each of the wavefronts that make up the workgroup. Alternatively, a wavefront executes serially on a single SIMD unit 138, or partially or fully in parallel on different SIMD units 138. A wavefront can be thought of as the largest collection of work items that can execute simultaneously on a single SIMD unit 138. Thus, if a command received from the processor 102 indicates that a particular program is parallelized to an extent that it cannot be executed simultaneously on a single SIMD unit 138, the program is divided into wavefronts that are either parallelized on two or more SIMD units 138, or serialized on the same SIMD unit 138 (or both parallelized and serialized, as appropriate). The scheduler 136 performs operations related to scheduling the various wavefronts on the different compute units 132 and SIMD units 138 .

[0020] The parallel processing provided by the compute units 132 is well suited to graphics-related operations such as pixel value calculations, vertex transformations, and other graphics operations. Thus, in some cases, the graphics processing pipeline 134, which accepts graphics processing commands from the processor 102, provides computational tasks to the compute units 132 for execution in parallel.

[0021] Computation unit 132 is also used to perform computational tasks that are not related to graphics or that are not performed as part of the "normal" operation of graphics processing pipeline 134 (e.g., custom operations performed to supplement the operations performed on graphics processing pipeline 134). Applications 126 or other software executing on processor 102 send programs defining such computational tasks to APD 116 for execution.

[0022] Figure 3 is a block diagram illustrating additional details of the graphics processing pipeline 134 shown in Figure 2. The graphics processing pipeline 134 includes stages, each of which performs a specific function. The stages represent subdivisions of the functionality of the graphics processing pipeline 134. Each stage may be implemented partially or fully as a shader program executing within the programmable processing unit 202, or partially or fully as fixed-function, non-programmable hardware external to the programmable processing unit 202.

[0023] The input assembler stage 302 reads primitive data from a user-filled buffer (e.g., a buffer filled with requests from software executed by the processor 102, such as application 126) and assembles the data into primitives for use by the rest of the pipeline. The input assembler stage 302 can generate different types of primitives based on the primitive data contained in the user-filled buffer. The input assembler stage 302 formats the assembled primitives for use by the rest of the pipeline.

[0024] The vertex shader stage 304 processes the vertices of the primitives assembled by the input assembler stage 302. The vertex shader stage 304 performs various per-vertex operations, such as transformation, skinning, morphing, and lighting for each vertex. Transformation operations include various operations for transforming the coordinates of vertices. These operations include one or more of modeling transformations, viewing transformations, projection transformations, perspective division, and viewport transformations. As used herein, such transformations are considered to modify the coordinates or "position" of the vertices on which the transformation occurs. Other operations of the vertex shader stage 304 modify attributes other than coordinates.

[0025] The vertex shader stage 304 is implemented partially or completely as a vertex shader program that runs on one or more compute units 132. The vertex shader program is provided by the processor 102 and is based on a program pre-written by a computer programmer. The driver 122 compiles such a computer program to generate a vertex shader program having a form suitable for execution within the compute units 132.

[0026] The hull shader stage 306, tessellator stage 308, and domain shader stage 310 work together to implement tessellation, which converts simple primitives into more complex primitives by subdividing the primitives. The hull shader stage 306 generates patches for tessellation based on the input primitives. The tessellator stage 308 generates a set of samples for the patch. The domain shader stage 310 calculates vertex positions for vertices corresponding to the samples in the patch. The hull shader stage 306 and domain shader stage 310 may be implemented as shader programs executing on the programmable processing unit 202.

[0027] The geometry shader stage 312 performs vertex operations on a primitive basis. A variety of different types of operations can be performed by the geometry shader stage 312, including operations such as point sprint expansion, dynamic particle system operations, fur-fin generation, shadow volume generation, single pass render-to-cubemap, per-primitive material swapping, and per-primitive material setup. In some cases, a shader program executing on the programmable processing unit 202 performs the operations of the geometry shader stage 312.

[0028] The rasterizer stage 314 accepts and rasterizes simple primitives generated upstream. Rasterization involves determining which screen pixels (or sub-pixel samples) are covered by a particular primitive. Rasterization is performed by fixed-function hardware.

[0029] The pixel shader stage 316 calculates the output values ​​of the screen pixels based on the primitives generated upstream and the results of rasterization. The pixel shader stage 316 can apply textures from texture memory. The operations of the pixel shader stage 316 are performed by shader programs running on the programmable processing unit 202.

[0030] The output merge stage 318 accepts the outputs from the pixel shader stage 316, merges them, and performs operations such as z-testing and alpha blending to determine the final color of the screen pixel.

[0031] Texture data defining textures is stored and / or accessed by texture unit 320. Textures are bitmap images that are used at various points within graphics processing pipeline 134. For example, in some cases, pixel shader stage 316 applies textures to pixels to improve the apparent rendering complexity (e.g., to provide a more "photorealistic" look) without increasing the number of vertices rendered.

[0032] In some cases, the vertex shader stage 304 uses texture data from the texture unit 320 to modify primitives to increase complexity, for example, by generating or modifying vertices for improved aesthetics. In one example, the vertex shader stage 304 uses a height map stored in the texture unit 320 to modify the displacement of vertices. This type of technique can be used to generate more realistic-looking water, for example, by changing the position and number of vertices used to render the water, compared to textures used only by the pixel shader stage 316. In some cases, the geometry shader stage 312 accesses texture data from the texture unit 320.

[0033] In general, performance of various computing operations, particularly on GPUs, can sometimes be improved by caching frequently used data in high-speed, dedicated memory. In some cases, the attribute information (e.g., x, y, z coordinates, color, texture, etc.) of all primitives being rendered for a frame exceeds the size of the cache or local memory used to store the information being processed. Therefore, in some embodiments, it is advantageous to render the entire frame in subsets, as described above. Such subsets of a frame are commonly referred to as bins or tiles. For example, in some embodiments, a frame is divided into bins in the x-y plane, and only primitives "covered by" pixels in the first bin (i.e., 3D primitives project or rasterize into 2D bins so that they overlap the bin in 2D space) are rendered before moving to the next bin. This approach is conveniently referred to as binning. In some cases, binning has the advantage of increasing cache locality and data reuse during rendering, reducing the rate of eviction of rendering data from the cache.

[0034] 4 is a block diagram of an example frame 400 divided into bins. Frame 400 is divided into 25 bins in this example, although any suitable number of bins is possible. For convenience, only three of the bins are labeled 402, 404, and 406. Using a binning approach, only those primitives of frame 400 that are covered by pixels that fall within bin 402 are rendered first. Exemplary primitive 408 is shown, which is covered by bin 402. After those primitives that rasterize to pixels that fall within bin 402 are rendered, primitives that rasterize to pixels that fall within bin 404 are rendered, as are primitives that rasterize to pixels that fall within bin 406, and then other bins in the same manner until primitives that rasterize to pixels that fall within each of the bins of frame 400 have been rendered.

[0035] In some embodiments, improved cache locality and data reuse are achieved. In this approach, a subset of primitives, called a batch, is rendered for each of the bins, one bin at a time. For each bin, each batch primitive is first rasterized to determine whether it is covered by the bin's pixels, and then those batch primitives determined to be covered by the bin's pixels are dispatched for rendering. In some embodiments, this determination is made using a rasterization algorithm, which in some embodiments is part of the PBB. After a batch is rendered one bin at a time for each bin, the next batch of primitives is rendered one bin at a time for each bin in the same manner until all batches have been rasterized and rendered for all bins.

[0036] Dedicated hardware, referred to herein as PBB hardware, is used to "replay" batches of primitives for each bin. In other words, the PBB hardware stores the primitives in batches and dispatches the primitives in the batch to the rendering pipeline once for each bin until the entire frame is rendered.

[0037] The PBB hardware is configured to batch primitives (i.e., store subsets of primitives) and "replay" them (i.e., dispatch stored batches of primitives for rendering) in a different order (e.g., screen position order for binning). In some embodiments, the replay functionality of the PBB hardware can also be used for other techniques, such as Z-Prepass (ZPP) and Light Shaft Optimization (LSO). While ZPP and LSO are convenient examples for illustrating alternative uses of the PBB replay functionality herein, it should be noted that in other embodiments, any suitable technique can utilize the PBB replay functionality.

[0038] ZPP is a processing technique for reducing computational load by rasterizing overlapping triangles (e.g., overlapping pixels in a batch or bin) once without performing color calculations to determine the triangles' "Z" or depth order (i.e., which triangle is closest to the viewer or which triangle is furthest, according to a Z function). This Z or depth information is recorded in a Z-buffer for each sample. This rasterization is called the Z pre-pass. After the sample closest to the viewer is determined in the Z pre-pass, the triangles, along with the Z information, are "replayed" to the rendering pipeline for color calculations in a second pass using the PBB hardware's replay function. Based on the Z information, color calculations are performed only for the samples in the front (i.e., closest to the viewer). In some embodiments, this has the advantage of improving performance by reducing the processing load. LSO uses the PBB hardware's replay function in a similar manner for light shaft optimization.

[0039] The PBB replay mechanism operates at the batch level. In other words, a first pass operates on a batch (i.e., a defined subset of primitives) before "replaying" (i.e., dispatching to the rendering pipeline) that same batch (i.e., the same subset of primitives). However, for ZPP operations, the Z calculations for all primitives in the first pass must be for the same Z-function. This is because the Z-function determines the Z-function semantics of each primitive relative to other primitives (i.e., representing which triangle is closest to the front in a "larger" or GT mode of operation, or which triangle is closest to the back in a "smaller" or LT mode of operation). Therefore, if the execution reaches a point where the Z-function changes, the primitives following the Z-function change are processed in a separate batch to facilitate correct operation. For LSO operations, the algorithm requires that all primitives in a light shaft geometry (e.g., a sphere) be completely contained within the batch; for best efficiency, there should be only one object in each batch. In some embodiments, this requires that the batch breaks at draw call boundaries, where each draw call renders one object: a draw call is a request sent from the CPU to the GPU asking the GPU to draw an object.

[0040] 5 is a block diagram of an example ZPP operation 500 illustrating an example batch break in Z-function changes (also called Z-state changes). The operation 500 includes processing a first batch 502 followed by processing a second batch 504.

[0041] The primitives in batch 502 are batched separately from the primitives in batch 504 because the primitives in batch 502 are associated with a different Z-function than the Z-function associated with the primitives in batch 504. In this example, the primitives in batch 502 are associated with a "greater than" Z-function (GT), and the primitives in batch 504 are associated with a "smaller" Z-function. The primitives in batch 502 are batched separately from the primitives in batch 504 due to the change in Z-function, even if the primitives could otherwise be batched together (e.g., the maximum batch size could accommodate all primitives in one batch).

[0042] For each bin in a frame, batch 502 is processed in two passes. In the first pass, primitives in batch 502 are sent to the rendering pipeline to rasterize them and determine their depth order without color calculations. This first pass is called the Z-prepass. The depth information is recorded in the Z-buffer. After the Z-prepass determines the samples closest to the view, the primitives in batch 502 are sent to the rendering pipeline in the second pass for color calculations, along with Z information from the Z-buffer, using the replay function of the PBB hardware. Based on the Z information, color calculations are performed only on samples in the front of the bin (i.e., closest to the viewer).

[0043] After the first and second passes are performed on batch 502 of the first bin of the frame, the first and second passes are performed on batch 502 of the next bin, and so on, until batch 502 has been rendered for each bin. After batch 502 has been rendered for each bin of the frame, batch 504 is processed in the same manner as batch 502, with two passes for each bin of the frame.

[0044] 6 is a block diagram of an example LSO operation 600 illustrating an example batch break at a draw call boundary. The operation 600 includes processing a first batch 602, followed by processing a second batch 604, followed by processing a third batch 606.

[0045] The primitives in batch 602, batch 604, and batch 606 are batched separately because the LSO algorithm requires that all primitives in a light shaft geometry (e.g., a sphere) be completely contained within a batch, and in some embodiments, it is more efficient to have only one object in each batch. If multiple objects exist in a single batch, they may interfere with each other, resulting in inaccurate results. Therefore, batches break at draw call boundaries because each draw call renders one object. The primitives in batch 602, batch 604, and batch 606 are batched separately due to draw call boundaries, even if they could otherwise be batched together (e.g., the maximum batch size could accommodate all primitives in one batch).

[0046] Batch 602 is processed in two passes, for each bin of the frame. In the first pass, the rendering pipeline rasterizes and performs Z-tests on the primitives in that bin's batch, and the Z-test results are recorded. In the second pass, if any of the fragments from the first pass pass the Z-test, the rendering pipeline rasterizes and performs Z-tests on the back-facing triangles to determine a representative fragment to represent the portion of the scene that falls within the light shaft. After the first and second passes are performed on batch 602 in the first bin of the frame, the first and second passes are performed on batch 602 in the next bin, and so on, until LSO has been performed on batch 602 in each bin. After LSO has been performed on batch 602 in each bin of the frame, batch 604 is processed in two passes for each bin of the frame in the same manner as batch 602. Similarly, after LSO is performed on batch 604 for each bin of the frame, batch 606 is processed in the same manner as batch 604, with two passes for each bin of the frame.

[0047] In some embodiments, Z-functions or draw call boundaries result in extra batch breaks beyond those used for PBB, substantially reducing the size of the batch. In some embodiments, a substantial reduction in batch size can adversely affect the cache eviction improvements and / or bandwidth reductions provided by PBB. Also, reducing a batch size below that used for PBB for any other purpose can have similar adverse effects.

[0048] Accordingly, some PBB hardware embodiments are configured to operate on sub-batches within a primitive batch. By facilitating second-level replay, this approach has the advantage of supporting ZPP, LSO, and / or other features that leverage the replay capabilities of the PBB hardware, while also preserving the cache eviction improvement and / or bandwidth benefits of the PBB. In some embodiments, by performing binned operations on sub-batches of a batch while maintaining cached attribute information for all primitives in the batch, adverse effects on cache eviction improvement and / or bandwidth reduction caused by the PBB that may be caused by reducing the size of the batch are avoided or limited.

[0049] Figure 7 is a block diagram of an example ZPP operation 700 illustrating an example sub-batch break at a Z-function change boundary. In the example of Figure 7, attribute information for all primitives in a first batch 702 is maintained in a cache while the PBB hardware dispatches the primitives of a first sub-batch 704 in two passes (one pass to determine GT-mode Z-functions for the primitives of sub-batch 704 and one pass to render the primitives of sub-batch 704 based on the determined Z-functions), and then dispatches the primitives of sub-batch 706 in two passes (one pass to determine LT-mode Z-functions for the primitives of sub-batch 706 and one pass to render the primitives of sub-batch 706 based on the determined Z-functions). After the ZPP is performed by the PBB hardware for each of sub-batches 704 and 706 in the current bin, the PBB hardware switches to the next bin and performs the ZPP again for sub-batches 704 and 706.

[0050] Figure 8 is a block diagram of an example LSO operation 800 illustrating example sub-batch breaks at draw call boundaries. In the example of Figure 8, attribute information for all primitives in a first batch 802 is maintained in a cache (e.g., a color cache and / or a texture cache) while the PBB hardware dispatches primitives of a first sub-batch 804 to the rendering pipeline for two passes of the LSO, then dispatches primitives of sub-batch 806 to the rendering pipeline for two passes of the LSO, then dispatches primitives of sub-batch 808 to the rendering pipeline for two passes of the LSO.

[0051] After the LSO is performed by the PBB hardware for each of sub-batch 804, sub-batch 806, and sub-batch 808 of the current bin, the PBB hardware switches to the next bin and performs the LSO again for sub-batch 804, sub-batch 806, and sub-batch 808.

[0052] As described herein, Table 1 contains pseudocode representing PBB replay at the batch level (for convenience, referred to as "typical PBB replay"), and Table 2 contains pseudocode representing PBB replay at the sub-batch level (for convenience, referred to as "sub-batch PBB replay").

[0053] [Table 1]

[0054] [Table 2]

[0055] In a typical PBB replay, on a batch-by-bin basis, the primitives of the current batch are sent to the graphics pipeline (e.g., for rasterization to determine which batch primitives are covered by the bin), and then the primitives of the current batch are resent to the graphics pipeline (e.g., for rendering of the batch primitives determined to be covered by the bin).

[0056] In PBB replay by sub-batch, on a batch-by-bin-by-sub-batch basis, the primitives of the current sub-batch are sent to the graphics pipeline (e.g., to determine the Z-order of the primitives), and then the primitives of the current batch are re-sent to the graphics pipeline (e.g., to render the batch primitives determined to be closest to the viewer in the Z direction).

[0057] 9 is a flowchart illustrating an example process 900 for PBB. In some embodiments, process 900, or portions thereof, can be used for ZPP or LSO operations, for example, as described herein, or for other operations. In some embodiments, process 900 is implemented using any suitable hardware, such as PBB hardware described further herein.

[0058] In step 902, primitives of a frame are input to a graphics processor. In step 904, the primitives of the frame are divided into multiple (P) batches. In step 906, the frame is divided into multiple (Q) bins. Note that steps 902, 904, and 906 can be performed in any suitable manner and / or with different processes. In step 908, the current batch is set to the first batch of the P batches, and the current bin is set to the first bin of the Q bins. This notation is merely for convenience; the batches and bins can be tracked using counters or in any suitable manner, with or without the exemplary initialization step 908.

[0059] In step 910, the current batch of primitives are buffered and dispatched to the graphics pipeline for a first pass for the current bin. For example, in some ZPP processes, the first pass is a Z-prepass, e.g., as described herein. After the first pass, in step 912, the current batch of primitives are dispatched to the graphics pipeline for a second pass (replayed) for the current bin. For example, in some ZPP processes, the second pass renders the colors of the primitives closest to the viewer based on the depth information determined in the first pass.

[0060] If the current bin is not the last batch of Q bins 914, then the current bin proceeds to the next step in step 916, and the primitives of the current batch are buffered and dispatched to the graphics pipeline for pass 1 for the current bin in step 910. If the current bin is the last batch of Q bins 914, and the current batch is the last bin of P batches 918, then the process 900 ends. Otherwise, if the current batch is not the last batch of R bins 918, then the current batch proceeds to the next batch in step 920, the current bin is reset to the first bin, and the primitives of the new current batch are buffered and dispatched to the graphics pipeline for pass 1 for the current bin in step 910.

[0061] 10 is a flowchart illustrating an example process 1000 for PBB replay using sub-batches. In some embodiments, process 1000, or portions thereof, can be used for ZPP or LSO operations, for example, as described herein, or for other operations. In some embodiments, this process 1000 is implemented using any suitable hardware, such as PBB hardware described further herein.

[0062] In step 1002, a frame of primitives is input to a graphics processor, the frame of primitives is divided into multiple (P) batches, each of the multiple (P) batches is divided into multiple (R) sub-batches, and the frame is divided into multiple (Q) bins. Note that in some embodiments, each of the batches P may be divided into a different number of sub-batches, each of which may be divided into sub-batches of different sizes (i.e., number of primitives), and / or some batches may not be divided into sub-batches.

[0063] It should be noted that step 1002 may be performed in any suitable manner and / or different processes, and may be performed in multiple individual steps (e.g., as in process 900 as shown and described with respect to FIG. 9) or a combination of those steps.

[0064] In step 1004, the current batch is set to the first batch of P batches, the primitives of the first batch of P batches are buffered, the current sub-batch is set to the first sub-batch of R sub-batches, and the current bin is set to the first bin of Q bins. This notation is merely for convenience, and the batches, sub-batches, and bins are tracked using counters, with or without the exemplary initialization step 1004, or in some embodiments, in any suitable manner.

[0065] In step 1006, the primitives of the current sub-batch are dispatched to the graphics pipeline for a first pass for the current bin. For example, in some ZPP processes, the first pass is a Z-prepass, e.g., as described herein. After the first pass, in step 1008, the primitives of the current sub-batch are dispatched to the graphics pipeline for a second pass (replayed) for the current bin. For example, in some ZPP processes, the second pass renders the colors of the primitives closest to the viewer based on the depth information determined in the first pass.

[0066] If the current bin is not the last bin of Q bins 1010, the current bin advances to the next bin in step 1012 and the primitives of the current sub-batch are dispatched to the graphics pipeline for pass 1 for the new current bin in step 1006. If the current bin is the last bin of Q bins 1010, it is determined whether the current sub-batch is the last sub-batch of R sub-batches.

[0067] If the current sub-batch is not the last of the R sub-batches 1014, then in step 1016 the current sub-batch advances to the next sub-batch of the R sub-batches of the current batch, and the primitives of that sub-batch are dispatched to the graphics pipeline for pass 1 for the current bin in step 1006. If the current sub-batch is the last of the R sub-batches 1014, then it is determined whether the current batch is the last of the P batches.

[0068] If the current bin is the last bin of Q bins, then the process 1000 ends on condition 1018. Otherwise, if the current batch is not the last bin of P batches, then the current batch advances to the next batch of P batches, the current sub-batch is reset to the first sub-batch of the next batch, the current bin is reset to the first bin of Q bins in step 1020, and the primitives of the first sub-batch of the new current batch are dispatched to the graphics pipeline for pass 1 for the first bin in step 1006.

[0069] It should be understood that many variations are possible based on the disclosure herein, and although features and elements are described above in particular combinations, each feature or element can be used alone without other features and elements, or in various combinations with or without other features and elements.

[0070] The various functional units illustrated in the figures and / or described herein (including, but not limited to, processor 102, input driver 112, input device 108, output driver 114, output device 110, acceleration processing device 116, scheduler 136, graphics processing pipeline 134, computation unit 132, SIMD unit 138) may be implemented as a general-purpose computer, processor, or processor core, or as a program, software, or firmware stored on a non-transitory computer-readable storage medium or another storage medium executable by the general-purpose computer, processor, or processor core. The provided methods may be implemented in a general-purpose computer, processor, or processor core. Suitable processors include, by way of example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine. Such processors may be fabricated by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data such as a netlist (such instructions may be stored on a computer-readable storage medium). The result of such processing may be a mask work that is used in subsequent semiconductor manufacturing processes to produce a processor implementing features of the present disclosure.

[0071] The methods or flow diagrams provided herein may be implemented in a computer program, software, or firmware embodied in a non-transitory computer-readable storage medium for execution by a general-purpose computer or processor. Examples of non-transitory computer-readable storage media include read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROM disks and digital versatile disks (DVDs)).

Claims

1. 1. A processor configured to render a plurality of primitives of a frame, comprising: The processor: a circuit configured to render a plurality of primitives of the frame, the plurality of primitives being divided into a plurality of batches of primitives and the frame being divided into a plurality of bins; Rendering at least one batch of the plurality of batches includes: For each of the plurality of bins, rendering in a first pass a first sub-batch of primitives that rasterize into that bin; and in a second pass, rendering a second sub-batch of primitives that rasterize into the bins. Processor.

2. and a circuit configured to cache the primitives of the at least one batch of the plurality of batches before rendering the primitives of the first sub-batch and the second sub-batch. The processor of claim 1 .

3. and circuitry configured to evict primitives of a different one of the plurality of batches before caching the primitives of the at least one batch of the plurality of batches. The processor of claim 2.

4. rendering the first sub-batch of primitives includes dispatching the primitives to a rendering pipeline in a first pass for a bin of the plurality of bins, and dispatching the first sub-batch of primitives to the rendering pipeline in a second pass for the bin of the plurality of bins before moving to a next bin; The processor of claim 1 .

5. The first pass includes rasterization and the second pass includes rendering. The processor of claim 4.

6. The first pass includes a Z test and the second pass includes a rendering. The processor of claim 4.

7. and a circuit configured to cache the primitives of the at least one batch of the plurality of batches before rendering the primitives of the first sub-batch. The processor of claim 1 .

8. the first sub-batch includes primitives of an object, and the second sub-batch includes primitives of a different object not present in the first sub-batch; The processor of claim 1 .

9. 1. A method of rendering a plurality of primitives in a frame, comprising: The method comprises: Rendering a plurality of primitives of the frame, the plurality of primitives being divided into a plurality of batches of primitives and the frame being divided into a plurality of bins; Rendering at least one batch of the plurality of batches includes: For each of the plurality of bins, rendering in a first pass a first sub-batch of primitives that rasterize into that bin; and in a second pass, rendering a second sub-batch of primitives that rasterize into the bins. method.

10. caching the primitives of the at least one batch of the plurality of batches before rendering the primitives of the first sub-batch and the second sub-batch.

10. The method of claim 9.

11. and further comprising evicting primitives of a different one of the plurality of batches before caching the primitives of the at least one batch of the plurality of batches. The method of claim 10.

12. rendering the first sub-batch of primitives includes dispatching the primitives to a rendering pipeline in a first pass for a bin of the plurality of bins, and dispatching the first sub-batch of primitives to the rendering pipeline in a second pass for the bin of the plurality of bins before moving to a next bin; 10. The method of claim 9.

13. the first pass includes rasterization and / or Z-test, and the second pass includes rendering based on the results of the Z-test; 13. The method of claim 12.

14. caching the primitives of the at least one batch of the plurality of batches before rendering the primitives of the first sub-batch.

10. The method of claim 9.

15. the first sub-batch includes primitives of an object, and the second sub-batch includes primitives of a different object not present in the first sub-batch; 10. The method of claim 9.

Images