Hybrid Binning

Abstract

A processing device and method for tiled rendering of an image for display are provided. The processing device includes a memory and a processor. The processor is configured to receive an image including one or more three-dimensional (3D) objects, divide the image into tiles, perform coarse-level tiling on the tiles of the image, and perform fine-level tiling on the tiles of the image. The processing device also includes the same fixed-function hardware used to perform the coarse-level tiling and the fine-level tiling. The processor is configured to determine visibility information for a first tile. The visibility information is divided into draw-call visibility information and triangle visibility information for each remaining tile of the image.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 963,414, entitled "HYBRID BINNING," filed January 20, 2020, and U.S. Patent Application No. 17 / 033,259, entitled "HYBRID BINNING," filed September 25, 2020, the contents of which are incorporated herein by reference. [Background technology]

[0002] Graphics processing involves rendering a three-dimensional (3D) scene onto a two-dimensional (2D) screen. The 3D scene is rendered onto the display screen through a graphics pipeline that includes various processing stages. Graphics processing commands in a command stream are received (e.g., from an application) and computational tasks are provided (e.g., to an accelerated processing device such as a GPU) to perform the tasks.

[0003] Graphics are rendered on the display screen using primitives (such as triangles, quadrilaterals, and other geometric shapes). Graphics processing commands include, for example, the number of primitives, the location of each primitive, and the attributes of each primitive to be rendered on the display screen.

[0004] 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]

[0005] [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 showing further details of FIG. 1. [Figure 3] FIG. 1 is a block diagram illustrating a graphics processing pipeline, according to an example. [Figure 4] FIG. 1 is a flow diagram illustrating an exemplary method for rendering an image for display according to the features of the present disclosure. [Figure 5] FIG. 1 is a schematic diagram illustrating an example of rendering an image for display according to the functionality of the present disclosure. [Figure 6] FIG. 1 is a flow diagram illustrating an example method for rendering a first tile of an image for display according to the features of the present disclosure. [Figure 7] FIG. 10 is a flow diagram illustrating an example method for rendering a next tile of an image for display in accordance with features of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0006] A graphics pipeline can be simplified to include a front-end geometry portion and a back-end portion. For example, the front-end geometry portion of the pipeline includes several shader stages (e.g., vertex shader stage, hull shader stage, tessellator stage, domain shader stage, and geometry shader stage). During the shader stages, primitives are received as 3D objects, converted to 2D objects, and rendered to a 2D screen. The back-end portion includes a rasterizer stage and a pixel shader stage. During the rasterizer stage, the screen location of each primitive as it is projected onto the 2D screen is determined. For example, during rasterization, an accelerated processing device (such as a GPU) determines, for each primitive, which pixel (or subpixel sample) corresponds to each primitive that is rendered to the 2D screen. During the pixel shader stage, values ​​(such as brightness and color) are calculated for the pixels corresponding to the primitive.

[0007] Data is processed more efficiently (e.g., by a GPU) by reusing previously processed data that is stored locally (e.g., data stored in a GPU cache) rather than using remote memory (e.g., main memory) to process the data. Tiling (or binning) is a technique for reducing the amount of local memory (e.g., cache) and bandwidth used to render a frame compared to rendering the entire frame at once. Tiling divides a frame into sections (e.g., tiles or bins) and renders one tile of the frame before rendering another tile of the frame. For example, if a frame (or image) is divided into four equal tiles (i.e., upper-left quadrant, upper-right quadrant, lower-left quadrant, and lower-right quadrant), the first tile (e.g., the upper-left quadrant) is rendered before rendering one of the next tiles. Then, one of the other tiles (e.g., the upper-right quadrant) is rendered before proceeding to rendering either of the last two tiles, and so on until every tile of the frame has been rendered.

[0008] Conventional tiling techniques include coarse-level tiling (i.e., larger tiles and fewer tiles or bins per frame) and fine-level tiling (i.e., small tiles and a larger number of tiles or bins per frame). Due to the fewer tiles per frame, coarse-level tiling has less tiling (binning) overhead than fine-level tiling, but an overall lower cache hit rate than fine-level tiling. Fine-level tiling has a higher cache hit rate than the fewer tiles of the coarse-level tiling, but a higher tiling overhead than fine-level tiling.

