Tile-based immediate mode rendering graphics pipeline

Abstract

To implement a tile-based immediate mode rendering graphics pipeline, an acceleration unit (AU) divides a frame to be rendered into two or more tiles. For each primitive in a batch of primitives, the AU then determines whether the primitive is at least partially visible in a tile. Based on the primitive being at least partially visible in the tile, the AU stores geometry data for the primitive in the tile in a corresponding per-tile queue assigned to the tile. For each tile and using the geometry data in the per-tile queue assigned to the tile, the AU renders attribute data for primitives that are at least partially visible in the tile to one or more buffers. The AU next determines lighting data for primitives that are at least partially visible in the tile based on the attribute data in the buffers, and stores the results in a frame buffer for display.

Description

Background Technology

[0001] In a graphics processing system, a 3D scene is rendered by a graphics processing unit (GPU) for display on a 2D monitor. To render such a scene, the GPU receives a command stream from the application, which instructs various primitives to be rendered. The GPU then renders these primitives according to a graphics pipeline with various stages, each containing instructions to be executed by the GPU. For example, some graphics pipelines include a visibility traversal, where the GPU categorizes primitives into bins based on which tiles in the scene each primitive is visible to. The GPU then renders the primitives in each bin sequentially. For example, the GPU renders the primitives in the first bin before rendering the primitives in the second bin. After rendering the primitives, the graphics processing system displays the rendered primitives as part of the 3D scene displayed on the 2D monitor. Attached Figure Description

[0002] This disclosure can be better understood by referring to the accompanying drawings, and many of its features and advantages will be apparent to those skilled in the art. The same reference numerals are used in different drawings to denote similar or identical items.

[0003] Figure 1 It is a block diagram of a processing system configured to implement a tile-based real-time rendering graphics pipeline, according to some implementation schemes.

[0004] Figure 2 It is a block diagram of an example processor core configured to implement at least a portion of a tile-based real-time rendering graphics pipeline, according to the implementation scheme.

[0005] Figure 3 It is a timeline of a tile-based real-time mode rendering graphics pipeline based on an example implementation scheme.

[0006] Figure 4 This is a block diagram of example operations for managing the geometric and pixel states of a tile-based real-time rendering graphics pipeline, according to the implementation plan.

[0007] Figure 5 This is an example method for implementing a tile-based real-time mode rendering graphics pipeline, based on the implementation scheme. Detailed Implementation

[0008] The systems and techniques disclosed herein relate to a processing system configured to implement a tile-based real-time rendering graphics pipeline. Such a tile-based real-time rendering graphics pipeline includes first dividing a frame to be rendered into two or more tiles. Furthermore, the tile-based real-time rendering graphics pipeline includes determining which primitives of the frame to be rendered are at least partially visible in each tile, and then sequentially rendering the primitives that are at least partially visible in each tile. For example, for the first tile of a frame, the tile-based real-time rendering graphics pipeline includes rendering pixel attribute data (e.g., position, color) associated with the primitives that are at least partially visible in the first tile to one or more per-pixel color buffers (PPC buffers). The tile-based real-time rendering graphics pipeline then includes determining the illumination values ​​(e.g., intensity values) of the pixels of the primitives that are at least partially visible in the first tile based on the pixel attribute data in the PPC buffers. The resulting pixel data and illumination data are then stored in a frame buffer, and the process is repeated for each tile of the frame.

[0009] To implement such a tile-based real-time rendering graphics pipeline, the processing system includes an acceleration unit (AU) configured to receive a command stream from an application being executed by the processing system. The command stream, for example, includes data indicating primitives to be rendered for each frame in a series of frames. As an example, for the first frame in the frame set, the command stream includes data including one or more commands (e.g., drawing commands, shading commands), geometry states, one or more pixel states, and data indicating one or more primitives to be rendered in the frame (e.g., vertices). These geometry states include data (e.g., parameters) for initializing and indicating the tile-based real-time rendering graphics pipeline, the geometry phases of the tile-based real-time rendering graphics pipeline, or both. Additionally, the pixel states include data (e.g., parameters) for initializing and indicating the tile drawing phase and the tile lighting phase of the tile-based real-time rendering graphics pipeline. Such stages of the tile-based real-time rendering graphics pipeline (e.g., geometry stage, tile drawing stage, tile lighting stage) each include a set of commands (e.g., draw commands, shading commands) that use the same resources (e.g., the same metadata), geometry states, pixel states, or any combination thereof, indicated in the command stream. Based on the received command stream, the AU first divides the frame to be rendered into two or more tiles. Furthermore, the AU assigns a corresponding per-tile queue to each tile of the frame. The AU then performs the geometry stage of the pipeline. During such a geometry stage, the AU determines which primitives of the frame are at least partially visible in each tile of the frame. Based on the fact that primitives are at least partially visible in a tile, the AU stores geometry data indicating the vertex data, shading data, positioning data, or any combination thereof of the primitives in the per-tile queue assigned to the tile.

[0010] After the Active Graph (AU) has stored data indicating which primitives in a batch of primitives are at least partially visible in each tile of a frame, the AU initiates, for example, a tile-based real-time rendering graphics pipeline tile-drawing phase for the first tile. During the tile-drawing phase for the first tile, the AU renders the primitives at least partially visible in the first tile to one or more per-pixel color buffers (PPC buffers) based on the geometry data stored in the per-tile queue allocated to the first tile. That is, based on the geometry data stored in the per-tile queue allocated to the first tile, the AU determines pixel attribute data indicating the position and color of the pixels of the primitives in the batch that are at least partially visible in the first tile. After writing such pixel attribute data associated with the first tile to the PPC buffers, the AU performs a tile-based real-time rendering graphics pipeline tile-lighting phase for the first tile. During the tile-lighting phase for the first tile, the AU is configured to determine lighting data (e.g., intensity data) for each pixel of the primitives at least partially visible in the first tile based on the pixel attribute data associated with the first tile in the PPC buffers. The AU then stores the color data of each pixel representing the at least partially visible primitives in the first tile into a frame buffer for display, based on the lighting data for each pixel. The AU then performs a tile drawing phase and a tile lighting phase for the remaining tiles of the frame.

[0011] In this way, the processing system implements a tile-based real-time rendering graphics pipeline. Because within the tile-based real-time rendering graphics pipeline, the AU renders primitives based on a single command stream from the application, the processing system does not need to manage in-memory state objects to allow, for example, the AU to access the stored state. This reduces the complexity and resources required for rendering primitives, thus contributing to improved processing efficiency. Additionally, because the AU determines the lighting data of pixels from pixel attribute data in the PPC buffer, the AU does not need to repeat primitive assembly and shading during the tile lighting phase, further reducing the processing resources and time required for rendering primitives. Furthermore, in some instances, once the AU has completed the tile drawing phase for the first tile in the graphics pipeline, the AU is configured to release the pixel attribute data associated with that first tile from the PPC buffer. When the pixel attribute data associated with the first tile is released from the PPC buffer, the AU is configured to perform the tile drawing phase for the second tile of the frame based on the corresponding pixel state of the command stream. In this way, AU does not need to wait for the pixel attribute data to be released before executing the next stage of the tile-based real-time rendering graphics pipeline, thereby reducing the amount of time required to execute stages (e.g., command groups) of the tile-based real-time rendering graphics pipeline.

[0012] Figure 1This is a block diagram of a processing system 100 configured to implement a tile-based real-time rendering graphics pipeline according to some specific embodiments. The processing system 100 includes or has access to memory 106 or other storage components implemented using non-transitory computer-readable media (e.g., dynamic random access memory (DRAM)). However, in specific embodiments, memory 106 is implemented using other types of memory (including, for example, static random access memory (SRAM), non-volatile RAM, etc.). According to specific embodiments, memory 106 includes external memory implemented outside the processing units implemented in the processing system 100. The processing system 100 also includes a bus 112 to support communication between entities implemented in the processing system 100, such as memory 106. Some specific embodiments of the processing system 100 include other buses, bridges, switches, routers, etc., which are not shown for clarity. Figure 1 As shown in the image.

