Local shader engine geometry and attribute shading

Abstract

Systems and techniques are provided for deferred attribute shading operations in a graphics pipeline (124). A set of primitives is received by one or more shader engines (300, 350) of a processing core (316) for rendering at least a portion of a scene. The shader engines cull the received set of primitives by identifying a subset of primitives that can be visible in the scene; generate intermediate data for the identified subset of primitives; generate attribute data values (235) based on the intermediate data for the identified subset of primitives; and rasterize the identified subset of primitives for rendering based on the generated attribute data values.

Description

Background Technology

[0001] In graphics processing systems, three-dimensional (3D) scenes are typically rendered by graphics processing units (GPUs) for display on a two-dimensional monitor. To render such a scene, the GPU receives a stream of commands from the application instructing various graphical primitives to be rendered (also referred to as primitives in this document for simplicity). The GPU then renders these primitives according to a graphics pipeline with various stages, each containing instructions to be executed by the GPU. The GPU typically computes visibility information for all primitives in a visibility traversal; in some scenes, the GPU then splits the output of the visibility traversal into tiles or other screen-space partitions. Based on the visibility data, the GPU generates and compresses data for the primitives later used to render the scene. In this way, the GPU renders the visible primitives based on the compressed data. The graphics processing system then displays the rendered primitives as part of the three-dimensional scene displayed on the two-dimensional monitor.

[0002] Traditional rendering techniques often struggle to meet the computational and memory bandwidth demands of modern applications for the efficient processing, storage, and manipulation of geometric and attribute data—all of which relate to the visual complexity and realism expected in generating modern graphics content. The management of geometry (such as vertices and primitives) and its associated attributes (such as color, texture coordinates, and normals) is a significant bottleneck. Summary of the Invention

[0003] The implementation described herein includes an acceleration unit (AU) configured to utilize deferred attribute shading to implement a graphics pipeline. The AU's attribute shader performs attribute data computation only after initial culling of primitives irrelevant to the scene being rendered. In a first embodiment, a method includes: receiving, by one or more shader engines, a set of primitives for rendering at least a portion of the scene; and culling the set of primitives by the one or more shader engines, wherein the culled primitive set includes identifying a subset of primitives that may be visible in the scene. The method further includes: generating attribute data values ​​for the identified subset of primitives by the one or more shader engines; and rasterizing the identified subset of primitives based on the generated attribute data values ​​for rendering by the one or more shader engines.

[0004] In some implementations, the method further includes generating intermediate data for the identified subset of primitives by one or more shader engines, and wherein the method is performed without providing intermediate data or attribute data values ​​outside of one or more shader engines. Generating intermediate data for the identified subset of primitives may include generating intermediate geometry data for the identified subset, and rasterizing the identified subset of primitives includes rasterizing the identified subset based on the intermediate geometry data.

[0005] In some specific implementations, generating intermediate data for the identified subset of primitives includes generating assembled primitive data for the identified subset of primitives, and generating attribute data values ​​includes generating attribute data values ​​based on the assembled primitive data.

[0006] The subset of primitives identified by rasterization may include generating a rasterized subset of primitives, and the method may also include rendering the scene by generating pixel data based on the rasterized subset of primitives. In some specific implementations, the method further includes splitting the scene into multiple tiles, wherein a set of primitives corresponds to all primitives associated with one of the multiple tiles.

[0007] Receiving a primitive set may include receiving one or more of the following: geometric data associated with the primitive set, geometric state data associated with the scene, or pixel state data. This method may be executed by a processor core that includes one or more shader engines.

[0008] In another specific implementation, an acceleration unit includes one or more caches and one or more shader engines coupled to the one or more caches. The one or more shader engines are configured to: receive a set of primitives for rendering at least a portion of a scene; cull the set of primitives to identify a subset of primitives that may be visible in the scene; generate attribute data values ​​for the identified subset of primitives; and rasterize the identified subset of primitives based on the generated attribute data values ​​for rendering.

[0009] The one or more shader engines may also be configured to: generate intermediate data for the identified primitive subset; and generate attribute data values ​​and rasterize the identified primitive subset without providing intermediate data or attribute data values ​​outside of the one or more shader engines.

[0010] In some implementations, the intermediate data of the identified primitive subset includes intermediate geometry data of the identified subset, and one or more shader engines are configured to rasterize the identified primitive subset based on the intermediate geometry data. The intermediate data of the identified primitive subset may include assembled primitive data of the identified primitive subset, and one or more shader engines may be configured to generate attribute data values ​​based on the assembled primitive data.

[0011] In some implementations, the subset of primitives identified by rasterization includes the generated rasterized primitive subset, and one or more shader engines can be configured to render the scene by generating pixel data based on the rasterized primitive subset. The scene can be divided into multiple tiles, and a primitive set can correspond to all primitives associated with one of the tiles. A primitive set can include one or more of the following: geometric data associated with the primitive set, geometric state data associated with the scene, or pixel state data.

[0012] In another specific embodiment, a non-transitory computer-readable medium embodies an executable instruction set for instructing at least one processor to perform the following operations: receiving a set of primitives for rendering at least a portion of a scene; identifying a subset of primitives that may be visible in the scene by a shader engine of the at least one processor; generating attribute data values ​​for the identified subset of primitives by the shader engine; and rasterizing the identified subset of primitives based on the generated attribute data values ​​by the shader engine for rendering.

[0013] In some implementations, the executable instruction set manipulates the shader engine to perform the following operations: generate intermediate data for the identified primitive subset; and generate attribute data values ​​and rasterize the identified primitive subset without providing the intermediate data or attribute data values ​​outside the shader engine.