[0009] This application discloses an apparatus and method that uses both coarse and fine level tiling in a unique and efficient manner to provide efficient tile rendering. The application performs coarse level tiling for a coarse tile and fine level tiling for a fine tile of the coarse tile before proceeding to the next coarse tile and performing coarse and fine level tiling. The application performs coarse and fine level tiling using the same fixed function hardware, providing the benefits of coarse and fine level tiling without the additional hardware cost.

[0010] This application provides a method for tiled rendering of an image for display, the method including receiving an image including one or more three-dimensional (3D) objects, dividing the image into tiles, performing coarse-level tiling on the tiles of the image, and performing fine-level tiling on the tiles of the image.

[0011] The present application provides a processing device for tiled rendering of an image for display, the processing device including a memory and a processor, the processor configured to receive an image including one or more three-dimensional (3D) objects, divide the image into tiles, perform coarse-level tiling on the tiles of the image, and perform fine-level tiling on the tiles of the image.

[0012] The present application provides a non-transitory computer-readable storage medium including instructions for causing a computer to perform a method for tiled rendering of an image for display, the method including receiving an image including one or more three-dimensional (3D) objects, dividing the image into tiles, performing coarse-level tiling on the tiles of the image, and performing fine-level tiling on the tiles of the image.

[0013] 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, memory 104, storage 106, one or more input devices 108, and one or more output devices 110. Device 100 may also include optional input drivers 112 and output drivers 114. It should be understood that device 100 may include additional components not shown in FIG. 1 .

[0014] 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).

[0015] Storage 106 includes fixed or removable storage (e.g., hard disk drive, solid state drive, optical disk, flash drive). 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 lights, antenna, or network connection (e.g., wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals).

[0016] 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 the device 100 operates similarly without the input driver 112 and the output driver 114. The output driver 116 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 the 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 for performing computations according to the single instruction, multiple data (SIMD) paradigm. Thus, although various functions are described herein as being performed by or in combination with APD 116, in various alternatives, the functions described as being performed by APD 116 are not driven by a host processor (e.g., processor 102), but are additionally or alternatively performed by other computing devices having similar functionality for providing 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 perform the functions described herein.

[0017] FIG. 2 is a block diagram of device 100, illustrating additional details related to the execution of processing tasks in APD 116. Processor 102 maintains one or more control logic modules in system memory 104 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).

[0018] 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 performs graphics pipeline operations, such as pixel operations, geometric computations, and can be used to render images on 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 simulation, computational fluid dynamics, or other tasks, based on commands received from processor 102.

[0019] The APD 116 includes compute units 132, which include one or more SIMD units 138 that perform operations in parallel according to the SIMD paradigm at the request of the processor 102. The SIMD paradigm is a paradigm in which multiple processing elements share a single program control flow unit and program counter, thereby 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 that instruction with different data. Prediction can turn off lanes when not all lanes need to execute a given instruction. Prediction can also be used to execute programs with branching control flows. 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 sequential execution of different control flow paths enables arbitrary control flow.

[0020] The basic unit of execution in 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 may execute simultaneously on a single SIMD unit 138 as a “wavefront.” One or more wavefronts are included in a “workgroup,” which contains a collection of work items designated to execute the same program. A workgroup may be executed by executing each of the wavefronts that make up the workgroup. Alternatively, a wavefront may execute partially or wholly on a single SIMD unit 138 or on various SIMD units 138. A wavefront may 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 split into wavefronts that are either parallelized on two or more SIMD units 138 or serialized on the same SIMD unit 138 (or both parallel and serialized, as appropriate). The scheduler 136 performs operations related to scheduling various wavefronts on different compute units 132 and SIMD units 138.

[0021] The parallelism provided by 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, graphics processing pipeline 134, which accepts graphics processing commands from processor 102, provides computational tasks to compute units 132 for parallel execution.

[0022] Compute 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 processing performed for the operation of graphics processing pipeline 134). Applications 126 or other software executing on processor 102 send programs that define such computational tasks to APD 116 for execution.

[0023] The APD 116 is configured to implement the features of the present disclosure by performing multiple functions, as described in more detail below. For example, the APD 116 is configured to receive an image including one or more three-dimensional (3D) objects, divide the image into tiles, perform a visibility pass on the primitives of the image, divide the image into tiles, perform coarse-level tiling on the tiles of the image, divide the tiles into fine tiles, and perform fine-level tiling of the image. Optionally, front-end geometry processing of a primitive determined to be the first one of the tile may be performed concurrently with the visibility pass.