[0013] In various specific implementations, the techniques described herein are employed at acceleration unit (AU) 114. AU 114 includes, for example, a vector processor, a coprocessor, a graphics processing unit (GPU), a nonscalar processor, a highly parallel processor, other multithreaded processing units, a scalar processor, a serial processor, a programmable logic device (e.g., a field-programmable gate array), or any combination thereof. In implementations, AU 114 renders a scene within a screen space (e.g., the space where a display scene is shown) for presentation on display 120, based on one or more applications 108. For example, AU 114 renders graphical objects (e.g., a set of primitives) of the scene in the screen space (e.g., the display space) to produce pixel values ​​provided to display 120, which uses these pixel values ​​to display a scene representing the rendered graphical objects. To render these graphical objects, AU 114 implements multiple processor cores 116-1 to 116-N that execute instructions concurrently or in parallel. For example, AU 114 uses multiple processor cores 116 to execute instructions from one or more graphics pipelines (e.g., a tile-based real-time rendering graphics pipeline 124) to render one or more graphics objects. The graphics pipeline, for example, includes one or more steps, stages, or instructions to be executed by AU 114 to render one or more graphics objects for a scene. As an example, the graphics pipeline includes data instructing one or more processor cores 116 of AU 114 to execute one or more graphics objects for a scene, such as an assembler stage, vertex shader stage, shell shader stage, tessellation stage, domain shader stage, geometry shader stage, binning stage, rasterizer stage, pixel shader stage, output merger stage, or any combination thereof.

[0014] In the implementation, one or more processor cores 116 of AU 114 each operate as a compute unit, configured to perform one or more operations on one or more instructions received by AU 114. Each of these compute units includes one or more Single Instruction Multiple Data (SIMD) units that perform the same operation on different datasets to produce one or more results. For example, AU 114 includes one or more processor cores 116, each processor core serving as a compute unit, which includes one or more SIMD units to perform operations on one or more instructions from a graphics pipeline (e.g., a tile-based real-time rendering graphics pipeline 124). To facilitate the execution of operations by one or more compute units on instructions from the graphics pipeline, AU 114 includes one or more command processors (not shown for clarity). Such command processors include, for example, circuitry configured to execute one or more instructions from the graphics pipeline by providing one or more compute units with data indicating one or more operations, operands, instructions, variables, register files, or any combination thereof, which is necessary, helpful, or auxiliary for the execution of one or more operations of the instructions. Although Figure 1 The example implementation shown presents the AU 114 as having three processor cores (116-1, 116-2, 116-N) representing N cores, but the number of processor cores 116 implemented in the AU 114 is a matter of design choice. Therefore, in other implementations, the AU 114 may include any number of processor cores 116.

[0015] According to implementations, one or more processor cores 116 of AU 114 (each operating as one or more computing units) are configured to store results (e.g., data generated by the execution of one or more instructions, operations, or both) in one or more caches 122, memory 106, or both. For example, such caches 122 may include one or more caches included in or otherwise connected to the processor core 116. As an example, in implementations, caches 122 may include one or more caches shared among one or more processor cores 116 (e.g., shared caches), one or more caches private to the corresponding processor core 116 (e.g., accessible only by the corresponding processor core) (e.g., private caches), or both. For example, according to some implementations, caches 122 may include a cache hierarchy that includes one or more private caches, one or more shared caches, or both.

[0016] In one implementation, AU 114 is configured to render one or more graphics objects based on a tile-based real-time rendering graphics pipeline 124. The tile-based real-time rendering graphics pipeline 124 includes, for example, a real-time renderer, wherein application 108 issues a command stream including data describing all graphics objects (e.g., primitives) in the scene to be rendered for each frame. For example, in one implementation, the command stream from application 108 includes data indicating the positions of vertices of one or more primitives to be rendered, one or more commands (e.g., draw commands, shader commands), one or more geometric states 115, and one or more pixel states 125. Such geometric states 115 include, for example, data (e.g., parameters) for initializing and indicating the tile-based real-time rendering graphics pipeline 124, its geometric stages, or both. As an example, one or more first geometric states 115 indicate the parameters, procedures, and data used in initializing the tile-based real-time rendering graphics pipeline 124, and one or more second geometric states indicate the parameters, procedures, and data used in the geometric phases of the tile-based real-time rendering graphics pipeline 124. Additionally, such pixel states 125 include data (e.g., parameters) for initializing and indicating the tile drawing and tile lighting phases of the tile-based real-time rendering graphics pipeline 124. For example, one or more first pixel states 125 indicate the parameters, procedures, and data used in the tile drawing phase of the tile-based real-time rendering graphics pipeline 124, and one or more second pixel states 125 indicate the parameters, procedures, and data used in the tile lighting phase of the tile-based real-time rendering graphics pipeline 124. In an embodiment, AU 114 is configured to store the geometric states 115 and pixel states 125 indicated in the command stream in one or more caches 122, memories 106, or both. Furthermore, such geometry phases, tile drawing phases, and tile lighting phases of the tile-based real-time mode rendering graphics pipeline 124 each include a corresponding set of commands (e.g., drawing commands) using the same resources (e.g., the same metadata), geometric states, and pixel states.

[0017] According to an implementation, the tile-based real-time rendering graphics pipeline 124 includes dividing a frame to be rendered into two or more tiles, and then rendering the scene's graphical objects tile by tile. For example, based on one or more first geometry states 115 in a received command stream, AU 114 first divides the frame to be rendered into two or more tiles (e.g., coarse tiles). For example, each tile includes a first number of pixels in a first direction (e.g., horizontal) and a second number of pixels in a second direction (e.g., vertical) of the frame, as indicated by one or more first geometry states 115. According to some implementations, the tile includes the same number of pixels in the first and second directions, while in other implementations, the tile includes different numbers of pixels in the first and second directions. After dividing the frame to be rendered into two or more tiles, AU 114 then allocates multiple queues formed by at least a portion of cache 122, memory 106, or both to each tile of the frame, such that each tile has a corresponding per-tile queue. As an example, AU 114 partitions and allocates one or more per-shader engine queues formed by portions of cache 122, such that each tile of a frame is assigned a per-tile queue. Each per-tile queue includes, for example, one or more queues formed by at least a portion of cache 122, memory 106, or both. After AU 114 has allocated per-tile queues to each tile of a frame, AU 114 initiates the geometry phase of the tile-based instant-mode rendering graphics pipeline 124 based on one or more second geometry states 115 of the command flow.

[0018] For example, such a geometric phase includes a visibility traversal, in which AU 114 determines which primitives (e.g., graphics objects) to render for each tile of the frame. For example, based on data indicating the vertices of one or more primitives to be rendered in the command stream, AU 114 assembles (e.g., performs an assembly phase) and shades (e.g., executes one or more shaders) one or more of the indicated primitives. As an example, AU 114 first assembles one or more primitives indicated in the command stream. For each assembled primitive, AU 114 then determines which tiles of the frame the primitive at least partially covers. Based on AU 114's determination that the assembled primitives are at least partially visible in the tiles, AU 114 provides geometric data—vertex data, shader data, positioning data, or any combination thereof—indicating the primitives to the per-tile queue associated with the tile. According to some embodiments, AU 114 continues performing the visibility traversal until a command (e.g., a tile refresh command) is received from the command stream, one or more per-tile queues reach a predetermined capacity threshold (e.g., storing a predetermined amount of data), or both. After receiving a command (e.g., a tile refresh command) from a command stream, one or more per-tile queues reaching a predetermined capacity threshold (e.g., storing a predetermined amount of data), or both, AU 114 then renders a set (e.g., a batch) of primitives represented by geometric data stored in the per-tile queues associated with the tiles. The per-tile geometry data of the primitives in this batch that are at least partially visible within the tiles is rendered... Figure 1 The data is represented as geometric data 105 per tile.