[0014] The intermediate data of the identified primitive subset may include intermediate geometry data of the identified subset, and the shader engine may be configured to rasterize the identified primitive subset based on the intermediate geometry data.

[0015] The intermediate data of the identified primitive subset may include the assembled primitive data of the identified primitive subset, and the shader engine may be configured to generate attribute data values ​​based on the assembled primitive data.

[0016] In some implementations, the subset of primitives identified by rasterization includes generating a subset of rasterized primitives, and an executable instruction set manipulates at least one processor to render a scene by generating pixel data based on the subset of rasterized primitives. Attached Figure Description

[0017] This disclosure can be better understood by referring to the accompanying drawings, and its many 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.

[0018] Figure 1 It is a block diagram of a processing system configured to implement deferred attribute shading operations in a graphics pipeline, according to some implementation schemes.

[0019] Figure 2 It is a block diagram of a processor core configured to implement at least a portion of a graphics pipeline to perform deferred attribute shading operations, according to an implementation scheme.

[0020] Figure 3 This is a block diagram of an example processor core, according to the implementation scheme, including a shader engine configured to implement deferred attribute shading operations.

[0021] Figure 4A flowchart is drawn out of the operation routines of one or more shader engines that implement deferred attribute shading operations according to some implementation schemes. Detailed Implementation

[0022] In a typical graphics pipeline, the vertex shader serves as a single processing stage for computing vertex attributes such as their location, color, and texture coordinates. The vertex shader performs transformations on the vertex data to prepare those vertices for use in the next pipeline stage, typically including tasks such as transforming vertex locations to screen space, calculating lighting, and projecting textures onto geometry. The vertex shader operates on each vertex individually and outputs the modified vertex data to subsequent stages, which typically lead to primitive assembly and rasterization stages.

[0023] The systems and techniques disclosed herein relate to accelerated units (AUs) configured to utilize deferred attribute shading in a graphics pipeline. In some implementations, a primitive mesh shader handles initial processing of vertex data, including primitive assembly and vertex transformation; however, an attribute shader performs attribute data computation on a deferred basis (i.e., only after initial culling of primitives irrelevant to the scene being rendered (e.g., potentially not visible in the scene being rendered)). The primitive mesh shader processes primitive geometry by performing operations such as pulling vertices from the vertex buffer and mesh shading, generating intermediate data for high-level geometry processing but not resource-intensive attribute data. Instead, the attribute shader performs attribute computation on a deferred basis. This deferred computation allows for more efficient and targeted computation of vertex attributes because the attribute shader only processes the attributes of vertices of primitives determined to be visible in the scene.

[0024] Therefore, the deferred attribute shading technique described in this paper involves strategically postponing the computation of primitive attributes until a relatively late stage in the rendering process, such as after the initial geometry culling operation has identified those primitives that will contribute to the final rendered frame. By postponing attribute shading in this way, AU is able to prioritize the allocation of computational resources to those primitives that are only visible, thereby potentially improving the efficiency and speed of the rendering process by reducing unnecessary computation and memory bandwidth usage.

[0025] In some implementations, the AU utilizes one or more shader engines to perform initial culling of primitives that are irrelevant to the frame being rendered (e.g., not visible in the frame being rendered) to generate attribute and geometry data for subsequent processing, and performs subsequent attribute shading operations based on the culled and processed geometry data. The described technique reduces memory bandwidth usage by avoiding premature computation and storage of attribute data for primitives that may ultimately be culled from the final scene.

[0026] The deferred attribute shading operations described herein are applicable to various types of graphics pipelines, including but not limited to tile-based immediate rendering (TBIR) pipelines. Therefore, in some embodiments, the systems and techniques disclosed herein are implemented via a processing system including a TBIR graphics pipeline, such that the operation of the graphics pipeline involves first dividing a frame to be rendered into two or more tiles. Furthermore, the TBIR 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. While various examples are described herein in the context of tile-based graphics pipelines, it should be understood that in various embodiments, aspects of the rendering operations described herein (e.g., deferred attribute shading and related operations) can operate in a variety of other contexts, such as non-tile-based graphics pipelines. Additionally, some embodiments may utilize other non-tile-based methods within the graphics pipeline to partition screen space as part of the rendering process, such that individual screen space partitions may each include any subset of the screen space where the scene will be rendered.

[0027] To implement a TBIR rendering graphics pipeline, the processing system includes an acceleration unit (AU) configured to receive command streams from an application being executed by the processing system. Such command streams, for example, include 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 geometric states, one or more pixel states, and data indicating one or more primitives to be rendered in the frame (e.g., vertices). Such geometric states include data (e.g., parameters) for initializing and indicating tile-based instant rendering, geometric stages of the TBIR graphics pipeline, or both. Additionally, such pixel states include data (e.g., parameters) for initializing and indicating tile drawing, release, acquisition, tile lighting, and discarding stages of the tile-based instant rendering graphics pipeline. Based on the received command stream, the AU first divides the frame to be rendered into two or more tiles based on the geometric states indicated in the command stream. Furthermore, the AU assigns a corresponding per-tile queue to each tile in the frame. The AU then executes the geometric stages of the pipeline based on a second geometric state. During this geometric phase, the AU determines, for each tile in a group (e.g., batch) of tiles in a frame, which primitives of the frame are at least partially visible in the tiles. Based on the fact that primitives are at least partially visible in the tiles, the AU stores geometric data indicating the vertex data, shading data, positioning data, or any combination thereof of the primitives in a per-tile queue assigned to the tiles.