[0024] 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 functionality. The stages represent a subdivision of the functionality of the graphics processing pipeline 134. Each stage may be implemented partially or fully as a shader program running on the programmable processing unit 202, or partially or fully as fixed-function, non-programmable hardware external to the programmable processing unit 202.

[0025] Stages 302-313 represent the front-end geometry processing portion of graphics processing pipeline 134. Stages 314-318 represent the back-end pixel processing portion of graphics processing pipeline 134.

[0026] The input assembler stage 302 reads primitive data from a user-filled buffer (e.g., a buffer filled at the request of 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.

[0027] 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 per-vertex lighting. Transformation operations include various operations for transforming the coordinates of vertices. These operations include one or more of the following: modeling transformation, display transformation, projection transformation, perspective division, and viewport transformation. As used herein, such transformations are considered to modify the coordinates or "position" of the vertex on which the transformation is performed. Other operations in the vertex shader stage 304 modify attributes other than coordinates.

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

[0029] The hull shader stage 306, tessellator stage 308, and domain shader stage 310 work together to perform tessellation, which converts simple primitives into more complex primitives by subdividing the primitives. The hull shader stage 306 generates patches for tessellation based on 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.

[0030] The geometry shader stage 312 performs vertex operations on a per-primitive basis. A variety of different types of operations can be performed by the geometry shader stage 312, including operations such as point splint expansion, dynamic particle system operations, farfin generation, shadow volume generation, single-pass rendering to cubemaps, 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.

[0031] The Binner (Tiler) stage 313 is the final stage of front-end processing. The Binner stage performs coarse rasterization to determine whether tiles (or bins) of a frame (or image) overlap with primitives. For example, the Binner stage includes visibility checks (i.e., a visibility pass) and tile walking for primitives determined to be in each tile. The Binner stage 313 is performed by fixed-function hardware.

[0032] As mentioned above, stages 314-318 represent the back-end processing of graphics processing pipeline 134. Rasterizer stage 314 accepts and rasterizes simple primitives and those generated upstream. Rasterization involves determining which screen pixels (or sub-pixel samples) are covered by a particular primitive. For example, rasterizer stage 314 converts primitives (e.g., triangles) to screen space pixels and tests which pixels are covered by the primitive. Rasterization is performed by fixed-function hardware.

[0033] The pixel shader stage 316 calculates the output values ​​of 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 operation of the pixel shader stage 316 is performed by a shader program executing on the programmable processing unit 202.

[0034] 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.

[0035] Texture data defining textures is stored and / or accessed by texture unit 320. Textures are bitmap images used at various points in 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" appearance) without increasing the number of vertices rendered.

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

[0037] Figure 4 is a flow diagram illustrating an exemplary method of rendering an image for display according to the features of the present disclosure. Figure 5 is used to explain the method of Figure 4 and is a schematic diagram illustrating an example of rendering an image 500 for display according to the features of the present disclosure.

[0038] As indicated by block 402, method 400 includes receiving an image including one or more 3D objects. For example, the image is received by APD 116. The image may include any number of objects that are transformed for rendering on a 2D display screen.

[0039] As indicated by block 404, method 400 includes dividing an image into a number of tiles. For ease of explanation, the example shown in FIG. 5 includes an image (or frame) 500 divided into four equal tiles (i.e., an upper left quadrant, an upper right quadrant, a lower left quadrant, and a lower right quadrant). However, the image (or frame) may be divided into any number of tiles (e.g., 32 tiles) for a coarser level of tiling. The number of tiles is independent of the screen resolution.

[0040] As shown in block 406, method 400 includes performing coarse-level tiling (binning) of a first tile (bin) of the image. The coarse-level tiling is performed via fixed-function hardware. That is, rendering instructions (e.g., instructions from an application or program stored in a command buffer) are executed for each tile via the fixed-function hardware for the first tile (Tile 0) using visibility information (i.e., from the visibility pass executed for the frame). The coarse-level tiling visibility information is generated during the rendering of Tile 0. Tiles are processed at a pixel granularity, and during rasterization, it is determined (e.g., by a fast processor such as a GPU) whether a pixel corresponding to a primitive is located in the tile. For example, the coarse-level tile visibility information generated for Tile 0 indicates that a triangle (Tri1) is located within Tile 0.

[0041] As shown in block 408, a fine level of tiling is performed on Tile 0 before a coarse level of tiling is performed on the next tile (i.e., Tile 1 in FIG. 5). That is, as shown in FIG. 5, Tile 0 is divided into several fine (smaller) tiles. Any number of fine tiles may be used to implement the functionality of the present application. Fine level tiling (e.g., primitive batch tiling) is performed via the same fixed-function hardware used to perform coarse level tiling (as described in more detail below with respect to FIG. 6), utilizing local memory (e.g., on-chip cache) to accumulate batches of primitives (such as triangles) and render the primitives one fine tile at a time.

[0042] As shown in block 410, it is determined whether the image (frame) includes the next tile. If it is determined that the image does include the next tile, method 400 returns to block 406 and performs coarse-level tiling on the next tile, and then fine-level tiling on the next tile. For example, using the example shown in FIG. 5, if it is determined that image 500 includes the next tile (tile 1), then coarse-level tiling is performed on tile 1 in block 406, and then fine-level tiling is performed on tile 1. The method then proceeds to perform coarse-level tiling and fine-level tiling on each remaining tile in the image. For example, using the example shown in FIG. 5, method 400 performs coarse-level tiling and fine-level tiling on tile 2, and then coarse-level tiling and fine-level tiling on tile 3.

[0043] If, at block 410, it is determined that the image does not contain a next tile, the method proceeds to block 412 to process the next image (frame). For example, using the example shown in Figure 5, if, at block 410, it is determined that image 500 does not contain a next tile (i.e., after coarse and fine level tiling have been performed on tile 3), the method 400 proceeds to block 412 to render the next image (frame).

[0044] 6 is a block diagram of components of an example device illustrating an example flow for rendering a first tile of an image for display in accordance with the features of the present disclosure. For example, FIG. 6 illustrates performing coarse-level tiling and fine-level tiling of the first tile (Tile 0) of image 500 shown in FIG. 5.

[0045] 6, instructions are received via a command stream 602 by a processor 604 (e.g., a GPU) to perform rendering of tiles of an image. The instructions are stored, for example, in a command buffer (not shown). The processor 604 provides a geometry engine (GE) 606 with attributes of primitives (e.g., triangles) to be rendered.

[0046] The GE 606 receives index information from, for example, the index buffer 608 and communicates attribute information provided by the processor 604 to a shader (non-fixed function hardware) for processing. For example, triangle vertices are stored locally (e.g., in a vertex buffer). For each triangle, the index information indicates which three points from the vertices stored in the vertex buffer are vertices of the triangle. That is, the index information describes the connectivity of the vertices. For example, two triangles that do not share an edge are composed of six vertices, while two triangles that share an edge are composed of four vertices. For two triangles composed of six vertices, the indices of the two triangles may be (0, 1, 2) (3, 4, 5), and for two triangles composed of four vertices, the indices of the two triangles may be (0, 1, 2) (1, 2, 3). The GE may be implemented in hardware (e.g., fixed function hardware), software, or a combination of hardware and software.

[0047] The shader 610 receives primitives as 3D objects and converts them into 2D objects for rendering on a 2D screen. For example, the shader 610 determines the location of the vertices of a triangle within a frame. The location information is provided to a primitive assembler 612. Additional information (e.g., color and texture information) is also provided to a primitive cache portion 616 of local memory.

[0048] The primitive assembler 612 uses the location information determined by the shader 610 to connect the vertices and determine the position of each triangle in the frame from the location of each triangle's vertices. The position information is then provided to the primitive tiler and rasterizer 614 and the primitive cache portion 616.

[0049] The primitive tiler and rasterizer 614 represents a fixed-function hardware block that performs two different functions. That is, the same fixed-function hardware is used to perform both coarse-level tiling and fine-level tiling. The primitive tiler and rasterizer 614 divides an image (frame) into coarse tiles and divides the coarse tiles into fine tiles. The primitive tiler and rasterizer 614 performs coarse-level tiling (i.e., coarse-level rasterization) to determine in which coarse tile each primitive (e.g., triangle) is located. That is, for each coarse tile, the primitive tiler and rasterizer 614 determines the visibility of each triangle within the coarse tile. For example, using the example shown in FIG. 5, the primitive tiler and rasterizer 614 determines that triangle TRI1 is located in tile 0. The location information is stored in local memory (e.g., cache memory) as visibility information 618. The Primitive Tiler and Rasterizer 614 also utilizes local memory (e.g., on-chip cache) to store batches of primitives (e.g., triangles) and performs fine-level tiling, rendering the primitives one fine tile at a time.

[0050] The primitive tiler and rasterizer 614 determines the on-screen location of each primitive to be projected onto the 2D screen. For example, during rasterization, a high-speed processing device (e.g., a GPU) determines, for each primitive, which pixel (or sub-pixel sample) corresponds to each primitive to be rendered on the 2D screen. During the pixel shader stage, values ​​(e.g., brightness and color) are calculated for the pixel corresponding to the primitive and provided to the pixel pipe 620.

[0051] 7 is a flow diagram illustrating an exemplary method for rendering each of the other tiles of an image (i.e., the remaining tiles other than the first tile) for display in accordance with the features of this disclosure. For example, FIG. 7 illustrates performing coarse-level tiling and fine-level tiling of tile 1, tile 2, and tile 3 of image 500 shown in FIG. 5.

[0052] When rendering each of the remaining tiles, processor 404 executes the same instructions as for Tile 0, but visibility information 418 stored in local memory is utilized to reduce processing (e.g., unnecessary processing) of data (e.g., primitives) for the remaining tiles, as shown in Figure 6. For example, using the example shown in Figure 5, during processing of Tile 0, it is determined that Triangle 1 (Tri1) is not located in Tile 1 as shown in Figure 5. Therefore, when Tile 1 is processed, processing of Tri1 is avoided.

[0053] 7, the stored visibility information 418 is divided into two types of visibility information: draw call visibility information 702 and triangle visibility information 704. The visibility information 418 describes each tile's draws (each containing one or more primitives, such as triangles). The draw call visibility information 702 describes which draws are contained in the tile being processed, and the triangle visibility information 704 describes which triangles of each draw are contained in the tile being processed.

[0054] For example, using the example image 500 of FIG. 5 , which includes two triangles (Tri1 and Tri2), the instruction might be “Draw 1: Tri1, Tri2.” That is, the instruction indicates a draw (e.g., Draw 1) and the triangles within the draw (e.g., Draw 1 includes Tri1 and Tri2). The processor 604 receives the same instruction for each tile. For example, assuming there is only one draw instruction, when processing a first tile (Tile 0), the visibility information 618 for Tile 0 determines that Tri1 is visible in Tile 0, but Tri2 is not visible in Tile 0. When processing a second tile (Tile 1), the draw call visibility information 702 indicates that Draw 1 includes one triangle, and the triangle visibility information 704 for Tile 1 determines that Tri1 is Tri2 because it was determined during processing of Tile 0 that Tri1 was not within Tile 1.

[0055] When processing tile 2, draw call visibility information 702 again indicates that draw 1 contains only one triangle, and triangle visibility information 704 for tile 2 is determined as Tri1. When processing tile 3, draw call visibility information 702 again indicates that draw 1 contains only one triangle, and triangle visibility information 704 for tile 3 is determined as Tri2. Thus, unnecessary processing (e.g., tile 2, tile 2, second triangle in tile 3) is avoided. The remaining blocks 610-620 of Figure 7 then perform the same functions as those described above with respect to Figure 6.

[0056] 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 the other features and elements or in various combinations with or without the other features and elements.

[0057] The various functional units illustrated in the figures and / or described herein (including, but not limited to, the processor 102, input drivers 112, input devices 108, output drivers 114, output devices 110, APD 116, scheduler 136, graphics processing pipeline 134, compute unit 132, and 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 medium and executable by a general-purpose computer, processor, or processor core. The provided methods may be implemented in a general-purpose computer, processor, or processor core. By way of example, suitable processors include a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), and / or state machines. Such a processor may be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data, including a netlist (instructions that may be stored on a computer-readable medium). The result of such processing may be a maskwork used in a semiconductor manufacturing process to produce a processor that implements the functions of the present disclosure.

[0058] The methods or flowcharts 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 such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs).