[0019] To render the primitives in the batch of primitives, AU 114 initiates a first tile drawing phase for the first tile of the frame based on one or more first pixel states 125 indicated in the command stream. As an example, concurrently with the continuing geometry phase, AU 114 initiates a first tile drawing phase for the first tile based on one or more first pixel states 125. To perform such a tile drawing phase, AU 114 is configured to first render the primitives in the batch of primitives that are at least partially visible in the first tile to one or more PPC buffers formed by at least a portion of cache 122, memory 106, or both. For this purpose, AU 114 is configured to render the primitives in the batch of primitives that are at least partially visible in the first tile based on per-tile geometry data 105 stored in a per-tile queue associated with the first tile. As an example, AU 114 first consumes the per-tile queue associated with the first tile, the per-tile geometry data representing the primitives in the batch of primitives that are at least partially visible in the first tile. Based on one or more first pixel states 125, AU114 then uses per-patch geometry data 105 to assemble, rasterize, and color the primitives to produce per-patch pixel attribute data stored in a PPC buffer and per-patch pixel depth data stored in a depth buffer (e.g., a Z-buffer) formed by at least a portion of cache 122, memory 106, or both. Such per-patch pixel attribute data represents the attributes (e.g., color, position) of pixels forming primitives at least partially visible in the patch, and such per-patch pixel depth data represents the depth of pixels forming primitives at least partially visible in the patch.

[0020] According to the implementation scheme, the tile rendering phase also includes AU 114 performing one or more depth culling techniques based on the per-tile pixel depth data in the Z-buffer and one or more first pixel states 125. For example, for each pixel forming a primitive in the batch that is at least partially visible in the tile, AU 114 compares the pixel's depth value with one or more predetermined thresholds. Based on the comparison of the pixel's depth value with the predetermined thresholds, AU 114 then culles the pixel from the Z-buffer, PPC-buffer, or both by, for example, not storing the pixel attribute data or pixel depth data in the PPC-buffer or Z-buffer, respectively. As an example, if the comparison of the pixel's depth value with the predetermined thresholds indicates that the pixel is at least partially occluded (e.g., at least a portion of the pixel is not visible in the scene), AU 114 then culles the pixel.

[0021] After completing the tile drawing phase for the first tile, AU 114 performs a tile lighting phase for the first tile. During such a tile lighting phase, AU 114 performs one or more pixel shading operations as indicated in one or more second pixel states 125 to determine lighting values ​​(e.g., intensity values) using per-tile pixel attribute data in the PPC buffer. These lighting values ​​represent direct and indirect lighting for each pixel of the primitives forming the batch of primitives that are at least partially visible in the tile. AU 114 then stores the pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of the primitives forming the primitives that are at least partially visible in the tile in a frame buffer formed by cache 122, memory 106, or at least a portion of both. In some embodiments, once AU 114 has determined the lighting values ​​for each pixel of the primitives forming the primitives that are at least partially visible in the tile, AU 114 discards the per-tile pixel attribute data associated with the tile stored in the PPC buffer. For example, based on one or more commands from application 108, AU 114 discards the per-tile pixel attribute data associated with the tile stored in the PPC buffer after executing commands included in the tile lighting phase for the tile. That is, AU 114 removes the per-tile pixel attribute data associated with the tile from the PPC buffer. After executing the tile drawing phase, tile lighting phase, or both for the first tile, AU 114 executes the tile drawing phase and tile rendering phase for each other tile in the frame to render the primitives in that batch. After rendering the primitives in that batch, AU 114 renders a second batch of primitives based on the geometric data determined during the geometry phase by executing the tile drawing phase and tile lighting phase for each tile in the frame. AU 114 continues in this manner until all primitives in the frame have been rendered.

[0022] In this way, AU 114 is configured to implement a tile-based real-time rendering graphics pipeline 124. Because the tile-based real-time rendering graphics pipeline 124 allows AU 114 to render primitives based on a single command stream from application 108, processing system 100 does not need to manage in-memory state objects to allow AU 114 to access stored state, thereby reducing the complexity and resources required for rendering primitives. Additionally, since the tile-based real-time rendering graphics pipeline 124 requires AU 114 to determine pixel light values ​​from per-tile pixel attribute data in the PPC buffer, the assembly and shading of primitives completed during the tile rendering phase are not repeated during the tile lighting phase, thus helping to reduce the processing resources and processing time required for rendering primitives. Furthermore, because the tile-based real-time rendering graphics pipeline 124 involves rendering primitives tile by tile rather than rendering the entire frame at once, it reduces the processing resources required at any given time, thereby helping to reduce power consumption and improve the processing efficiency of processing system 100.

[0023] According to some implementations, after AU 114 has completed the tile drawing phase for the first tile, AU 114 releases the per-tile pixel attribute data in the PPC buffer and uses the released per-tile pixel attribute data to perform a tile lighting phase. For example, based on one or more commands provided by application 108 to release the per-tile pixel attribute data (e.g., at the frame buffer level), AU 114 releases the per-tile pixel attribute data after completing the tile drawing phase for the first tile and performs a tile lighting phase for the first tile. For example, AU 114 refreshes one or more PPC buffers to release the per-tile pixel attribute data. Furthermore, in some implementations, when AU 114 releases the per-tile pixel attribute data in the PPC buffer to perform a tile lighting phase for the first tile, AU 114 is configured to perform a tile drawing phase for a second tile of the frame, a tile lighting phase for the second tile of the frame, or both. As an example, when releasing the per-tile pixel attribute data in the PPC buffer to perform a tile lighting phase for the first tile, AU 114 performs a tile drawing phase for the second tile, stores the per-tile pixel attribute data of the primitives in the second tile in the PPC buffer, and releases the per-tile pixel attribute data of the primitives in the second tile from the PPC buffer to perform a lighting phase for the second tile. Furthermore, as an example, when AU 114 releases the per-tile pixel attribute data of the primitives in the second tile from the PPC buffer, AU 114 performs a lighting phase for the first tile and a drawing phase for the third tile. Because AU 114 performs such phases (e.g., command groups) when releasing the per-tile pixel attribute data from the PPC buffer, AU 114 does not need to wait for the per-tile pixel attribute data to be released before starting the next phase of the tile-based instant-mode rendering graphics pipeline 124, thus helping to reduce pauses between phases and helping to reduce the time required to render primitives. Those skilled in the art will understand that the release and acquisition of such per-tile pixel attribute data is based on commands issued from one or more applications 108, and thus represents an example implementation of the tile-based real-time mode rendering graphics pipeline 124.

[0024] In one implementation, the processing system 100 also includes a central processing unit (CPU) 102 connected to a bus 112 and thus communicating with the AU 114 and memory 106 via the bus 112. The CPU 102 implements multiple processor cores 104-1 to 104-N that execute instructions concurrently or in parallel. In a specific implementation, one or more processor cores of the processor cores 104 operate as SIMD units performing the same operation on different datasets. For example, one or more processor cores 104 operate as SIMD units, each SIMD unit having two or more channels respectively configured to perform wave operations (e.g., spatial testing). Although in Figure 1 In the illustrated example implementation, three processor cores (104-1, 104-2, 104-M) representing M cores are presented, but the number of processor cores 104 implemented in CPU 102 is a matter of design choice. Therefore, in other implementations, CPU 102 may include any number of processor cores 104. In some implementations, CPU 102 and AU 114 have an equal number of processor cores 104 and 116, while in other implementations, CPU 102 and AU 114 have different numbers of processor cores 104 and 116. Processor core 104 executes instructions (such as program code 110 of one or more applications 108 stored in memory 106), and CPU 102 stores information (such as the results of the executed instructions) in memory 106. CPU 102 is also capable of initiating graphics processing by issuing command streams from one or more applications 108 to AU 114.