[0028] After the AU has determined whether each primitive of a frame is at least partially visible in the first tile of a tile group, the AU initiates a tile rendering phase for the first tile in the TBIR graphics pipeline based on a first pixel state from the command stream. During the tile rendering phase for the first tile, the AU renders the primitives at least partially visible in the first tile to a geometry buffer (G buffer) based on the geometry data stored in each tile queue allocated to the first tile. That is, based on the geometry data stored in each tile queue allocated to the first tile, the AU determines pixel attribute data indicating the location and color of the pixels that indicate the primitives at least partially visible in the first tile. After such pixel attribute data associated with the first tile is written to the G buffer, the AU performs a tile lighting phase for the first tile in the TBIR graphics pipeline based on a second pixel state from the command stream. 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 G buffer. The AU then stores the location, color, and lighting of each pixel representing at least partially visible primitives in the first tile into a frame buffer for display. Based on the subsequent pixel states from the command stream, the AU then performs a tile drawing phase and a tile lighting phase for the remaining tiles in the tile group.

[0029] In this way, the processing system implements the TBIR graphics pipeline. Because 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 G 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 of the graphics pipeline for the first tile, the AU is configured to release the pixel attribute data associated with that first tile from the G buffer. When the pixel attribute data associated with the first tile is released from the G buffer, the AU is configured to perform the tile drawing phase for the second tile of the tile group based on the corresponding pixel state of the command stream. In this way, the AU does not need to wait for the pixel attribute data to be released before executing the next stage of the TBIR pipeline, thus reducing the amount of time required to execute stages of the TBIR pipeline.

[0030] 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 a central processing unit (CPU) 102, which is communicatively coupled to memory 106 via a bus 112. In embodiments, memory 106 includes storage components implemented using non-transitory computer-readable media such as dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile RAM, etc. In some specific embodiments, memory 106 includes external memory implemented outside the processing unit implemented in the processing system 100. Bus 112 supports communication between entities implemented in the processing system 100, including CPU 102 and 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.

[0031] In various specific implementations, the techniques described herein are employed at acceleration unit (AU) 114. AU 114 includes, for example, one or more vector processors, coprocessors, graphics processing units (GPUs), general-purpose GPUs (GPGPUs), nonscalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multithreaded processing units, scalar processors, serial processors, programmable logic devices (e.g., field-programmable gate arrays), or any combination thereof. In various implementations, AU 114 renders a scene within screen space (e.g., the space for displaying a scene) based on one or more applications 108 executed in memory 106 for presentation on display 120 communicatively coupled to bus 112 via input / output (I / O) engine 118. For example, AU 114 renders graphical objects (e.g., primitive sets) of the scene in the screen space (e.g., 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 graphics 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. A 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, a graphics pipeline includes data instructing one or more processor cores 116 of AU 114 to execute 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 to render one or more graphics objects for a scene.

[0032] 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. These compute units each include 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., TBIR graphics pipeline 124). To facilitate the execution of operations by one or more compute units against 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.

[0033] According to embodiments, 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 include one or more caches included in or otherwise connected to the processor core 116. As an example, in embodiments, caches 122 include one or more caches shared among two or more processor cores 116 (e.g., shared caches), one or more caches private to a single corresponding processor core 116 (e.g., accessible only by that single corresponding processor core) (e.g., private caches), or both. For example, according to some embodiments, caches 122 include a cache hierarchy that includes one or more private caches, one or more shared caches, or both.

[0034] In one implementation, AU 114 is configured to render one or more graphics objects according to a tile-based real-time rendering (TBIR) graphics pipeline 124. For example, the graphics pipeline 124 includes a real-time rendering mode in which application 108 issues a command stream comprising data describing all graphics objects (e.g., primitives) in the scene to be rendered for each frame to be rendered. In the depicted implementation, the command stream includes data indicating the location of vertices of one or more primitives to be rendered, 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 tile-based real-time rendering, geometric stages of the TBIR graphics pipeline 124, or both. As an example, geometric states 115 indicate parameters, procedures, and data used when initializing or executing tile-based real-time rendering or geometric stages of the TBIR graphics pipeline 124. Additionally, such pixel states 125 include data (e.g., parameters) for initializing and indicating the tile drawing, release, acquisition, tile lighting, and discarding phases of the TBIR graphics pipeline 124. For example, pixel states 125 indicate the parameters, procedures, and data used in the tile drawing, release, acquisition, tile lighting, and discarding phases of the TBIR graphics pipeline 124. In an embodiment, AU 114 is configured to store the geometry states 115 and pixel states 125 indicated in the command stream in one or more caches 122, memories 106, or both.

[0035] In various implementations, per-tile geometry data 105, geometry state 115, and pixel state 125 facilitate or are influenced by the deferred processing of attribute data, particularly when optimizing rendering based on the visibility and relevance of individual primitives. For example, per-tile geometry data 105, including information about those primitives that are at least partially visible within each tile, facilitates identification (see also...). Figure 3 (Discussed elsewhere in this paper) Which primitives are associated with such deferred attribute shading operations, thus enabling attribute shading operations to be performed only on the associated primitives. The deferred processing method uses per-tile geometry data 105 to postpone attribute calculations until it is confirmed that these primitives contribute to the final rendered image. Geometry state 115 defines how the geometry of each tile is processed (enabling AU 114 to identify and prioritize primitive rendering based on their visibility and relevance), and includes parameters and instructions for the initial stages of rendering (including culling and preparation of primitives for attribute shading). Pixel state 125 further refines the rendering process by specifying how pixels within each tile are drawn and shading based on the deferred attribute data. These states include instructions for the final stages of rendering, including tile drawing stages and lighting calculations, which are directly affected by the attribute data generated during the deferred shading operations.