Claims

1. 1. A method of tiled rendering of an image for display, comprising: performing coarse-level tiling on a first coarse tile of an image, the coarse-level tiling including identifying and rendering a set of primitives that cover the first coarse tile; performing fine level tiling on the first coarse tile of the image, the fine level tiling including rendering the set of primitives into fine tiles based on primitives identified by the coarse level tiling; after performing coarse level tiling for the first coarse tile and fine level tiling for the first coarse tile, performing coarse level tiling and fine level tiling for a second coarse tile of the image based on a set of primitives identified by the coarse level tiling for the first coarse tile. method.

2. performing fine level tiling on the first coarse tile of the image includes dividing the first coarse tile into smaller fine tiles; 10. The method of claim 1.

3. performing a coarse level of tiling for each tile of the image; 10. The method of claim 1.

4. primitive visibility information is determined for a first tile, and for each remaining tile of the image, the visibility information is split into draw-call visibility information and triangle visibility information; 10. The method of claim 1.

5. For each remaining tile being processed, the draw call visibility information indicates which draws are included, and the triangle visibility information indicates which triangles of each draw are included in the tile being processed. The method of claim 4.

6. the coarse level tiling and the fine level tiling are performed using the same fixed function hardware; 10. The method of claim 1.

7. performing the coarse-level tiling and the fine-level tiling via the same fixed-function hardware; performing the coarse level tiling to determine in which tile each of a plurality of primitives is located; performing said fine level tiling by utilizing a local cache memory to store batches of primitives and rendering the primitives one fine tile at a time; The method of claim 6.