[0025] The processing system 100 also includes an input / output (I / O) engine 118, which includes hardware and software for handling input or output operations associated with the display 120, as well as other components of the processing system 100, such as a keyboard, mouse, printer, external disk, etc. The I / O engine 118 is coupled to a bus 112, enabling the I / O engine 118 to communicate with the memory 106, AU 114, or CPU 102.

[0026] Now for reference Figure 2According to an implementation, an example processor core 200 is presented, configured to implement at least a portion of a tile-based real-time rendering graphics pipeline. In some implementations, the example processor core 200 is implemented as processor core 116 within AU 114. According to an implementation, the example processor core 200 is configured to implement at least a portion of the tile-based real-time rendering graphics pipeline 124 by executing one or more instructions, operations, or both associated with the tile-based real-time rendering graphics pipeline 124. For this purpose, the example processor core 200 is connected to a command processor 232. The command processor 232 includes, for example, circuitry configured to receive a command stream from an application 108. Such a command stream includes, for example, one or more geometric states 115, pixel states 125, and data indicating one or more primitives to be rendered in the scene of an indicative frame. The command processor 232 then provides the data indicating the geometric states 115, pixel states 125, and primitives to be rendered (e.g., vertex data) to the example processor core 200. Such geometric states 115 may include, for example, data (e.g., parameters) for initializing and indicating the tile-based real-time rendering, the geometric phases of the tile-based real-time rendering graphics pipeline 124, or both. Additionally, such pixel states 125 may include data (e.g., parameters) for initializing and indicating the tile drawing phases and tile lighting phases of the tile-based real-time rendering graphics pipeline 124.

[0027] Based on one or more first geometry states 115 provided from command processor 232, example processor core 200 initializes a tile-based real-time rendering graphics pipeline 124. To this end, example processor core 200 first divides the frame to be rendered into multiple tiles as indicated by one or more first geometry states 115. For example, each tile includes multiple pixels in a first direction and multiple pixels in a second direction, as indicated by one or more first geometry states 115. After dividing the frame into tiles, example processor core 200 then assigns per-tile queues 228 to each tile of the frame, as indicated by one or more first geometry states 115. For example, AU 114 assigns a first per-tile queue 0 228-1 to the first tile, a second per-tile queue 1 228-2 to the second tile, a third per-tile queue 2 228-3 to the third tile, and an Nth per-tile queue N 228-N to the Nth tile. Each of these per-tile queues 228 is formed from at least a portion of cache 122, memory 106, or both, and includes one or more queues, such as first-in-first-out (FIFO) queues. Although Figure 2The example implementation presented illustrates an example processor core 200 having four per-tile queues 228, representing N per-tile queues 228 supporting N tiles of a frame. However, in other implementations, the example processor core 200 may include any number of per-tile queues 228 supporting any number of tiles of a frame. Furthermore, in some implementations, each per-tile queue 228 is formed by one or more per-shader engine queues of the example processor 200.

[0028] Based on one or more second geometry states 115 of the command stream, the example processor core 200 then performs a geometry phase (e.g., visibility traversal) to determine which primitives to be rendered in the frame are at least partially visible in each tile of the frame. To this end, the example processor core 200 includes or is otherwise connected to geometry circuitry 226, which is configured to implement one or more primitive assemblers, shaders (e.g., geometry shaders), or both, to assemble and shade one or more primitives based on one or more second geometry states 115. As an example, based on one or more second geometry states 115 and data indicating the primitives to be rendered in the frame, geometry circuitry 226 assembles and shades one or more primitives among the indicated primitives. Once geometry circuitry 226 has assembled and shaded the indicated primitives, it determines for each assembled primitive in which tile the primitive is at least partially visible. Based on the fact that the assembled primitive is at least partially visible in a tile, geometry circuitry 226 provides geometry data representing any combination of vertex data, shaded data, positioning data, or primitives to a per-tile queue 228 allocated to the tiles. In the implementation, geometry circuit 226 is configured to perform visibility traversal until a command (e.g., a tile refresh command) is received from the command stream, one or more per-tile queues 228 are at a predetermined capacity threshold (e.g., storing a predetermined amount of data), or both. Once a command (e.g., a tile refresh command) is received from the command stream, one or more per-tile queues 228 are at the predetermined capacity threshold (e.g., storing a predetermined amount of data), or both, geometry circuit 226 forms a batch of primitives to be rendered, represented by the geometric data stored in the per-tile queues 228.

[0029] After geometric circuit 226 has stored the geometric data representing each primitive in a batch of primitives that is at least partially visible in a tile into the corresponding per-tile queue 228, such stored data... Figure 2The data is represented as per-tile geometry data 105. Each of these per-tile geometry data (105-1, 105-2, 105-3, 105-N) represents vertex data, shading data, positioning data, or any combination thereof for a primitive in a batch that is at least partially visible within the corresponding tile. According to the implementation, once the geometry circuit 226 has stored the per-tile geometry data 105 of that batch of primitives in each per-tile queue 228, the example processor core 200 is configured to perform a tile drawing phase for the first tile based on one or more first pixel states 125. As an example, with the geometry circuit 226 having completed the remainder of the geometry phase, the example processor core 200 is configured to perform a tile drawing phase for the first tile based on one or more first pixel states 125. For this purpose, the processor core 116 includes pixel circuitry 230, which is configured to implement one or more assemblers, shaders (e.g., fragment shaders), or both based on the corresponding pixel state 125.

[0030] As an example, to perform the tile-based real-time rendering graphics pipeline 124 for a first tile, pixel circuitry 230 is configured to first consume per-tile queue 228 (e.g., per-tile queue 0 228-1) associated with the first tile to receive per-tile geometry data 105 (e.g., per-tile geometry data 0 105-1) associated with the first tile. After obtaining the per-tile geometry data 105 associated with the first tile, pixel circuitry 230 then renders the primitives indicated in the per-tile geometry data 105 as batches (e.g., coarse batches) to one or more PPC buffers 234 based on one or more first pixel states 125. That is, AU 114 assembles, rasterizes, and shades the primitives indicated in the per-tile geometry data 105 based on one or more first pixel states 125 to produce per-tile pixel attribute data 235 stored in PPC buffers 234. Furthermore, based on the assembly, rasterization, and coloring of these primitives according to the per-patch geometry data 105, the pixel circuitry 230 generates per-patch pixel depth data 245 stored in the Z-buffer 236. The PPC buffer 234 and the Z-buffer 236 are, for example, each one or more buffers formed by at least corresponding portions of the cache 122, memory 106, or both. As an example, the PPC buffer 234 includes one or more buffers configured to store data indicating the color and position of each pixel in the frame, and the Z-buffer 236 includes one or more buffers configured to store data indicating the depth value of each pixel in the frame.