[0036] According to an implementation, the TBIR 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 a first geometry state 115 in a received command stream, AU 114 first divides the frame to be rendered into two or more tiles (e.g., coarse tiles). Each tile includes, for example, 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 the first geometry state 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.

[0037] After dividing the frame to be rendered into two or more tiles, AU 114 then assigns multiple queues, formed by at least a portion of cache 122, memory 106, or both, to each tile in the tile group (e.g., batch) of the frame, such that each tile in the tile group has a corresponding per-tile queue. As an example, AU 114 divides and assigns one or more per-shader engine queues, formed by portions of cache 122, such that each tile in the tile group is assigned a per-tile queue. Each per-tile queue, for example, includes one or more queues formed by at least a portion of cache 122, memory 106, or both. After AU 114 has assigned per-tile queues to each tile in the tile group, AU 114 begins the geometry phase of the TBIR graphics pipeline 124 based on the second geometry state 115 of the command flow.

[0038] This geometric phase includes, for example, a visibility traversal, in which AU 114 determines which primitives (e.g., graphic objects) to render for each tile in the tile group. 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) the indicated primitives. For each tile in the tile group, AU 114 then determines whether each assembled primitive in the assembled primitives is at least partially visible (e.g., associated). Based on AU 114's determination that the assembled primitives are at least partially visible in the tile, AU 114 provides geometric data indicating the primitives' vertex data, shader data, positioning data, or any combination thereof to the per-tile queue associated with the tile. Once AU 114 has determined whether each primitive indicated in the command stream from application 108 is visible in the tile, the per-tile queue assigned to the tile stores per-tile geometry data 105, which represents vertex data, shading data, positioning data, or any combination thereof of primitives that are at least partially visible within the tile.

[0039] Once AU 114 has determined whether each assembled primitive is visible in the first tile of the frame to be rendered, AU 114 begins the first tile drawing phase of the first tile based on the first pixel state 125 indicated in the command stream. As an example, after AU 114 has determined whether each assembled primitive is visible in the first tile of the tile group, and while AU 114 is simultaneously executing the remainder of the geometry phase, AU 114 begins the first tile drawing phase of the first tile based on the first pixel state 125. To perform this tile drawing phase, AU 114 is configured to first render primitives that are at least partially visible in the first tile as a batch (e.g., a coarse batch) to a G-buffer formed by at least a portion of cache 122, memory 106, or both. For this purpose, AU 114 is configured to render 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 a per-tile queue associated with a first tile of per-tile geometry data 105, which represents primitives that are at least partially visible in the first tile. Based on a first pixel state 125, AU 114 then uses the per-tile geometry data 105 to assemble, rasterize, and colorize the primitives to generate per-tile pixel attribute data stored in a G buffer and per-tile 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-tile pixel attribute data represents the attributes (e.g., color, positioning) of pixels forming primitives that are at least partially visible in the tile, and such per-tile pixel depth data represents the depth of pixels forming primitives that are at least partially visible in the tile.

[0040] 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 a first pixel state 125. For example, for each pixel forming a primitive 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, G-buffer, or both by, for example, not storing the pixel attribute data or pixel depth data in the G-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.

[0041] After AU 114 has completed the tile drawing phase for the first tile and based on the second pixel state 125, AU 114 releases the per-tile pixel attribute data in the G buffer and uses the released per-tile pixel attribute data to perform a tile lighting phase. For example, during the tile lighting phase, AU 114 performs one or more pixel shading operations as indicated in the second pixel state 125 to determine lighting values ​​(e.g., intensity values) using the per-tile pixel attribute data in the G buffer, which represent direct and indirect lighting for each pixel of at least partially visible primitives formed in the tile. AU 114 then stores 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 formed by cache 122, memory 106, or at least a portion of both. Furthermore, once AU 114 has determined the illumination value for each pixel of a primitive formed in a tile that is at least partially visible, AU 114 discards the per-tile pixel attribute data associated with the tile stored in the G buffer. In an implementation, when AU 114 releases the per-tile pixel attribute data in the G buffer to perform a tile illumination phase for a first tile, AU 114 is configured to perform a tile drawing phase for a second tile of the frame, a tile illumination phase for a second tile of the frame, or both. As an example, when the per-tile pixel attribute data in the G buffer is released to perform a tile illumination phase for a first tile, AU 114 performs a tile drawing phase for a second tile, stores the per-tile pixel attribute data of the primitives in the second tile in the G buffer, and releases the per-tile pixel attribute data of the primitives in the second tile from the G buffer to perform a illumination phase for the second tile. Furthermore, as an example, as AU 114 releases the per-patch pixel attribute data of primitives in the second patch from the G buffer, AU 114 performs a lighting phase for the first patch and a drawing phase for the third patch. Because AU 114 performs these phases as the per-patch pixel attribute data is released from the G buffer, AU 114 does not need to wait for the per-patch pixel attribute data to be released before starting the next phase of the TBIR graphics pipeline 124, thus helping to reduce pauses between phases and helping to reduce the time required to render primitives.

[0042] In this manner, AU 114 is configured to implement the TBIR graphics pipeline 124. Because the TBIR graphics pipeline 124 enables 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 the stored state, thereby reducing the complexity and resources required for rendering primitives. Additionally, since AU 114 determines pixel light values ​​from per-tile pixel attribute data in the G buffer, the assembly and shading of primitives completed during the tile rendering phase are not repeated during the tile lighting phase, thereby reducing the processing resources and time associated with rendering primitives. Furthermore, because the TBIR graphics pipeline 124 involves rendering primitives tile by tile rather than rendering the entire frame at once, the processing resources required at any given time are reduced, thereby helping to reduce the power consumption of processing system 100 and improve processing efficiency.