8. 1. A processing device for rendering an image for display, comprising: Memory and a processor, The processor: performing coarse-level tiling on a first coarse tile of an image, the coarse-level tiling including identifying and rendering a set of primitives that cover the first coarse tile; performing fine level tiling on the first coarse tile of the image, the fine level tiling including rendering the set of primitives into fine tiles based on primitives identified by the coarse level tiling; after performing coarse level tiling for the first coarse tile and fine level tiling for the first coarse tile, performing coarse level tiling and fine level tiling for a second coarse tile of the image based on a set of primitives identified by the coarse level tiling for the first coarse tile; configured to: Processing device.

9. the processor is configured to perform a fine level of tiling on the first coarse tile of the image by dividing the first coarse tile into smaller tiles. The processing device of claim 8.

10. the processor is configured to perform a coarse level of tiling for each tile of the image. The processing device of claim 8.

11. and further comprising the same fixed function hardware used to perform the coarse level tiling and the fine level tiling. The processing device of claim 8.

12. The same fixed function hardware may include: performing the coarse level tiling to determine in which tile each of a plurality of primitives is located; performing said fine level tiling by utilizing a local cache memory to accumulate batches of primitives and render the primitives one fine tile at a time; configured to: The processing device of claim 11.

13. The processor: configured to determine visibility information for a first tile of the image; For each remaining tile of the image, the visibility information is split into draw-call visibility information and triangle visibility information. The processing device of claim 8.