[0031] In one implementation, after performing a tile drawing phase for a first tile, per-tile pixel attribute data 235 stored in PPC buffer 234 represents, for example, the attributes (e.g., color, position) of pixels forming at least partially visible elements in the first tile within the batch of primitives, and per-tile pixel depth data 245 stored in Z buffer 236 represents the depth of pixels forming at least partially visible elements in the first tile within the batch of primitives. According to another implementation, the tile drawing phase further includes pixel circuitry 230 performing one or more depth culling techniques on the per-tile depth data 245, as indicated by the first pixel state 125. As an example, for each pixel forming at least partially visible elements in the tile, AU 114 compares the depth value of the pixel indicated in the per-tile pixel depth data 245 with one or more predetermined thresholds indicated in one or more first pixel states 125. Based on a comparison of the pixel's depth value with a predetermined threshold, pixel circuitry 230 removes pixels from Z-buffer 236, PPC-buffer 234, or both by, for example, not providing per-patch pixel attribute data 235 or per-patch pixel depth data 245 associated with the pixel to PPC-buffer 234 or Z-buffer 236, respectively. As an example, if a pixel is at least partially occluded (e.g., at least a portion of the pixel is not visible in the scene) based on a comparison of the pixel's depth value, as indicated by per-patch pixel depth data 245, with a predetermined threshold, pixel circuitry 230 then removes the pixel from Z-buffer 236, PPC-buffer 234, or both.

[0032] After pixel circuit 230 has completed the tile drawing phase for the first tile and based on one or more second pixel states 125, pixel circuit 230 executes the lighting phase for the first tile in the tile-based real-time rendering graphics pipeline 124. For example, as indicated by one or more second pixel states 125, pixel circuit 230 performs one or more pixel shading operations using per-tile pixel attribute data 235 associated with the first tile to determine lighting values ​​(e.g., intensity values) representing direct and indirect lighting for each pixel of at least partially visible primitives formed in the first tile. Pixel circuit 230 then stores the pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of at least partially visible primitives formed in the tile in a frame buffer (not shown for clarity) formed by cache 122, memory 106, or at least a portion of both.

[0033] According to some implementations, based on one or more commands from application 108, pixel circuit 230 is configured to release per-patch pixel attribute data 235 associated with the first patch from PPC buffer 234 to perform a patch lighting phase for the first patch. To this end, when pixel circuit 230 releases per-patch pixel attribute data 235 associated with the first patch from PPC buffer 234, AU 114 is configured to perform a patch drawing phase for the second patch of the frame, a patch lighting phase for the second patch of the frame, or both. As an example, when per-patch pixel attribute data 235 associated with the first patch is released and based on one or more corresponding pixel states 125, pixel circuit 230 performs a patch drawing phase for the second patch, stores per-patch pixel attribute data 235 of the second patch in PPC buffer 234, and releases the per-patch pixel attribute data 235 of the second patch from PPC buffer 234 to perform a lighting phase for the second patch. Furthermore, as an example, when pixel circuit 230 releases the per-patch pixel attribute data 235 of the second patch in PPC buffer 234 and based on the corresponding pixel state 125, pixel circuit 230 performs a lighting phase for the first patch and a drawing phase for the third patch.

[0034] Now for reference Figure 3 An example tile-based real-time rendering graphics pipeline 300 is presented according to some embodiments. According to the embodiments, the example tile-based real-time rendering graphics pipeline 300 is implemented by AU 114 based on one or more commands from application 108. For example, in one embodiment, after tile-based real-time rendering is initialized, the example tile-based real-time rendering graphics pipeline 300 first includes AU 114 performing a geometry phase 305 based on one or more first geometry states 115. During the geometry phase 305, AU 114 is configured to determine which primitives in a batch of primitives to be rendered in a frame are at least partially visible in each tile of the frame. To this end, AU 114 assembles and shades one or more primitives to be rendered in the frame based on one or more first geometry states 115. For each assembled primitive, AU 114 then determines which tiles the assembled primitive is at least partially visible (e.g., present) in the assembled primitives. In response to AU 114 determining that the assembled primitives are at least partially visible in the tile, AU 114 provides the vertex data, shading data, positioning data, or any combination of geometric data indicating the primitives (e.g., per-tile geometry data 105) to the per-tile queue 228 assigned to the tile.

[0035] According to some implementations, during geometry phase 305, AU 114 is configured to assemble primitives and determine in which tiles the assembled primitives are at least partially visible, until a command (e.g., a tile refresh command) is received in the command stream, one or more per-tile queues 228 are at a predetermined capacity threshold (e.g., storing a predetermined amount of data), or both. After receiving a specific command in the command stream, one or more per-tile queues 228 being at the predetermined capacity threshold, or both, AU 114 forms a batch of primitives to be rendered, represented by per-tile geometry data 105 stored in the per-tile queues 228. That is, AU 114 is configured to form a batch of primitives to be rendered based on a command received in the command stream, one or more per-tile queues 228 being at a predetermined capacity, or both. As an example, based on per-tile queues 228 becoming full, AU 114 is configured to render a batch of primitives (e.g., primitives represented by per-tile geometry data in the per-tile queues 228) by performing a tile drawing phase and a tile lighting phase for each tile of the frame. As another example, after initiating a visibility traversal and based on the command stream of the instruction to refresh the tile received by AU 114, AU 114 is configured to render a batch of primitives by performing a tile drawing phase and a tile lighting phase for each tile of the frame.

[0036] To render the primitives in the first batch of primitives, AU 114 is configured to begin tile 0 rendering phase 310 based on one or more first pixel states 125. For example, AU 114 begins tile 0 rendering phase 310 concurrently with the completion of the remainder of geometry phase 305. During tile 0 rendering phase 310, AU 114 renders primitives in the batch of primitives that were at least partially visible in the first frame to PPC buffer 234 based on per-tile geometry data 105 stored in per-tile queue 228 associated with the first tile. For example, refer to Figure 3In the implementation presented, AU 114 renders primitives at least partially visible in the first frame from the batch of primitives based on per-patch geometry data 0 105-1 from per-patch queue 0228-1. In this implementation, during the tile 0 rendering phase 310, AU 114 first assembles, rasterizes, and shades the primitives indicated in the per-patch geometry data 0 105-1 based on one or more first pixel states 125 to produce per-patch pixel attribute data 235 stored in one or more PPC buffers 234 and per-patch pixel depth data 245 stored in a Z buffer 236. According to some implementations, the tile 0 rendering phase 310 includes AU 114 performing a clipping operation based on the size of the tile. For example, based on one or more first pixel states, AU 114 discards per-patch pixel attribute data 235 and per-patch pixel depth data 245 associated with any pixels outside a frame (e.g., a frame having the same size and position as the tile) based on the size and position of the tile. Additionally, in some embodiments, the tile 0 rendering phase 310 includes AU 114 performing one or more depth culling techniques based on the determined per-tile pixel depth data 245. For example, for each pixel forming a primitive that is at least partially visible in the tile and based on one or more first pixel states 125, AU 114 compares the depth value of the pixel indicated in the per-tile pixel depth data 245 with one or more predetermined thresholds. Based on the comparison of the pixel's depth value with the predetermined thresholds indicating that the pixel is at least partially occluded (e.g., at least a portion of the pixel is not visible in the scene), AU 114 then culles the pixel such that the per-tile pixel attribute data 235 and the per-tile pixel depth data 245 associated with the pixel are not stored in the PPC buffer 234 and Z buffer 236, respectively.