[0043] In the depicted example, CPU 102 implements multiple processor cores 104-1 to 104-N that execute instructions concurrently or in parallel. In at least some embodiments, one or more processor cores of processor core 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 having two or more channels configured to perform wave operations (e.g., space testing). Although three processor cores (104-1, 104-2, 104-M) representing M cores are presented, the number of processor cores 104 implemented in CPU 102 is a matter of design choice. Therefore, in other embodiments, CPU 102 may include any number of processor cores 104. In some embodiments, CPU 102 and AU 114 have equal numbers of processor cores 104 and 116, while in other embodiments, 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 able to initiate graphics processing by issuing command streams from one or more applications 108 to AU 114.

[0044] The input / output (I / O) engine 118 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 communicatively coupled to one or more of the memory 106, AU 114, or CPU 102 via bus 112.

[0045] Now for reference Figure 2 The implementation scheme presents AU processor cores 216-1 to 216-1 configured to implement at least a portion of a tile-based real-time rendering pipeline. N Collective operation of (collectively referred to herein as processor core 216). In some implementations, processor core 216 is implemented within AU 114 as processor cores 116-1 to 116- N (refer to Figure 1 According to the implementation scheme, processor core 216 is configured to implement at least a portion of the TBIR graphics pipeline 124 by executing one or more instructions, operations, or both associated with the TBIR graphics pipeline 124. For this purpose, processor core 216 is communicatively coupled to command processor 232. Command processor 232 includes, for example, circuitry configured to receive a command stream from 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 a frame. 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 processor core 216. Such geometric states 115 include, for example, data (e.g., parameters) for initializing and indicating tile-based real-time rendering, geometric stages of the TBIR graphics pipeline 124, or both. Additionally, such pixel states 125 include data (e.g., parameters) for initializing and indicating the tile drawing phase, release phase, acquisition phase, tile lighting phase, and discard phase of the TBIR graphics pipeline 124.

[0046] Based on a first geometry state 115 provided from command processor 232, processor core 216 first divides the frame to be rendered into multiple tiles as indicated by the first geometry state 115. Each tile includes, for example, multiple pixels in a first direction and multiple pixels in a second direction, as indicated by the first geometry state 115. After dividing the frame into tiles, processor core 216 then assigns per-tile queues 228 to each frame in the frame group, as indicated by the first geometry state 115. For example, AU 114 assigns a first per-tile queue 0 228-1 to the first tile in the tile group, a second per-tile queue 1 228-2 to the second tile in the tile group, a third per-tile queue 2 228-3 to the third tile in the tile group, and a fourth per-tile queue N 228-N to the fourth tile in the tile group. 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 embodiment presented illustrates a processor core 216 with four sets of per-tile queues 228, representing N per-tile queues 228 supporting N tiles of a frame. However, in other embodiments, processor core 216 may include any number of per-tile queues 228 supporting any number of tiles of a frame. Furthermore, in some embodiments, each per-tile queue 228 is formed by one or more per-shader queues of processor core 216.

[0047] Based on the second geometry state 115 of the command flow, processor core 216 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 tile group (e.g., tiles have an assigned per-tile queue 228). For this purpose, processor core 216 includes, or otherwise communicatively coupled 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 the second geometry state 115. As an example, based on the second geometry state 115 and data indicating the primitives to be rendered in the frame, geometry circuitry 226 assembles and shades each indicated primitive. Once geometry circuitry 226 has assembled and shaded the indicated primitives, it determines whether each of the assembled primitives is at least partially visible (e.g., relevant) in each tile of the frame group. Based on the fact that the assembled primitives are at least partially visible in the tile, the geometry circuit 226 provides geometric data representing the primitives, such as vertex data, shading data, positioning data, or any combination thereof, to the per-tile queue 228 assigned to that tile.

[0048] Once the geometry circuit 226 has stored the geometry data representing each primitive that is at least partially visible in the tile into the corresponding per-tile queue 228, such stored data... Figure 2 The 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 of primitives that are at least partially visible within the corresponding tile. According to an embodiment, once the geometry circuit 226 has stored the per-tile geometry data 105 of the first tile in the corresponding per-tile queue 228 (e.g., per-tile queue 228), the processor core 216 is configured to perform a tile drawing phase for the first tile based on a first pixel state 125. As an example, with the geometry circuit 226 having completed the remainder of the geometry phase, the processor core 216 is configured to perform a tile drawing phase for the first tile based on the first pixel state 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.

[0049] As an example, to perform the tile rendering phase for the first tile in the TBIR graphics pipeline 124, pixel circuitry 230 is configured to first consume the 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 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 per-tile geometry data 105-1 as a batch (e.g., a coarse batch) to G buffer 234 based on a first pixel state 125. That is, AU 114 assembles, rasterizes, and shades the primitives indicated in per-tile geometry data 105 based on the first pixel state 125 to produce per-tile pixel attribute data 235 stored in G buffer 234. Furthermore, based on the assembly, rasterization, and coloring of these primitives according to the per-patch geometry data 105, the pixel circuit 230 generates per-patch depth data 245 stored in the Z-buffer 236. The G-buffer 234 and Z-buffer 236 each include, for example, corresponding buffers formed by at least corresponding portions of the cache 122, memory 106, or both. Furthermore, the per-patch pixel attribute data 235 stored in the G-buffer 234 represents the attributes (e.g., color, positioning) of pixels forming primitives that are at least partially visible in the first patch, and the per-patch depth data 245 stored in the Z-buffer 236 represents the depth of pixels forming primitives that are at least partially visible in the first patch. According to an embodiment, the patch rendering stage also includes the pixel circuit 230 performing one or more depth culling techniques on the per-patch depth data 245, as indicated by the first pixel state 125. As an example, for each pixel that forms a primitive that is at least partially visible in a tile, AU 114 compares the depth value of the pixel indicated in the per-tile depth data 245 with one or more predetermined thresholds indicated in the first pixel state 125. Based on the comparison of the pixel's depth value with the predetermined thresholds, pixel circuitry 230 removes the pixel from Z-buffer 236, G-buffer 234, or both by, for example, not providing the per-tile pixel attribute data 235 or per-tile depth data 245 associated with the pixel to G-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) as indicated by the comparison of the pixel's depth value indicated by the per-tile depth data 245 with the predetermined thresholds, pixel circuitry 230 then removes the pixel from Z-buffer 236, G-buffer 234, or both.

[0050] After pixel circuit 230 has completed the tile drawing phase of the first tile and based on the second pixel state 125, the pixel circuit then releases the per-tile pixel attribute data 235 in the G buffer 234, enabling the pixel circuit to perform the lighting phase of the TBIR graphics pipeline 124 for the first tile. To perform this lighting phase for the first tile, pixel circuit 230 is configured to receive a third pixel state 125. As indicated by the third pixel state 125, pixel circuit 230 uses the per-tile pixel attribute data 235 associated with the first tile to perform one or more pixel shading operations 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 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. Furthermore, once the pixel circuit 230 has determined the illumination value for each pixel of a primitive that is at least partially visible in the first tile and based on the fourth pixel state 125, the pixel circuit 230 discards the per-tile pixel attribute data 235.

[0051] According to the implementation scheme, when pixel circuit 230 releases the per-patch pixel attribute data 235 associated with the first patch in G 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 the per-patch pixel attribute data 235 associated with the first patch is released and based on the corresponding pixel state 125, pixel circuit 230 performs a patch drawing phase for the second patch, stores the per-patch pixel attribute data 235 of the second patch in G buffer 234, and releases the per-patch pixel attribute data 235 of the second patch in G buffer 234 to perform a lighting phase for the second patch. Furthermore, as an example, as pixel circuit 230 releases the per-patch pixel attribute data 235 of the second patch in G 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.

[0052] Figure 3 This is a block diagram of acceleration unit core 316, which includes (along with interconnect circuitry omitted for clarity) two shader engines 300 (SE0) and 350 (SE1), each configured, among other things, to perform deferred attribute shading operations as part of graphics pipeline 124 (see reference). Figure 1 In some implementations, the acceleration unit core 316 is implemented within the AU 114 as processor cores 116-1 to 116-1.N One of them (reference) Figure 1 ).