14. For each remaining tile being processed, the draw call visibility information indicates which draws are included, and the triangle visibility information indicates which triangles of each draw are included in the tile being processed. The processing device of claim 13.

15. the processor is configured to receive the draw call visibility information for each of the remaining tiles of the image and provide attributes of primitives to be rendered to a geometry engine. The processing device of claim 14.

16. the geometry engine is fixed function hardware; 16. The processing device of claim 15.

17. the geometry engine receives the triangle visibility information and stored index information, and communicates the attributes of the primitives for each triangle determined to be in the image being processed according to the triangle visibility information.

16. The processing device of claim 15.

18. 1. A computer-readable storage medium containing instructions for causing a computer to perform a method for tiled rendering of an image for display, The method comprises: performing coarse-level tiling on a first coarse tile of an image, the coarse-level tiling including identifying and rendering a set of primitives that cover the first coarse tile; performing fine level tiling on the first coarse tile of the image, the fine level tiling including rendering the set of primitives into fine tiles based on primitives identified by the coarse level tiling; after performing coarse level tiling for the first coarse tile and fine level tiling for the first coarse tile, performing coarse level tiling and fine level tiling for a second coarse tile of the image based on a set of primitives identified by the coarse level tiling for the first coarse tile. A computer-readable storage medium.

19. performing fine level tiling on the first coarse tile of the image includes dividing the first coarse tile into smaller tiles; 20. The computer-readable storage medium of claim 18.

20. a coarse level of tiling is performed for each tile of the image; 20. The computer-readable storage medium of claim 18.

Images