[0037] After AU 114 has executed tile 0 rendering phase 310, in some embodiments, the example tile-based real-time rendering graphics pipeline 300 includes AU 114 executing a release command 315 based on one or more commands indicated in the command stream. During release command 315, AU 114 releases per-tile pixel attribute data 235 associated with the first tile in PPC buffer 234, enabling AU 114 to execute a lighting phase for the first tile (e.g., tile 0 lighting phase 335). For example, AU 114 refreshes one or more PPC buffers 234 to release the per-tile pixel attribute data 235 associated with the first tile. Concurrently with AU 114 executing release command 315, the example tile-based real-time rendering graphics pipeline 300 includes AU 114 executing tile 1 rendering phase 320 based on one or more first pixel states. During tile 1 rendering phase 320, AU 114 renders at least partially visible primitives in the second tile of the frame to PPC buffer 234 based on per-tile geometry data 105 stored in per-tile queue 228 associated with the second tile. For example, see reference... Figure 3 In the implementation presented, AU 114 renders primitives at least partially visible in the second tile based on per-tile geometry data 1 105-2 from per-tile queues 1 228-2. According to the implementation, during the tile 1 rendering phase 320, AU 114 renders the primitives indicated in the per-tile geometry data 1 105-2 to generate per-tile pixel attribute data 235 associated with the second tile stored in one or more PPC buffers 234 and per-tile pixel depth data 245 associated with the second tile stored in a Z buffer 236. In some implementations, the tile 1 rendering phase 320 further includes, based on one or more first pixel states 125, AU 114 performing one or more clipping operations, performing depth culling operations, or both, based on the size of the tile. Once AU 114 has executed Tile 1 drawing phase 320, the example tile-based real-time rendering graphics pipeline 300 includes AU 114 executing release command 325 based on one or more commands in the command stream (e.g., based on one or more commands from application 108). During release command 325, AU 114 releases per-tile pixel attribute data 235 associated with the second tile in PPC buffer 234, enabling AU 114 to execute a lighting phase for the second tile (e.g., Tile 1 lighting phase 360).

[0038] Following release command 325, the example tile-based real-time mode rendering graphics pipeline 300 includes AU 114 executing acquire command 330 based on one or more commands from the command stream. During acquire command 330, AU 114 acquires (e.g., based on release command 315) per-tile pixel attribute data 235 associated with the first tile, released from PPC buffer 234. In response to AU 114 acquiring the per-tile pixel attribute data 235 associated with the first tile, AU 114 then executes tile 0 lighting phase 335 based on one or more second pixel states 125. During tile 0 lighting phase 335, AU 114 determines lighting values ​​(e.g., intensity values) based on the per-tile pixel attribute data 235 associated with the first tile, representing direct and indirect lighting for each pixel of a primitive that is at least partially visible in the first tile within the batch of primitives. For example, based on the per-patch pixel attribute data 235 associated with the first patch, AU 114 performs one or more shading operations (e.g., fragment shading operations), lighting operations, or both, according to one or more second pixel states 125 to determine the lighting value of each pixel of the primitives forming the batch that are at least partially visible in the first patch. AU 114 then stores the pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of the primitives forming the batch that are at least partially visible in the first patch in a frame buffer. Additionally, after AU 114 performs the patch 0 lighting phase 335, according to some embodiments, the example patch-based real-time mode rendering graphics pipeline 300 includes AU 114 performing a discard command 340 based on one or more commands in a command stream. The discard command 340 includes, for example, AU 114 discarding the per-patch pixel attribute data 235 associated with the first patch. For example, AU 114 removes per-tile pixel attribute data 235 associated with the first tile from one or more PPC buffers 234 in order to create a free entry in the PPC buffer 234.

[0039] Following the discard command 340, the example tile-based real-time mode rendering graphics pipeline 300 includes AU 114 performing a tile 2 drawing phase 345 based on one or more first pixel states 125. During the tile 2 drawing phase 345, AU 114 renders primitives from the batch that are at least partially visible in a third tile of the frame to a PPC buffer 234. For example, AU 114 renders the primitives indicated in per-tile geometry data 2 105-3 to produce per-tile pixel attribute data 235 associated with the third tile stored in one or more PPC buffers 234 and per-tile pixel depth data 245 associated with the third tile stored in a Z buffer 236. According to some embodiments, the tile 2 drawing phase 345 also includes AU 114 performing one or more clipping operations, performing depth culling operations, or both, based on the size of the tile, as indicated by one or more first pixel states 125. In the implementation, once AU 114 has executed the tile 2 drawing phase 345, the example tile-based real-time mode rendering graphics pipeline 300 includes AU 114 then executing a release command 350 based on one or more commands in the command stream. During the release command 350, AU 114 releases the per-tile pixel attribute data 235 associated with the third tile in the PPC buffer 234, enabling AU 114 to execute a lighting phase for the third tile (e.g., tile 2 lighting phase 375).

[0040] Within the example tile-based real-time rendering graphics pipeline 300, after the release command 350, AU 114 executes the acquire command 355 based on one or more commands in the command stream. During this process, AU 114 acquires (e.g., based on the release command 325) the per-tile pixel attribute data 235 associated with the second tile, released from the PPC buffer 234. In response to AU 114 acquiring the per-tile pixel attribute data 235 associated with the second tile, AU 114 then executes the tile 1 lighting phase 360 ​​based on one or more second pixel states 125. To perform the tile 1 lighting phase 360, AU 114 performs one or more shading operations (e.g., fragment shading operations), lighting operations, or both, as indicated in one or more second pixel states 125, based on the released per-tile pixel attribute data 235 associated with the second tile, to determine lighting values ​​(e.g., intensity values) representing direct and indirect lighting for each pixel of a primitive that is at least partially visible in the second tile within the batch of primitives. AU 114 then stores the pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of a primitive that is at least partially visible in the second tile within the batch of primitives in a frame buffer. Furthermore, after AU 114 performs the tile 1 lighting phase 360, the example tile-based real-time mode rendering graphics pipeline 300 includes AU 114 performing a discard command 365 based on one or more commands in a command stream, during which AU 114 discards the per-tile pixel attribute data 235 associated with the second tile from the PPC buffer 234.

[0041] Following the release command 365, AU 114 executes the acquire command 370 based on one or more commands in the command stream, during which AU 114 acquires (e.g., based on the release command 350) the per-tile pixel attribute data 235 associated with the third tile, released from the PPC buffer 234. Once AU 114 has acquired the per-tile pixel attribute data 235 associated with the third tile, AU 114 executes the tile 2 lighting phase 375 based on one or more second pixel states 125. To this end, AU 114 performs one or more shading operations (e.g., fragment shading operations), lighting operations, or both, based on the released per-tile pixel attribute data 235 associated with the third tile to determine lighting values ​​(e.g., intensity values) representing direct and indirect lighting for each pixel of a primitive formed in at least partially visible in the third tile. AU 114 then stores the pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of a primitive formed in the batch of primitives that is at least partially visible in the third tile in the frame buffer. Additionally, after AU 114 executes the tile 1 lighting phase 360, the example tile-based real-time mode rendering graphics pipeline includes AU 114 executing a discard command 380 based on one or more commands in the command stream, during which AU 114 discards per-tile pixel attribute data 235 associated with the third tile from the PPC buffer 234. Although Figure 3 The example tile-based real-time mode rendering graphics pipeline 300 presented in the example shows AU 114 performing corresponding tile drawing phases (310, 320, 345) and tile lighting phases (335, 360, 375) for three tiles per frame. However, in other embodiments, the example tile-based real-time mode rendering graphics pipeline 300 includes AU 114 performing corresponding tile drawing phases and tile lighting phases for any number of tiles per frame.

[0042] According to the implementation scheme, concurrently with executing one or more tile drawing phases (e.g., 310, 320, 345), tile lighting phases (e.g., 335, 360, 375), or both for each tile of the frame to render the primitives in the first batch, AU 114 continues the visibility traversal of the geometry phase 305 until a command (e.g., a tile refresh command) is received from the command stream, one or more per-tile queues 228 are at a predetermined capacity threshold (e.g., storing a predetermined amount of data), or both, thus forming a second batch of primitives to be rendered. AU 114 then renders the second batch of primitives by again executing the tile drawing phase and tile lighting phase for each tile using the per-tile geometry data 105 in the per-tile queue 228 associated with the second batch of primitives. AU 114 then continues in this manner until all primitives associated with the frame have been rendered.