[0053] In the depicted embodiments, shader engines 300, 350 share primitive and geometric data, as described below. However, it should be understood that in various embodiments, the AU core may include any number of shader engines and may be configured to share such primitive and geometric data among any number of those shader engines, or to be configured such that each shader engine utilizes only the primitive and geometric data generated locally for that shader engine.

[0054] Shader engine 300 (SE0) includes geometry engine 302, which performs initial culling of geometric primitives to identify (such as based on per-tile geometry data 105 and / or geometry state 115) those geometric primitives relevant to subsequent processing and generates metadata 314 to facilitate that subsequent processing. The metadata 314 typically includes information about the geometric primitives identified as to be processed (such as vertices, lines, triangles), including their indices and basic properties required for primitive assembly and culling.

[0055] Primitives identified as relevant by geometry engine 302 are processed by primitive mesh shader block 304 (based on pixel state 125). The primitive mesh shader block performs various shader operations to transform and prepare the identified relevant primitives for rendering by generating geometric data 320 for subsequent processing. In various implementations and scenarios, as a non-limiting example, geometric data 320, 322 includes transformed positioning of vertices, normals, and / or other geometric features generated by the execution of the vertex or geometry shader. This data is used for further geometric processing, including clipping, tessellation, and setup for subsequent rasterization.

[0056] In the depicted implementation, primitive assembler 306 processes and assembles primitive data based on primitive data 314 from geometry engine 302 and primitive data 317 from geometry engine 352. Primitive assembler 306 then provides the assembled primitive data 308 to attribute shader 310 and rasterizer 324. In the depicted implementation, primitive assembler 306 aggregates and organizes primitive data 314, 317 for subsequent processing, such as aligning primitive data like vertices and indices to facilitate subsequent attribute shading and rasterization.

[0057] The attribute shader 310 performs attribute shading operations on a deferred basis relative to a typical graphics pipeline. These operations generate attribute data 328 by determining or modifying one or more attributes of a vertex or primitive (e.g., by calculating lighting effects, texture map coordinates, vertex colors, etc.). By deferring these operations until after initial geometry culling, thus generating attribute data only for primitives that have already undergone the culling process of geometry engines 302, 352, the AU core 316 improves rendering efficiency by allocating more computational resources to the processing of geometry that contributes only to the final rendered image. This reduces the overhead associated with processing the attributes of primitives that will ultimately be discarded, for example, due to occlusion or being outside the view frustum.

[0058] The attribute shader 310 provides the processed attribute data 328 to the rasterizer 324 and the pixel shader 330. The rasterizer transforms the geometric data into pixel data. After the occlusion culling block 326 performs a culling operation on the output of the rasterizer 324, the pixel shader generates the final pixel value for rendering (such as to eliminate unnecessary processing of occluded primitives by the pixel shader 330).