[0043] Now for reference Figure 4 According to some implementations, example operation 400 for managing the geometry and pixel states of a tile-based real-time rendering graphics pipeline is presented. In one implementation, example operation 400 is performed by AU 114 while implementing a tile-based real-time rendering graphics pipeline 124. According to one implementation, example operation 400 first includes command processor 232 receiving a command stream from, for example, CPU 102, which indicates one or more geometry states 115 and one or more pixel states 125 (e.g., a first pixel state, a second pixel state) of a scene to be rendered in a frame. Based on the received command stream, command processor 232 provides data indicating geometry states 115 to geometry state management circuitry 434. For example, such geometry state management circuitry 434 is configured to store data indicating geometry states 115 in one or more queues. For example, geometry state management circuitry 434 stores data indicating geometry states 115 in the received command stream in one or more FIFO queues. The geometry state management circuit 434 then passes the stored data indicating geometry state 115 to the geometry circuit 226 to initiate and execute one or more stages (e.g., command groups) of the tile-based real-time rendering graphics pipeline 124. For example, the geometry state management circuit 434 passes data indicating one or more first geometry states 115 to the geometry circuit 226 to cause the geometry circuit 226 to initialize tile-based real-time rendering. As another example, the geometry state management circuit 434 passes data indicating one or more second geometry states 115 to the geometry circuit 226 to cause the geometry circuit 226 to execute a geometry stage (e.g., geometry stage 305) that includes visibility traversal. When the geometry circuit 226 executes such a geometry stage, the geometry circuit 226 stores the geometry data for each tile (e.g., per-tile geometry data 105) in a corresponding per-tile queue 228 assigned to the tile.

[0044] In some implementations, after geometry circuitry 226 has completed one or more tasks (e.g., visibility traversal task, geometry shading task) of a geometry phase (e.g., a geometry phase caused by geometry state management circuitry 434), geometry circuitry 226 indicates to geometry state management circuitry 434 that one or more tasks have been completed. Geometry state management circuitry 434 then issues one or more subsequent geometry states 115 to cause geometry circuitry 226 to execute the next task of the geometry phase. In some implementations, each processor core 116 of AU 114 includes or is otherwise connected to a corresponding instance of geometry state management circuitry 434.

[0045] Additionally, in an embodiment, based on the received command stream, example operation 400 includes command processor 232 providing data indicating pixel state 125 to one or more pixel command replay queues 436. Such pixel command replay queues 436 may include, for example, one or more FIFO queues formed by at least a portion of cache 122, memory 106, or both. According to an embodiment, such pixel command replay queues 436 are configured to provide pixel states 125 stored in pixel command replay queues 436 to pixel state management circuitry 438 in the order they are received by pixel command replay queues 436. Based on the pixel states 125 received from pixel command replay queues 436, pixel state management circuitry 438 is configured to cause pixel circuitry 230 to initiate and execute tile drawing phases (e.g., tile drawing phases 310, 320, 345) and tile lighting phases (e.g., tile lighting phases 335, 360, 375) of a tile-based real-time mode rendering graphics pipeline 124.

[0046] As an example, pixel state management circuit 438 passes one or more first pixel states 125 from pixel command replay queue 436 to pixel circuit 230 to cause pixel circuit 230 to perform a tile drawing phase for the first tile of the frame. Based on the first pixel states 125, pixel circuit 230 then performs the tile drawing phase to generate per-tile pixel attribute data 235 for the first tile stored in PPC buffer 234. Once pixel circuit 220 has completed the tile drawing phase, pixel circuit 220 transmits data indicating that the tile drawing phase is complete to pixel state management circuit 438. Pixel state management circuit 438 then provides the corresponding pixel state 125 from pixel command replay queue 436 to pixel circuit 220 to cause pixel circuit 220 to perform subsequent phases of the tile-based real-time rendering graphics pipeline 124 (e.g., tile lighting state, tile drawing phase). Additionally, in some embodiments, the pixel state management circuit 438 is configured to compare a pixel state 125 to be emitted by the pixel state management circuit 438 with the current pixel state 125 received by the pixel circuit 220. That is, it is configured to compare the pixel state 125 to be emitted with the most recently emitted pixel state 125. Based on the comparison indicating that the pixel state 125 to be emitted is the same as the most recently emitted pixel state 125, the pixel state management circuit 438 filters out the pixel state 125 to be emitted and does not provide that pixel state to the pixel circuit 220. In some embodiments, each processor core 116 of the AU114 includes or is otherwise connected to a corresponding instance of the pixel command replay queue 436, the pixel state management circuit 438, or any combination thereof.

[0047] Now for reference Figure 5This paper presents an example method 500 for performing a tile-based real-time rendering graphics pipeline according to an embodiment. In the embodiment, the example method 500 is implemented by at least a portion of AU 114 (e.g., one or more processor cores 116 of AU 114). In the embodiment, the example method 500 first includes, at block 505, AU 114 receiving a command stream from CPU 102 indicating one or more geometric states 115 and one or more pixel states 125. Based on the received command stream, AU 114 divides a frame to be rendered into two or more tiles. For example, each tile includes a first number of pixels in a first direction and a second number of pixels in a second direction. Furthermore, at block 505, AU 114 assigns a corresponding per-tile queue 228 to each tile of the frame. At block 510, the example method 500 includes AU 114 determining per-tile geometry data 105 of the primitives in the first batch of primitives to be rendered in the frame. To this end, AU 114 performs one or more assembly operations, shading operations (e.g., geometry shading operations), or both, based on the geometry state 115 indicated in the command stream to produce one or more assembled primitives. For each assembled primitive, AU 114 then performs a visibility traversal to determine in which tiles the assembled primitive is at least partially visible. Based on the fact that the primitive is at least partially within the corresponding tile, AU 114 stores geometric data (e.g., per-tile geometry data 105) indicating the vertex data, shading data, positioning data, or any combination thereof associated with the primitive in the tile in a per-tile queue 228 allocated to the tile.

[0048] Based on AU 114 determining whether each primitive in a batch is at least partially visible in each tile of the frame, at box 515, AU 114 begins rendering the batch of primitives by performing a tile rendering phase for the first tile of the frame (e.g., tile 0 rendering phase 310). To do this, AU 114 renders primitives in the batch that are at least partially visible in the first tile to PPC buffer 234 based on per-tile geometry data 105 stored in per-tile queue 228 associated with the first tile. That is, AU 114 assembles, rasterizes, and shades the primitives indicated in the per-tile geometry data 105 associated with the first tile in the batch of primitives to produce per-tile pixel attribute data 235 associated with the first tile stored in one or more PPC buffers 234 and per-tile pixel depth data 245 associated with the first tile stored in Z buffer 236. In some implementations, at block 515, the tile drawing phase also includes AU 114 performing one or more clipping operations, depth culling operations, or both. Additionally, at block 515, in some implementations, after AU 114 has written the per-tile pixel attribute data 235 associated with the first frame stored in PPC buffer 234, AU 114 releases the per-tile pixel attribute data 235 associated with the first tile from PPC buffer 234 based on one or more commands from application 108, so that AU 114 can perform subsequent tile lighting phases for the first tile.

[0049] At box 520, AU 114 performs a tile rendering phase for the second tile of the frame (e.g., tile 1 rendering phase 320). To do this, AU 114 renders at least partially visible primitives in the second tile from the batch of primitives to PPC buffer 234 based on per-tile geometry data 105 stored in per-tile queue 228 associated with the second tile. As an example, AU 114 assembles, rasterizes, and shades the primitives indicated in the per-tile geometry data 105 associated with the second tile to produce per-tile pixel attribute data 235 associated with the second tile stored in one or more PPC buffers 234 and per-tile pixel depth data 245 associated with the first frame stored in Z buffer 236. In some embodiments, at box 520, the tile rendering phase also includes AU 114 performing one or more clipping operations, depth culling operations, or both. After AU 114 has written the per-tile pixel attribute data 235 associated with the second tile to the PPC buffer 234, AU 114 releases the per-tile pixel attribute data 235 associated with the second tile from the PPC buffer 234 based on one or more commands from application 108, so that AU 114 can perform subsequent tile lighting stages for the second tile.

[0050] At box 525, AU 114 is configured to perform a tile lighting phase (e.g., tile 0 lighting phase 335) for the first tile of the frame. During the tile lighting phase, at box 525, AU 114 determines lighting values ​​(e.g., intensity values) based on released per-tile pixel attribute data 235 associated with the first tile, representing direct and indirect lighting for each pixel of a primitive that is at least partially visible in the first tile within the batch of primitives. As an example, based on the per-tile pixel attribute data 235 associated with the first tile, AU 114 performs one or more shading operations (e.g., fragment shading operations), lighting operations, or both, to determine the lighting value for each pixel of a primitive that is at least partially visible in the first tile. AU 114 then stores the pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of a primitive that is at least partially visible in the first tile within the batch of primitives in the frame buffer. After completing the tile lighting phase based on AU 114, at box 530, AU 114 then discards the per-tile pixel attribute data 235 associated with the first tile from PPC buffer 234. After discarding the per-tile pixel attribute data 235 associated with the first tile, at box 535, AU 114 then performs a tile lighting phase for the second tile of the frame (e.g., tile 1 lighting phase 360). During the tile lighting phase, at box 535, AU 114 determines lighting values ​​(e.g., intensity values) based on the per-tile pixel attribute data 235 associated with the second tile, which represent direct and indirect lighting for each pixel of the primitives forming the batch of primitives that are at least partially visible in the second tile. AU 114 then stores pixel values ​​representing the color and lighting (e.g., intensity) of each pixel of the primitives forming the primitives that are at least partially visible in the second tile in the frame buffer.

[0051] In some implementations, the apparatus and techniques described above include one or more integrated circuit (IC) devices (also known as integrated circuit packages or microchips) (such as those referenced above). Figures 1 to 5The system described herein is implemented. Electronic Design Automation (EDA) and Computer-Aided Design (CAD) software tools can be used in the design and manufacture of these IC devices. These design tools are typically represented as one or more software programs. One or more software programs include code executable by a computer system to manipulate the computer system to operate on code representing one or more IC devices to perform at least a portion of the process for designing or adapting a manufacturing system to manufacture the circuit. The code may include instructions, data, or a combination of instructions and data. Software instructions representing design tools or manufacturing tools are typically stored in a computer-readable storage medium accessible to the computing system. Similarly, code representing one or more stages of the design or manufacture of the IC device may be stored in and accessed from the same computer-readable storage medium or different computer-readable storage media.

[0052] Computer-readable storage media may include any non-transitory storage medium or a combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., optical discs (CDs), digital versatile optical discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS) based storage media. Computer-readable storage media may be embedded in a computing system (e.g., system RAM or ROM), permanently attached to a computing system (e.g., a magnetic hard disk drive), removably attached to a computing system (e.g., an optical disc or a flash memory based on a universal serial bus (USB)), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0053] In some implementations, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing the software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, disk or optical disc storage devices, solid-state storage devices such as flash memory, cache, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executed by one or more processors.

[0054] It should be noted that not all activities or elements described above in the general description are essential. A particular activity or part of the apparatus may not be essential, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Additionally, these concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of this disclosure as set forth in the following claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0055] The benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that may lead to or make any benefit, advantage, or solution appear or become more significant should not be construed as key, essential, or fundamental features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that will be apparent to those skilled in the art who benefit from the teachings herein. No limitation is intended on the details of the constructions or designs shown herein, except as described in the following claims. Therefore, it will be apparent that the specific embodiments disclosed above can be changed or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the following claims.

Claims

1. A method, the method comprising: Divide the frame to be rendered into multiple tiles; For the first of the plurality of tiles, the pixel attribute data of the primitives that are at least partially visible in the first tile are written to one or more caches; as well as Illumination data of the primitives at least partially visible in the first tile are determined based on the pixel attribute data of the primitives stored in the one or more caches.

2. The method according to claim 1, further comprising: Release the pixel attribute data of the primitive that is at least partially visible in the first tile, stored in the one or more caches; as well as Concurrently with releasing the pixel attribute data of the primitives that are at least partially visible in the first tile and stored in the one or more caches, the pixel attribute data of the primitives that are at least partially visible in the second tile of the plurality of tiles are written to the one or more caches.

3. The method according to claim 2, further comprising: Illumination data of the primitives at least partially visible in the second tile are determined based on the pixel attribute data of the primitives stored in the one or more caches.

4. The method according to any one of claims 1 to 3, further comprising: Based on the lighting data of the primitives that are at least partially visible in the first tile, the pixel attribute data of the primitives that are at least partially visible in the first tile are discarded.

5. The method according to any one of claims 1 to 4, further comprising: A visibility traversal is performed to determine which primitives in a batch are at least partially visible in each of the plurality of tiles.

6. The method according to claim 5, further comprising: The batch of primitives is formed when the queues allocated to the corresponding primitives in the plurality of primitives reach a capacity threshold.

7. The method of claim 5 or 6, wherein the visibility traversal comprises, for each of the plurality of tiles, writing geometric data of one or more tiles in the batch that are at least partially visible in the tile to a queue allocated to the tile.

8. An acceleration unit (AU), the acceleration unit (AU) comprising: One or more caches; and One or more processor cores, said one or more processor cores being coupled to said one or more caches and configured to perform the method according to any one of claims 1 to 7.

9. An acceleration unit (AU), the acceleration unit (AU) comprising: Multiple per-tile queues, each of which is assigned to a tile in a plurality of tiles of a frame to be rendered; and One or more processor cores, wherein the one or more processor cores are configured to: For each of the plurality of tiles: The geometric data of one or more primitives of the frame to be rendered, which are at least partially visible in the tile, are written into the per-tile queue of the plurality of per-tile queues assigned to the tile; as well as Based on the geometric data of the one or more primitives that are at least partially visible in the tile, stored in the per-tile queue allocated to the tile, the pixel attribute data of the one or more primitives that are at least partially visible in the tile are rendered to one or more per-pixel color buffers (PPC buffers).

10. The AU of claim 9, wherein the one or more processor cores are configured to: For each of the plurality of tiles, illumination data of the one or more tiles that are at least partially visible in the tile are determined based on the pixel attribute data of the one or more tiles that are at least partially visible in the tile.

11. The AU of claim 9 or 10, wherein the one or more processor cores are configured to: Release pixel attribute data of one or more primitives that are at least partially visible in the first tile of the plurality of tiles from the PPC buffer; and Concurrently with the release of pixel attribute data of the one or more primitives that are at least partially visible in the first tile from the PPC buffer, pixel attribute data of the one or more primitives that are at least partially visible in the second tile of the plurality of tiles are rendered to the PPC buffer.

12. The AU of claim 11, wherein the one or more processor cores are configured to: Illumination data of the pixels of the one or more primitives that are at least partially visible in the first block of the plurality of blocks are determined based on the pixel attribute data of the one or more primitives that are at least partially visible in the first block of the plurality of blocks.

13. The AU according to any one of claims 9 to 12, wherein the one or more processor cores are configured to: For each of the plurality of tiles, a clipping operation is performed on the pixels of the one or more primitives that are at least partially visible in the tile.

14. The AU of claim 13, wherein the one or more processor cores are configured to: For each of the plurality of tiles, a depth culling operation is performed on the pixels of the one or more primitives that are at least partially visible in the tile.

Images