[0059] In the depicted implementation, shader engine 350 is substantially the same as shader engine 300, wherein geometry engine 352, primitive mesh shader 354, primitive assembler 356, attribute shader 360, rasterizer 374, occlusion culling block 376, and pixel shader 380 perform substantially the same operations as those described above with respect to geometry engine 302, primitive mesh shader 304, primitive assembler 306, attribute shader 310, rasterizer 324, occlusion culling block 326, and pixel shader 330, respectively. Shader engines 300 and 350 of AU core 316 operate together to generate primitive data 314 and 317 and geometric data 320 and 322 for subsequent processing by each of these shader engines 300 and 350. Furthermore, in the described implementation, the map data 314, 317, geometric data 320, 322, assembly map data 308, 358, and attribute data 328, 378 are advantageously preserved and used within the AU core 316, thereby avoiding cross-core data traffic and the latency and associated resource consumption associated with such data traffic.

[0060] Figure 4 A flowchart is depicted illustrating an operation routine 400 of one or more shader engines implementing deferred attribute shading operations according to some implementation schemes. This routine may, for example, be generated by one or more processing cores (e.g., Figure 1 Core 116-1......116- N , Figure 2 Core 216-1......216- N and / or Figure 3 The core 316) is executed, such as via one or more shader engines that process the core (e.g., Figure 3 (Shader engines 300, 350). Although the operation routine 400 is described below as if executed by a single shader engine, it should be understood that in various implementations, the described operation may be executed by one or more shader engines across one or more processing cores, as described elsewhere in this document.

[0061] The routine begins at box 405, where the shader engine receives a set of primitives specified for rendering the scene. These primitives, which constitute the raw geometry, are the fundamental elements that will be processed to create the final visual output for the scene being rendered.

[0062] The routine proceeds to box 410, where the received set of primitives is culled. During this culling phase, the shader engine identifies a subset of primitives that are likely to be visible within the scene, effectively filtering out those primitives that will not contribute to the viewer's perception of the scene. Therefore, primitives that are likely not visible within the scene (whether due to occlusion or being outside screen space) are culled, leaving only those that are likely to be visible for further processing. This culling improves rendering efficiency by reducing the workload in subsequent processing stages. Once the subset of potentially visible primitives has been established, the routine proceeds to box 415.

[0063] At box 415, the shader engine generates intermediate data for the subset of primitives to be culled. As discussed elsewhere in this document, this intermediate data may, as a non-limiting example, include: one or more of the primitive data (e.g., primitive data 314, 317); geometric data (e.g., geometric data 320, 322); assembled primitive data 308, 358, which aggregates and organizes the primitive data for efficient subsequent processing; and attribute data (e.g., attribute data 328, 378). This routine proceeds to box 420.

[0064] At box 420, the shader engine uses the intermediate data to generate attribute data values ​​for the identified subset of primitives. As discussed in more detail elsewhere in this document, such attribute values ​​may, as a non-limiting example, include color, normal vectors, texture coordinates, lighting information, etc. After the attribute data is computed, the routine proceeds to box 425.

[0065] At box 425, the shader engine rasterizes the identified subset of primitives based on the generated attribute data values. Rasterization converts the geometric representation of the primitives into pixel data of the scene, thus mapping the attribute data onto a two-dimensional screen space. This routine proceeds to box 430.

[0066] At box 430, the shader engine generates pixel values ​​for the rendered scene based on a subset of rasterized primitives. In various implementations and scenes, the generation of pixel values ​​may include applying final color and lighting calculations to the rasterized data, resulting in pixel values ​​output to the display that create the rendered scene as observed by the user.

[0067] In some implementations, the above-described devices and techniques include one or more integrated circuit (IC) devices (also known as integrated circuit packages or microchips) (as described in the above reference). Figures 1 to 4 The described acceleration unit and its components are implemented in a system. 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 a 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 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 an IC device may be stored in or accessed from the same computer-readable storage medium or different computer-readable storage media.

[0068] 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), fixedly 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 USB-based flash memory), or coupled to a computer system via a wired or wireless network (e.g., a network-accessible storage device (NAS)).

[0069] One or more of the aforementioned elements are circuits designed and configured to perform the corresponding operations described above. In at least some embodiments, such circuitry is any one or a combination of the following: hard-coded circuitry (e.g., a corresponding portion of an Application-Specific Integrated Circuit (ASIC) or a set of logic gates, memory elements, and other components selected and arranged to perform the operations), programmable circuitry (e.g., a corresponding portion of a Field-Programmable Gate Array (FPGA) or Programmable Logic Device (PLD), or one or more processors executing software instructions that cause one or more processors to perform the actions. In some embodiments, the circuitry of a particular element is selected, arranged, and configured by one or more computer-implemented design tools. For example, in some embodiments, the sequence of operations for a particular element is defined in a specified computer language (such as register-transfer language), and the computer-implemented design tools select, configure, and arrange the circuitry based on the defined sequence of operations.

[0070] Within this disclosure, in some instances, different entities (which are referred to differently as “components,” “units,” “devices,” “circuits,” etc.) are described or claimed to be “configured” to perform one or more tasks or operations. This way of describing (i.e., an [entity] configured to [perform one or more tasks]) is used herein to refer to a structure (i.e., a physical structure, such as an electronic circuit). More specifically, this way of describing indicates that the physical structure is arranged to perform the one or more tasks during operation. A structure may be referred to as being “configured” to perform a task even if the structure is not currently operating. “Memory device configured to store data” is intended to cover, for example, an integrated circuit having circuitry for storing data during operation, even if the integrated circuit in question is not currently in use (e.g., power is not connected to the integrated circuit). Therefore, an entity described or stated as being “configured” to perform a task refers to a physical structure, such as a device, circuit, memory storing program instructions that can be executed to perform the task, etc. This phrase is not used herein to refer to an intangible structure. Furthermore, the term “configured to” is not intended to mean “configurable as.” For example, an unprogrammed field-programmable gate array will not be considered "configured" to perform a particular function, but it may be "configurable" to perform that function after programming. Additionally, the statement in the appended claims that a structure is "configured" to perform one or more tasks is not expressly intended to be interpreted as having components plus functional elements.

[0071] In some implementations, certain aspects of the above-described techniques 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 above-described techniques. 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.

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

[0073] 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: A set of primitives is received by one or more shader engines for rendering at least a portion of the scene; The primitive set is culled by one or more shader engines, wherein culling the primitive set includes identifying a subset of primitives that may be visible in the scene; The attribute data values ​​of the identified primitive subset are generated by the one or more shader engines; as well as The one or more shader engines rasterize the identified primitive subset for rendering based on the generated attribute data values.

2. The method of claim 1, further comprising generating intermediate data of the identified primitive subset by the one or more shader engines, and wherein the method is performed without providing the intermediate data or the attribute data values ​​outside the one or more shader engines.

3. The method according to claim 2, wherein: The intermediate data for generating the identified subset of primitives includes intermediate geometric data for generating the identified subset; and The subset of primitives identified by rasterization includes the subset identified by rasterization based on the intermediate geometry data.

4. The method according to claim 2 or claim 3, wherein: The intermediate data for generating the identified primitive subset includes assembled primitive data for generating the identified primitive subset; and Generating the attribute data values ​​includes generating the attribute data values ​​based on the assembly graph data.

5. The method according to any one of claims 1 to 4, wherein the subset of primitives identified by rasterization includes generating a rasterized subset of primitives, and wherein the method further includes rendering the scene by generating pixel data based on the subset of rasterized primitives.

6. The method according to any one of claims 1 to 5, the method further comprising splitting the scene into a plurality of tiles, wherein the set of primitives corresponds to all primitives associated with one of the plurality of tiles.

7. The method according to any one of claims 1 to 6, wherein receiving the primitive set comprises receiving one or more of the following: geometric data associated with the primitive set, geometric state data associated with the scene, or pixel state data.

8. The method according to any one of claims 1 to 7, wherein the method is executed by a processor core including the one or more shader engines.

9. An acceleration unit, the acceleration unit comprising: One or more caches; and One or more shader engines, said one or more shader engines being coupled to said one or more caches, said one or more shader engines being configured to: Receive a set of primitives for at least a portion of the scene to be rendered; Remove the set of primitives to identify a subset of primitives that may be visible in the scene; Generate attribute data values ​​for the identified subset of primitives; as well as The identified subset of primitives is rasterized based on the generated attribute data values ​​for rendering.

10. The acceleration unit of claim 9, wherein the one or more shader engines are further configured to: generate intermediate data for the identified primitive subset; and generate the attribute data values ​​and rasterize the identified primitive subset without providing the intermediate data or the attribute data values ​​outside the one or more shader engines.

11. The acceleration unit according to claim 10, wherein: The intermediate data of the identified primitive subset includes the intermediate geometric data of the identified subset; and The one or more shader engines are configured to rasterize the identified primitive subset based on the intermediate geometry data.

12. The acceleration unit according to claim 10 or claim 11, wherein: The intermediate data for the identified primitive subset includes the assembled primitive data of the identified primitive subset; and The one or more shader engines are configured to generate the attribute data values ​​based on the assembled graph data.

13. The acceleration unit according to any one of claims 9 to 12, wherein the primitive subset identified by rasterization includes generating a rasterized primitive subset, and wherein the one or more shader engines are configured to render the scene by generating pixel data based on the rasterized primitive subset.

14. The acceleration unit according to any one of claims 9 to 13, wherein the scene is divided into a plurality of tiles, and wherein the set of primitives corresponds to all primitives associated with one of the plurality of tiles.

15. The acceleration unit according to any one of claims 9 to 14, wherein the primitive set includes one or more of the following: geometric data associated with the primitive set, geometric state data associated with the scene, or pixel state data.

16. A non-transitory computer-readable medium employing an executable instruction set for instructing at least one processor to perform the following operations: Receive a set of primitives for at least a portion of the scene to be rendered; A subset of primitives that may be visible in the scene is identified by the shader engine of the at least one processor; The shader engine generates attribute data values ​​for the identified subset of primitives; as well as The shader engine rasterizes the identified primitive subset based on the generated attribute data values ​​for rendering.

17. The non-transitory computer-readable medium of claim 16, wherein the executable instruction set manipulates the shader engine to: generate intermediate data for an identified subset of primitives; and generate the attribute data values ​​and rasterize the identified subset of primitives without providing the intermediate data or the attribute data values ​​outside the shader engine.

18. The non-transitory computer-readable medium according to claim 17, wherein: The intermediate data of the identified primitive subset includes the intermediate geometric data of the identified subset; and The shader engine is configured to rasterize the identified primitive subset based on the intermediate geometry data.

19. The non-transitory computer-readable medium according to claim 17 or claim 18, wherein: The intermediate data for the identified primitive subset includes the assembled primitive data of the identified primitive subset; and The shader engine is configured to generate the attribute data values ​​based on the assembled graph data.

20. The non-transitory computer-readable medium according to any one of claims 16 to 19, wherein the primitive subset identified by rasterization includes generating a rasterized primitive subset, and wherein the executable instruction set manipulates the at least one processor to render the scene by generating pixel data based on the rasterized primitive subset.

Images