Graphics processing system, storage medium, and method of processing primitive fragments

Abstract

The invention relates to a graphics processing system, a storage medium and a method of processing primitive fragments. The graphics processing system processes primitive fragments using a rendering space subdivided into tiles. The graphics processing system comprises processing engines configured to apply texturing and / or shading to the primitive fragments. The graphics processing system further comprises a cache system for storing graphics data of the primitive fragments, the cache system comprising a plurality of cache subsystems. Each of the cache subsystems is coupled to a respective set of one or more processing engines. The graphics processing system further comprises a tile assignment unit operating in a plurality of assignment modes to assign tiles to the processing engines. The plurality of assignment modes comprises a spatial assignment mode, wherein spatially adjacent tile groups are assigned to the processing engines according to a spatial assignment scheme which ensures that each of the spatially adjacent tile groups is assigned to a set of processing engines coupled to the same cache subsystem.

Description

[0001] This application is a divisional application of the original invention patent application No. 201611193851.8 (filed on December 21, 2016, entitled "Graphics Processing System and Method for Processing Primitive Fragments in a Graphics Processing System"). Technical Field

[0002] This invention relates to the partitioning of a processing engine in a graphics processing system. Background Technology

[0003] Graphics processing systems are typically configured to receive graphics data (e.g., from applications running on a computer system) and render the graphics data to provide a rendered output. For example, the graphics data provided to a graphics processing system may describe the geometry within a three-dimensional (3D) scene to be rendered, and the rendered output may be a rendered image of the scene. Some graphics processing systems (which may be referred to as “tile-based” graphics processing systems) use a rendering space that is subdivided into multiple tiles. A “tile” is a region of the rendering space and can have any suitable shape, but is typically rectangular (where the term “rectangle” includes squares). To give some examples, a tile may cover a 16×16 pixel block or a 32×32 pixel block of the image to be rendered. As is known in the art, there are many benefits to subdividing the rendering space into tiles. For example, subdividing the rendering space into tiles allows the image to be rendered in a tile-by-tile manner, where graphics data for a tile can be temporarily stored “on-chip” during the rendering of the tile, thereby reducing the amount of data transferred between system memory and the chip where the graphics processing unit (GPU) implementing the graphics processing system resides.

[0004] Patch-based graphics processing systems typically operate in two phases: a geometry processing phase and a rasterization phase. In the geometry processing phase, the graphics data to be rendered is analyzed to determine which graphics data items are present in each patch. Then, in the rasterization phase, the patches are rendered by processing those graphics data items determined to be present in the patch (without processing graphics data items determined not to be present in a particular patch during the geometry processing phase). Graphical data items can represent geometry, describing the surfaces of structures in the scene, and are called "primitives." A common primitive shape is a triangle, but primitives can be other 2D shapes or even lines or points. Objects can consist of one or more (e.g., hundreds, thousands, or millions) of such primitives.

[0005] Figure 1Some components of a graphics processing system 100 that can be used to render images of a 3D scene are shown. The graphics processing system 100 includes a graphics processing unit (GPU) 102 and two parts, memory 1041 and memory 1042. The two parts of memory 1041 and memory 1042 may or may not be parts of the same physical memory.

[0006] GPU 102 includes a preprocessing module 106, a patching unit 108, and a rasterization module 110, wherein the rasterization module 110 includes a hidden surface removal (HSR) unit 112 and a texturing / shading unit 114. The texturing / shading unit 114 includes one or more processing engines, which may be referred to as "Unified Shading Clustering" (USC). The graphics processing system 100 is arranged such that a sequence of primitives provided by an application is received at the preprocessing module 106.

[0007] During the geometry processing phase, preprocessing module 106 performs geometry processing functions, including trimming and pruning, to remove primitives that do not fall into the visible view. Preprocessing module 106 can also project primitives into screen space. Primitives output from preprocessing module 106 are passed to segmentation unit 108, which determines which primitives exist in each segment of the rendering space of graphics processing system 100. Segmentation unit 108 assigns primitives to segments of the rendering space by creating a display list for each segment, wherein the display list for each segment includes an indication of the primitives present within the segment. This display list and primitives are output from segmentation unit 108 and stored in memory 1041.

[0008] During the rasterization phase, rasterization block 110 retrieves a display list for the patch and the primitives associated with that patch from memory 1041. HSR unit 112 performs hidden surface removal, thereby removing fragments of primitives hidden in the scene. Methods for performing hidden surface removal are known in the art. The term "fragment" refers to a sample of a primitive at a sampling point that will be processed as a pixel in the rendered image. In some examples, there may be a one-to-one mapping from fragments to pixels. In other examples, there may be more fragments than pixels, and this oversampling may take into account higher quality rendering of pixel values, for example, by facilitating anti-aliasing and other filtering that can be applied to multiple fragments for each pixel value in the rendered image. The remaining fragments are passed from HSR unit 112 to texturing / shading unit 114, which performs texturing and / or shading on the fragments to determine pixel color values ​​that can be passed to memory 1042 for use in the rendered image stored in the frame buffer. The texturing / shading unit 114 may receive texture data from memory 1041 to apply texturing to primitive fragments, as known in the art (e.g., by running a shadower program). The texturing / shading unit 114 may apply further processing to the primitive fragments (e.g., alpha blending and other processes), as known in the art, to determine the rendered pixel values ​​of the image. The rasterization block 110 processes the primitives in each of the patches, and when the entire image has been rendered and stored in memory 1042, the rendered image may be output from the graphics processing system 100 and used in any suitable manner (e.g., displayed on a monitor, stored in memory, or sent to another device, etc.).

[0009] The texturing / shading unit 114 may include more than one processing engine capable of processing different data in parallel, thereby improving the efficiency of texturing and / or shading performed by the texturing / shading unit 114. The rasterization block 110 may be configured to render primitives for a single patch at a time. Summary of the Invention

[0010] This overview is provided to introduce a choice of concepts in a simplified form, which will be further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0011] A graphics processing system is provided, configured to process primitive fragments using a rendering space subdivided into multiple patches. The system includes: multiple processing engines configured to apply one or both of texturing and shading to the primitive fragments; a cache system configured to store graphics data for use in processing the primitive fragments, the cache system including multiple cache subsystems, each cache subsystem being coupled to a corresponding set of one or more processing engines within the processing engines; and a patch allocation unit configured to operate in one or more allocation modes to allocate patches to the processing engines, wherein the one or more allocation modes include a spatial allocation mode in which spatially adjacent patches are allocated to processing engines according to a spatial allocation scheme that ensures each group of spatially adjacent patches is allocated to a set of processing engines coupled to the same cache subsystem.

[0012] A method is provided for processing primitive fragments in a graphics processing system using a rendering space that is further divided into multiple patches. The method includes: applying one or both of texturing and shading to the primitive fragments at multiple processing engines; storing graphics data in a cache system for use in processing the primitive fragments, the cache system including multiple cache subsystems, wherein each cache subsystem is coupled to a corresponding set of one or more processing engines in the processing engines; and allocating patches to the processing engines in one or more allocation modes, wherein the one or more allocation modes include a spatial allocation mode in which spatially adjacent patches are allocated to processing engines according to a spatial allocation scheme that ensures that each group of spatially adjacent patches is allocated to a set of processing engines coupled to the same cache subsystem.

[0013] Computer-readable code may be provided, which is adapted to perform the steps of any of the methods described herein when the code is run on a computer. This computer-readable code may be encoded on a computer-readable storage medium.

[0014] A method for manufacturing a graphics processing system according to any of the examples described herein at an integrated circuit manufacturing system may also be provided. An integrated circuit definition dataset may also be provided, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing system as described in any of the examples herein. This integrated circuit definition dataset may be stored on a computer-readable storage medium.

[0015] As will be apparent to a person skilled in the art, the above features can be combined where appropriate and can be combined with any of the aspects of the examples described herein. Attached Figure Description

[0016] The example will now be described in detail with reference to the accompanying drawings, in which:

[0017] Figure 1 An example of a prior art graphics processing system is shown;

[0018] Figure 2 A graphics processing system according to an embodiment described herein is shown;

[0019] Figure 3 Represents the primitives within a segment;

[0020] Figure 4 This is a flowchart illustrating a method for processing primitive fragments in a graphics processing system;

[0021] Figure 5 The image shows the fragment blocks to be assigned to the processing engine;

[0022] Figure 6 Instructions to allocate the fragment from the block to the processing engine;

[0023] Figure 7 The diagram illustrates the first state of the sequence of slices assigned to the processing engine;

[0024] Figure 8 This is a flowchart illustrating the method of allocating slices to the processing engine;

[0025] Figure 9 The diagram illustrates the second state of the queues assigned to the processing engine;

[0026] Figure 10 The diagram illustrates the third state of the queues assigned to the processing engine;

[0027] Figure 11a This shows the first order in which the fragment blocks can be processed;

[0028] Figure 11b The diagram illustrates the second order in which regions can be processed;

[0029] Figure 12 A graphics processing system based on another example is shown;

[0030] Figure 13 This is a flowchart illustrating a method for processing primitive fragments in another example graphics processing system;

[0031] Figure 14 A computer system in which a graphics processing system is implemented is shown; and

[0032] Figure 15 An integrated circuit manufacturing system for generating integrated circuits that implement a graphics processing system is shown.

[0033] The accompanying drawings illustrate various examples. Those skilled in the art will understand that the element boundaries (e.g., blocks, groups of blocks, or other shapes) illustrated in the drawings represent one example of a boundary. In some examples, one element may be designed as multiple elements or multiple elements may be designed as one element. Where appropriate, common reference numerals are used throughout the drawings to indicate similar features. Detailed Implementation

[0034] The embodiments will now be described by way of example only.

[0035] Figure 2 Some components of a graphics processing system 200 that can be used to render images of a 3D scene are shown. The graphics processing system 200 includes two parts: a graphics processing unit (GPU) 202 and memories 2041 and 2042. It should be noted that the two parts of memories 2041 and 2042 may or may not be parts of the same physical memory, and both memories 2041 and 2042 may be located "off-chip" (i.e., not on the same chip as the GPU 202). Communication between the memories (2041 and 2042) and the GPU 202 can occur on a communication bus within the system 200. The graphics processing system can be implemented in hardware (e.g., on an integrated circuit), in software, or a combination of both.

[0036] The GPU 202 includes a preprocessing module 206, a patching unit 208, and a rasterization module 210, wherein the rasterization module 210 includes a hidden surface removal (HSR) unit 212, a texturing / shading unit 214, and a post-processing module 230. The texturing / shading unit 214 includes multiple processing engines 216, which may be referred to as "Unified Shading Clustering" (USC). Figure 2 Eight processing engines 2160 to 2167 are shown, where, for clarity, in Figure 2 Only two of them are referenced using figure reference numerals. Each processing engine 216 in processing engine 216 is configured to apply one or both of texturing and shading to primitive fragments. The texturing / shading unit 214 also includes a cache system 218 configured to store graphics data associated with primitive fragments. The cache system 218 is a multi-level cache. The cache system 218 includes multiple level 1 cache subsystems 220 and level 2 caches 222. Figure 2 In the example shown, there are four Level 1 cache subsystems 2200 to 2203, where, for clarity, Figure 2Only two of them are referenced using the figure reference numerals. The texturing / shading unit 214 also includes: a tile allocation unit 224, which includes allocation logic 226; and a set of queues 228 for storing indications of tiles allocated to the processing engine. The operation of the tile allocation unit 224 is described in detail below.

[0037] The geometry processing stage implemented by graphics processing system 200 can be the same as the geometry processing stage implemented by graphics processing system 100 described above. Therefore, preprocessing module 206 performs functions such as trimming / clipping and projects primitives into screen space. The patching unit 208 determines which primitives exist within each patch of the rendering space of graphics processing system 200 and assigns primitives to the patches of the rendering space by creating a display list for each patch, wherein the display list for each patch includes indications of the primitives present within the patch. This display list and primitives are output from patching unit 208 and stored in memory 2041. The display list provides data to rasterization module 210 for rendering primitive fragments within the corresponding patches in the rasterization stage. As an example, the display list may include a region header, control flow, and vertex blocks. The region header is an array of pointers to the header of the control flow for each patch. The control flow is a list of pointers to vertex blocks for each patch and a list of primitives present within the vertex blocks of the corresponding patches. A vertex block includes the exponent of a primitive, where the exponent points to the vertex data contained within the same vertex block (i.e., the local exponent within the context of the vertex block).

[0038] Reference Figure 1 In contrast to the graphics processing system 100 described above, the graphics processing system 200 may have "multiple patches in flight" (i.e., multiple patches targeted by primitives that are partially processed at a given time) in the rasterization module 210. For example, the HSR unit 212 may include multiple depth buffers configured to store depth data for the respective multiple patches, allowing it to switch between processed primitives from different patches before processing of all primitives within a patch is completed. This allows for greater flexibility in the order in which primitives are processed by the rasterization module 214, which can result in more efficient processing of primitives by the graphics processing system 200 compared to the processing performed by the graphics processing system 100, where any one of the primitives in the next patch is processed by the rasterization unit 110 and all primitives in the previous patch are processed by the rasterization unit 110. For example, if processing of a region stops for some reason specific to the region being processed, the rasterization unit 210 of the graphics processing system 200 can continue processing primitives from other regions; however, the rasterization unit 110 of the graphics processing system 100 may stop until processing can resume for the stopped region. See below for reference. Figure 12 and Figure 13 In more detail, an HSR unit may include more than one HSR module that can perform HSR on different segments in parallel.

[0039] In a graphics processing system 200 containing multiple patches in flight, using the same processing engine 216 for applying texture / shading to all visible primitives within a specific patch can be efficient. That is, a patch can be assigned to be processed by one of the processing engines 216, rather than using more than one of the processing engines 216 to process graphics data for a specific patch. This can be advantageous because each primitive in a patch allows texture data for that primitive to be loaded into a local cache subsystem 220 of the processing engine 216. By processing primitive fragments from a patch in a single processing engine 216, texture / shading data for the primitives in that patch needs to be loaded into the cache subsystem of that processing engine 216. Conversely, if primitive fragments from a patch are distributed across several processing engines, the same texture / shading data is more likely to be copied across several cache subsystems 220. Furthermore, if primitive fragments from a region are distributed across several processing engines, data consistency issues may arise, for example, assuming different processing engines process primitives at the same sampling location.

[0040] In some systems, slices are allocated to processing engines for processing according to a load balancing scheme. In this way, slices can be allocated to processing engines with a view that prevents any of the processing engines from becoming idle, which helps maintain the rate at which the texturing / shading unit 214 processes slices. However, according to these load balancing schemes, slices can be allocated to processing engines without considering their spatial location, and as described below, this can lead to inefficiencies in cache usage.

[0041] Individual primitives can exist within more than one region. For example, Figure 3 A 2×4 tile block 300 within the rendering space is shown, where primitive 304 exists within two tiles: tile 3020 and tile 3021. Therefore, graphics data for primitive 304 will be written to a cache subsystem used by the processing engine that processes tiles 3020 and 3021. As will be apparent, primitives can cover many tiles within the rendering space, exceeding two tiles.

[0042] In the example described herein, each processing engine in the processing engine shares an L1 cache subsystem with one or more (but not all) other processing engines. That is, each L1 cache subsystem is coupled to a corresponding set of one or more processing engines within the processing engine. For example, in Figure 2 In the texture / shading unit 214 shown, each of the cache subsystems 2200 to 2203 is coupled to a corresponding set of two of the processing engines 2160 to 2167. Specifically, cache subsystem 2200 is coupled to processing engines 2160 and 2161; cache subsystem 2201 is coupled to processing engines 2162 and 2163; cache subsystem 2202 is coupled to processing engines 2164 and 2165; and cache subsystem 2203 is coupled to processing engines 2166 and 2167. The cache subsystem 220 is configured to store graphics data associated with primitive fragments processed by the corresponding set of processing engines to which the cache subsystem 220 is coupled. For example, the graphics data may be texture data to be applied to the primitive fragments.

[0043] Each cache subsystem 220 in the cache subsystem 220 is configured to store graphics data associated with primitive fragments of a slice of the processing engine 216 to which the cache subsystem 220 is coupled. This graphics data may be referred to as “primitive data.” This graphics data is data used by the processing engine 216 to apply one or both of texturing and shading to the primitive fragments. Generally, this graphics data may include any data used in processing the primitive fragments. This graphics data may be referred to as “variable data” and may include data values ​​associated with vertices, which may or may not cross the surface of the primitives to compute per-fragment values. This graphics data may be used in a fragment shader running on the processing engine for any suitable purpose. For example, the graphics data may be color data, coordinates for accessing textures, distance data (which may be used for lighting or shading or bump mapping or something else), opacity data (which may be referred to as “alpha” data), or simply data values ​​to be used in some arbitrary computation (e.g., for use in an algorithm to produce a specific effect). The graphics data may also include other data to be used to process the primitive fragments (such as texture data of the texture to be applied to the primitive fragments).

[0044] The example diagram can be used to illustrate the issue of load balancing distribution schemes. Based on the load balancing scheme, Figure 3The slices 3020 and 3021 shown can be allocated, for example, to processing engines 2160 and 2165. Since processing engine 2160 is coupled to cache subsystem 2200 and processing engine 2165 is coupled to cache subsystem 2202, the graphics data for primitive 304 (which resides within slices 3020 and 3021) can be stored in cache subsystems 2200 and 2202. Therefore, the graphics data for primitive 304 can be copied for storage in both L1 cache subsystems. This copying represents inefficient use of cache system 218. As more data is copied in the L1 cache subsystems, additional data is pushed out of the L1 cache subsystems. This makes it more likely that data is retrieved back to L1, preferably from L2 cache 222, and possibly from higher-level memory (e.g., main memory 2041 or L3 cache or any component to which L2 cache is connected).

[0045] Compared to systems that merely implement a load balancing scheme for allocating shards to processing engines, the example described herein improves cache efficiency. Specifically, the example described herein utilizes a space allocation scheme that allocates shards to processing engines based on their spatial location and couples the cache subsystem to the processing engines. That is, the shard allocation for processing engine 216 matches the structure of cache system 218. As described in more detail below, shard allocation unit 224 can operate in a space allocation mode, in which spatially adjacent shard groups are allocated to processing engines 216 according to the space allocation scheme, ensuring that each group of spatially adjacent shard groups is allocated to a set of processing engines 216 coupled to the same cache subsystem 220.

[0046] refer to Figure 4 The flowchart shown illustrates a method for processing primitives in the graphics processing system 200. In step S402, a geometry processing stage is implemented, as described above, causing the patching unit 208 to generate a display list (or control flow) for patches in the rendering space. As described above, the display list for patches includes indications of primitives present within the patches. The display list and primitives are output from the patching unit 208 and stored in the memory 2041.

[0047] During the rasterization stage, the display list and graphic data for the primitives are provided to the rasterization module 210. Figure 2The graphics processing system 200 shown is a deferred rendering system, so hidden surface removal is applied before texturing and / or shading are applied to primitive fragments. Other graphics processing systems may be non-deferred rendering systems (i.e., immediate mode rendering systems), and in those systems, texturing and / or shading are applied before hidden surface removal is applied to primitive fragments.

[0048] In step S404, HSR unit 212 performs hidden surface removal on primitive fragments for a region of the rendering space. To process a specific region, HSR unit 212 may receive position data of primitives indicated by a display list for a specific region, such as those present within that region. HSR unit 212 uses the position data for primitives to determine whether a primitive fragment at a sample location within the region is hidden from view by other primitives. Methods for performing hidden surface removal are known in the art and will not be described in more detail herein. However, as a brief and simplified explanation, hidden surface removal may involve performing a depth test on a primitive fragment against a depth buffer, and if the primitive fragment passes the depth test, it is maintained; however, if the primitive fragment fails the depth test, it is removed. The depth buffer may be maintained to store the depth value of the latest primitive fragment that has passed the depth test at each sample location. Hidden surface removal can be more complex than this (e.g., if the primitives are not completely opaque, but the details of such complex hidden surface removal techniques are beyond the scope of this disclosure). The primitive fragments passed through the HSR are provided to the texturing / shading unit 214.

[0049] In step S406, the texturing / shading unit 214 receives graphical data (e.g., texture data) for primitive fragments passed through the HSR performed by the HSR unit 212. For example, the HSR unit 212 may provide the texturing / shading unit 214 with an indication (or “label”) of which primitives have passed through the HSR at each sample location within the patch (and are therefore visible). The texturing / shading unit 214 may retrieve graphical data for the indicated primitives from the memory 2041. The retrieved graphical data may include positional data for the primitives and attribute data to be applied to the primitives (e.g., texture to be applied to the primitives).

[0050] As mentioned above, a slice can be allocated to processing engine 216 instead of using more than one processing slice in processing engine 216. In step S408, allocation unit 224 allocates a slice to processing engine 216. This slice allocation unit 224 is configured to operate in one or more allocation modes, including a space allocation mode, where spatially adjacent slice groups are allocated to processing engines according to a space allocation scheme. As mentioned above, the space allocation scheme ensures that each of a plurality of spatially adjacent slice groups is allocated to a set of processing engines 216 coupled to the same cache subsystem 220. For example, refer to... Figure 3 Pieces 3020 and 3021 are spatially adjacent pieces and can be in the same group of spatially adjacent pieces, such that these pieces will be allocated to a set of processing engines (e.g., processing engines 2160 and 2161) coupled to the same cache subsystem (e.g., cache subsystem 2200). In this case, the graphics data for primitive 304 can be stored in the cache subsystem 2200 of the processing engines coupled to the set. The graphics data for primitive 304 does not need to be stored in any of the other cache subsystems (e.g., cache subsystems 2201, 2202, or 2203). Therefore, there is no copying of the graphics data for primitive 304 across different cache subsystems 220, and it is unlikely that other graphics data will need to be retrieved from L2 cache 222. The allocation of pieces to the processing engines is performed by the allocation logic 226 of the piece allocation unit 224. Moreover, it should be noted that textures can be mapped across multiple primitives. If texture data is stored in cache subsystem 220 for use in rendering more than one primitive, cache system 218 maintains cache consistency for texture data used in rendering different primitives. Such cache consistency is easier to maintain if processing engines that are using texture data to process primitives share a common cache subsystem 220. This is more likely to be the case when adjacent slices are assigned to processing engines 216 that share the cache subsystem 220.

[0051] In cases where primitives exist in more than one slice, compared to allocating slices to processing engines according to a load balancing scheme, allocating space to a set of spatially adjacent slices of processing engines coupled to the same cache subsystem reduces the likelihood that graphics data is required by processing engines 216 that are not coupled to the same cache subsystem 220. Further examples of allocating slices to processing engines are described below.

[0052] In step S410, the graphical data of the primitives existing in the slice is stored in the cache system 218. Specifically, the graphical data of the primitives existing in the slice is stored in the cache subsystem 220 coupled to the cache subsystem 220 to which the slice has been assigned.

[0053] In step S412, processing engine 216 processes primitive fragments by applying one or both of texturing and shading to the primitive fragments. Processing engine 216 uses graphics data (e.g., texture data) stored in cache system 218 to process primitive fragments. As described above, patches are assigned to processing engines 216 such that each processing engine 216 processes the primitive fragments of the patch assigned to it.

[0054] The graphics processing system 200 can be used in rendering images, and the processing engine 216 can output processed primitive fragments for use in generating pixel data representing the rendered image. For example, in step S414, the post-processing module 230 can apply post-processing steps such as filtering to the processed primitive fragments output from the texturing / shading unit 214 to generate pixel data representing the rendered image. The post-processing module 230 can also compress the pixel data of the rendered image before it is stored. As will be apparent, the post-processing applied by the post-processing module 230 can include any other suitable procedures (such as format conversion, gamma compression, color space conversion, or format packing).

[0055] In step S416, pixel data (which may be compressed) is output from post-processing module 230 and stored in a pixel buffer, for example, in memory 2042.

[0056] The allocation of fragments to processing engines 216 is described in more detail below. In space allocation mode, fragment allocation unit 224 allocates fragment blocks to processing engines (2160 to 2167) in an allocation process. In this way, one or more corresponding fragments from a fragment block are allocated to each of the processing engines 216. For example, in one allocation process, an equal number of fragments from a block may be allocated to each of the processing engines 216. The fragment block comprises multiple sets of spatially adjacent fragments to be allocated to different sets of processing engines coupled to the respective cache subsystem 220. For example, Figure 5 This shows patch 500. Patch 500 is a 4×4 patch. Figure 5 In this example, each parcel in parcel block 500 is labeled with a hexadecimal number (0 to F), making it easy to reference different parcels within block 500. The parcel block comprises four 2×2 spatially adjacent parcel groups (in...). Figure 5 (G1, G2, G3, and G4 are represented in the original text). By allocating all fragment blocks in a single allocation process, it is ensured that the space allocation of fragments to the processing engines matches the structure of the cache system 218. In this way, decisions about which processing engine to allocate each fragment in the block to are performed substantially simultaneously. As will be apparent from the following description, allocating fragment block 500 to processing engine 216 in a single allocation process (i.e., substantially simultaneously) does not necessarily mean that fragment block 500 will be processed by processing engine 216 simultaneously.

[0057] Figure 6 The diagram illustrates how the partition allocation unit 224 allocates partition blocks 500 to processing engines 216 according to a space allocation scheme. A first partition group (G1) is allocated to processing engines 2160 and 2161 coupled to cache subsystem 2200, such that partitions 0 and 1 are allocated to processing engine 2160 and partitions 2 and 3 are allocated to processing engine 2161. A second partition group (G2) is allocated to processing engines 2162 and 2163 coupled to cache subsystem 2201, such that partitions 4 and 5 are allocated to processing engine 2162 and partitions 6 and 7 are allocated to processing engine 2163. A third partition group (G3) is allocated to processing engines 2164 and 2165 coupled to cache subsystem 2202, such that partitions 8 and 9 are allocated to processing engine 2164 and partitions A and B are allocated to processing engine 2165. The fourth partition group (G4) is assigned to processing engines 2166 and 2167 coupled to cache subsystem 2203, such that partitions C and D are assigned to processing engine 2166 and partitions E and F are assigned to processing engine 2167. It can be understood that each 2×2 partition group (G1 to G4) is assigned to a pair of processing engines 216 coupled to the same cache subsystem 220. Therefore, in this example, each processing engine 216 in a pair is allocated two partitions from the partition group assigned to that pair of processing engines 216. In other examples, a different number of partitions (e.g., 1 or 3 or more partitions) may be allocated to each processing engine in each allocation process.

[0058] In this example, during an allocation process, each processing engine is assigned two slices from block 500. Processing engine 216 can process data from one slice at a time, so processing engine 2160 starts processing slice 0 and will attempt to complete processing of slice 0 before starting processing of slice 1. However, if for some reason, processing of slice 0 stops before it is completed, processing engine 2160 can perform some processing on slice 1 before processing of slice 0 is complete. Other processing engines 216 operate in a similar manner. Therefore, as an example, slices 0 and 2 will tend to be processed concurrently by their respective processing engines 2160 and 2161, and slices 1 and 3 will tend to be processed concurrently by their respective processing engines 2160 and 2161. Processing engines 2160 and 2161 are coupled to cache subsystem 2200, so if, for example, a primitive (such as primitive 304) exists in both sectors 0 and 2, then processing engines 2160 and 2161 can access the graph data of the primitive from cache subsystem 2200.

[0059] Assigning the fragment from the block to, for example Figure 5 and Figure 6 The processing engines shown provide a good distribution of partitions for processing engine 216. In an alternative example, partitions 0 and 2 can be assigned to processing engine 2160; partitions 1 and 3 can be assigned to processing engine 2161; partitions 4 and 6 can be assigned to processing engine 2162; partitions 5 and 7 can be assigned to processing engine 2163; partitions 8 and A can be assigned to processing engine 2164; partitions 9 and B can be assigned to processing engine 2165; partitions C and E can be assigned to processing engine 2166; and partitions D and F can be assigned to processing engine 2167. This partition allocation will also depend on the space allocation scheme, since each partition group (G1 to G4) is assigned to a corresponding set of processing engines 216 coupled to the same cache subsystem 220. However, this will tend to result in different partitions being processed concurrently. For example, patches 0 and 1 will then tend to be processed concurrently by the corresponding processing engines 2160 and 2161, and patches 2 and 3 will tend to be processed concurrently by the corresponding processing engines 2160 and 2161. In user interface use cases (such as video compositing), a significant proportion of the graphical data can be stride-based texture data, and therefore, there can be methods for allocating such... Figure 6 The slight preference for the patches shown is because if the horizontal pairs of patches tend to be processed concurrently, the cache hit rate for reading texture data from the cache system 218 can be slightly higher on average than if the vertical pairs of patches tend to be processed concurrently.

[0060] It is understandable that, compared to load balancing schemes, a space allocation scheme for allocating slices to the processing engine based on the architecture of cache system 218 can improve cache hit rates. This can be beneficial in reducing the amount of data transferred between GPU 202 and memory 2041 (which may be off-chip memory) and in reducing the amount of data transferred between different levels of the cache hierarchy. It can also be beneficial in terms of processing speed and power consumption of texture / shading unit 214.

[0061] Therefore, there is a trade-off between the efficiency of the cache system 218 and the load balancing across the different processing engines. In particular, if any of the processing engines 216 becomes idle when there is processing ready to be executed, it can reduce the efficiency of the texturing / shading unit 214. Therefore, in some scenarios, it may be beneficial to return to the load balancing distribution mode to avoid any of the processing engines becoming idle.

[0062] Therefore, the partition allocation unit 224 can operate in a load balancing allocation mode, where partitions are allocated to processing engines 216 based on their computational load. Specifically, if the load on any of the processing engines 216 drops below a threshold level, one or more partitions can be allocated to that processing engine 216 to increase its load. This can be accomplished using a view that approximately maintains the same computational load on each of the processing engines 216.

[0063] The partition allocation unit 224 includes a set of queues 228. The partition allocation unit 224 (particularly the allocation logic 226 of the partition allocation unit 224) maintains a queue for each of the processing engines 216 that is allocated for the partitions to be processed by that processing engine 216. Figure 7 The diagram illustrates the state of queue 228, which is assigned to eight processing engines 2160 to 2167. It should be noted that queue 228 contains an indication (e.g., a partition ID) of the partition assigned to the corresponding processing engine 216, rather than storing the actual partition data used to render the partition. Figure 7The diagram illustrates the number of slices in the queue for each of the processing engines 216. When a slice has been processed by a processing engine 216, it is removed from the queue for that processing engine 216; and when a slice is assigned to a processing engine 216, it is added to the queue for that processing engine 216. Thus, the queues represent slices that have been assigned to a processing engine 216 but have not yet been fully processed by it. In some other examples, a slice may be removed from the queue for a processing engine when processing begins. When a processing engine 216 is ready to begin processing a new slice, the slice allocation unit 224 determines which slice the processing engine 216 will process next by querying the appropriate queue 228. The queues may operate in a first-in, first-out (FIFO) manner or according to any other suitable queuing scheme.

[0064] As in Figure 7 As shown, there exists a maximum number of slices that can be allocated to the processing engine at any given time. Utilizing Figure 7 The dashed line (“maximum”) in the diagram indicates this maximum value. As an example, the maximum number could be six. In other examples, the maximum value could be set to a different number. Setting the maximum value to the number of slices that can be allocated to the processing engines prevents the processing of slices on different processing engines from becoming too far out of sync with each other. This helps ensure that spatially adjacent slices processed by different processing engines are processed approximately simultaneously. As an example, keeping the processing of two spatially adjacent slices on two different processing engines 216 of the shared cache subsystem 220 close in time increases the possibility that graphics data in the cache subsystem 220 that is useful to both slices can be used by different processing engines before being evicted from the cache subsystem 220. The cache subsystem can operate, for example, according to a Least Recently Used (LRU) cache eviction policy. Other cache eviction policies can be used.

[0065] Figure 7 Also shown are "allocation thresholds" and "load thresholds." These are thresholds for the number of slices in the queue and are used to control the allocation mode in which allocation unit 224 operates, as described below. The allocation threshold is higher than the load threshold. For example, the allocation threshold could be four, and the load threshold could be two, but in other examples, the thresholds could take different values. The maximum value, allocation threshold, and load threshold can be fixed or variable. As will become apparent from the following description, if the queue is in Figure 7 If the state shown (having at least one queue greater than the allocation threshold and no queue less than the loading threshold) is reached, then no slice will be allocated to the processing engine at that time, and the processing engine will continue to process the slices queued for the processing engine.

[0066] refer to Figure 8 The flowchart shown illustrates the operation of the fragment allocation unit 224. This fragment allocation unit 224 monitors the state of the queue to determine the allocation mode in which fragments will be allocated to processing engines 216. Initially, when queue 228 is empty, fragment allocation unit 224 operates in space allocation mode. In step S802, fragment blocks are allocated to processing engines 216, as described above, such that spatially adjacent fragment groups are allocated to the corresponding set of processing engines 216 coupled to the same cache subsystem 220. For example, the allocation of a fragment block (e.g., block 500) could result in two fragments being allocated to each of the processing engines 216.

[0067] In step S804, the fragment allocation unit 224 (e.g., allocation logic 226) determines whether all queues are less than or equal to an allocation threshold. In other words, in step S804, the fragment allocation unit 224 (e.g., allocation logic 226) determines whether the number of allocated fragments in each queue in the queues is not greater than the allocation threshold. If it is detected in step S804 that the number of allocated fragments in each queue 228 is not greater than the allocation threshold, then the method proceeds to step S802, and as described above, the allocation process is implemented in the space allocation mode to allocate fragment blocks to the processing engine 216. In this way, fragments are allocated to the processing engine to match the spatial location of the fragments with the structure of the cache system 218. Figure 9 An example is shown in which there is no queue greater than the allocation threshold, causing the method to switch from step S804 to step S802, so that the fragment block is allocated to the processing engine 216 in the space allocation mode.

[0068] In some examples, the difference between the maximum number of partitions that can be included in the queue and the allocation threshold is equal to the number of partitions allocated to each processing engine when a partition block is allocated to a processing engine.

[0069] If at least one queue in queue 228 is greater than the allocation threshold, then no fragment is allocated to a processing engine at that time. In this case, the method proceeds from step S804 to step S806. In step S806, fragment allocation unit 224 (e.g., allocation logic 226) determines whether any queue in the queue is less than the load threshold. In other words, in step S806, fragment allocation unit 224 (e.g., allocation logic 226) determines whether the number of allocated fragments in any queue in the queue is less than the load threshold. If it is detected in step S806 that the number of allocated fragments in any queue in queue 228 is less than the load threshold, then the method proceeds to step S808. In step S808, allocation unit 224 allocates fragments to processing engines in a load-balanced allocation mode. As described above, in a load-balanced allocation mode, fragments can be allocated to processing engines using a view of load balancing across different processing engines. In particular, in a load-balanced allocation mode, different numbers of fragments can be allocated to different processing engines. Figure 10 An example is shown in which at least one of the queues (queues 3 and 5) is less than the load threshold, such that the method proceeds from step S806 to step S808 so that a slice is allocated to processing engine 216 in load balancing distribution mode.

[0070] The workload involved in processing can vary for different slices and is highly dependent on the running application. For example, a game application may often use images where higher-level details are found in some regions (e.g., the center) compared to other regions (e.g., the edges) of the image, making the processing of the central slice involve more work than the processing of the edge slices in the rendering space. For other applications (e.g., for rendering a user interface (UI)), the level of detail may be approximately constant across the entire image, making the processing of all slices involve approximately the same workload. Differences in the number of processes performed on different slices may cause some processing engines to lag behind others in the number of slices they have processed. Over time, these differences can lead to significant differences in the number of slices queued for different processing engines 216. This can result in one or more slices in the queue falling below a load threshold, while one or more different slices in the queue are above an allocation threshold. In this case, a load balancing allocation mode is invoked to resolve the imbalance in the computational load currently queued for different processing engines 216.

[0071] The number of fragments allocated in step S808 can vary in different examples. For instance, in response to detecting that the number of allocated fragments in any queue in step S806 is less than the load threshold, in step S808, in load balancing allocation mode, fragment allocation unit 224 can allocate enough fragments to processing engine 216 to fill each queue in the queue (i.e., make all queues up to the maximum line). This is a simple way to ensure that the current number of fragments in the queues for each processing engine is the same.

[0072] In another example, in step S808, the fragment allocation unit 224 can identify the maximum number of fragments currently in any queue and can allocate fragments to processing engines 216 such that all queues have the identified number of fragments. This is another way to ensure that the number of fragments allocated to each processing engine is the same. This can involve allocating fewer fragments in a load-balanced allocation mode compared to making all queues up to their maximum queue occupancy. Allocating fewer fragments in a load-balanced allocation mode can mean that more fragments can be allocated in a space allocation mode, which can improve cache efficiency, as described above.

[0073] In another example, in step S808, the fragment allocation unit 224 may allocate fragments to the processing engine 216 such that all queues have a number of fragments at least equal to the allocation threshold. In yet another example, in step S808, the fragment allocation unit 224 may allocate fragments to the processing engine 216 such that all queues have a number of fragments at least equal to the load threshold. These examples may result in even fewer fragments being allocated in the load balancing allocation mode, but they may result in step S808 being executed more frequently than in the other previously described examples.

[0074] In some examples, step S808 may involve allocating fragment blocks to processing engines in a load-balanced manner (e.g., allocating different numbers of fragments from blocks to different processing engines). This means that when the allocation mode switches back to space allocation mode, all fragment blocks have already been allocated, which simplifies the process of switching back to space allocation mode.

[0075] If in step S806 it is determined that no queue is smaller than the loading threshold (e.g., if the queue is in...) Figure 7 If the state shown in the diagram is reached, then the method proceeds to step S804. Furthermore, following step S808, the method proceeds to step S804. The method ends when no more slices are allocated to the processing engine 216.

[0076] In the example described above, space allocation mode is used to improve cache efficiency unless the processing of a segment is unbalanced in the sense that one or more of the processing engines risk becoming idle before one or more different processing engines in the processing engine are ready to be allocated a new segment block in space allocation mode. In this case, load balancing allocation mode is used to prevent the processing engines from becoming idle. Therefore, in the trade-off between cache efficiency (achieved by using space allocation mode) and load balancing (achieved by using load balancing allocation mode), segment allocation unit 224 is intended for cache efficiency unless the load plane takes priority over cache efficiency at a point by exceeding a threshold (set by a load threshold). Therefore, segment allocation unit 224 switches to operate in load balancing allocation mode at this time. However, once the load has been rebalanced, segment allocation unit 224 can then switch back to space allocation mode to maintain cache efficiency. Therefore, if the work involved in processing each slice is approximately the same, then the slice allocation unit 224 may be able to operate primarily (possibly proprietaryly) in the space allocation mode; however, if the work involved in processing each slice is significantly different for different slices, then the slice allocation unit 224 may switch to the load balancing allocation mode more frequently to ensure that the load is balanced across different processing engines and to prevent any of the processing engines from becoming idle.

[0077] Figure 5 This illustrates a patch 500 to be allocated to processing engine 216 during an allocation process. The rendering space can include many patches. For example, Figure 11a The rendering space 1100 is shown, comprising 64 tiles arranged in an 8×8 grid. Three of the tiles are designated by reference numerals 1102, 1104, and 1106. Each tile can be a 4×4 tile (such as...). Figure 5 (See block 500 shown). The partition allocation unit 224 can process partition blocks sequentially. Figure 11a The diagram shows that block 1102 is processed first, followed by the next three blocks from the first column (ending with block 1104). Then block 1106 is processed, and subsequently the next three blocks from the second column are processed. The processing sequence can be followed... Figure 11aThe pattern shown (e.g., based on space-fill curves, such as those based on Morton order or Hilbert curves) continues until the first four blocks from each column have been processed. The sequence then repeats from the last four blocks from each column until all patch blocks in the render space 1100 have been processed. In this example, by utilizing a view of the degree to which the spatial positions between consecutively processed patch blocks are maintained, only four blocks are processed from each column before moving to the next column (i.e., the difference in spatial position between two consecutively processed blocks remains relatively small (compared to processing all columns before moving to the next column)), thereby increasing the likelihood that the contents cached after processing one block may be useful for processing the next block.

[0078] Despite the jumps in spatial location between continuously processed blocks Figure 11a The example shown may be relatively small, but there are spatial discontinuities in the sequential locations of consecutive parcel blocks to be processed from the first, fourth, fifth, and eighth blocks of each column of the block. Such discontinuities mean that data stored in cache 218 for a block may be unlikely to be useful for processing the next block in sequence, causing the cache hit rate to potentially decrease when discontinuities exist in the sequence of blocks being processed.

[0079] To address this issue, the segment allocation unit 224 can process segment blocks in a raster scan order. For example, Figure 11b Rendering space 1110 is shown, comprising 64 8×8 tile blocks. Reference numerals 1112, 1114, and 1116 denote three blocks within each tile block. Each tile block can be a 4×4 tile block (such as...). Figure 5 (See block 500 shown). The patch allocation unit 224 can process patch blocks in raster scan order, such that block 1112 is processed first, then the remainder of the first row of blocks is processed, ending with block 1114. Then, the blocks of the next row are processed, starting with block 1116. This process continues for each row of blocks until all patch blocks in the rendering space 1110 have been processed.

[0080] use Figure 11b The order shown exhibits a discontinuity in the spatial location of consecutive region blocks to be processed sequentially from the first and eighth blocks of each row. This implies a difference compared to utilizing... Figure 11a The order shown is compared to have something about Figure 11b The order shown has less concurrency. Less concurrency means a higher cache hit rate. The optimal order for processing fragments can depend on the content of the data being processed.

[0081] In another example, the lines of a block can be processed sequentially (as in...). Figure 11b Similar to the example shown), but alternative lines can be processed in reverse order (i.e., from right to left) (i.e., blocks can be processed in alternating right-to-left writing order). This will further reduce the number of discontinuities in the order in which blocks are processed.

[0082] Generally, the order in which the partition allocation unit 224 processes partition blocks can be any suitable order (e.g., the constraint order defined within the system).

[0083] Figure 12 Another example of a graphics processing system 1200, which can be implemented in hardware (e.g., on an integrated circuit), software, or a combination of both, is shown. This graphics processing system 1200 is similar to the graphics processing system 200 described above. However, in the graphics processing system 1200, multiple HSR modules exist within the HSR unit. The allocation of slices to the processing engine is divided into two levels: in the first level, slices are allocated to the HSR modules, and in the second level, slices from the HSR modules are allocated to the processing engines. In this way, after the HSR has been executed, slices are allocated to the processing engines on a per HSR module basis.

[0084] Specifically, the graphics processing system 1200 includes two parts: a graphics processing unit (GPU) 1202 and memory 2041 and memory 2042. Common reference numerals are shown in the figures. Figure 2 and Figure 12 The same components are used in the same way. The GPU 1202 includes a preprocessing module 206, a patching unit 208, and a rasterization module 1210, wherein the rasterization module 1210 includes a Hidden Surface Removal (HSR) unit 1212, a texturing / shading unit 1214, and a post-processing module 1230. The HSR unit 1212 includes an HSR patch allocation unit 1211 and multiple HSR modules 12130 and 12131. Figure 12 In the example shown, there are two HSR modules 1213, but in other examples, more than two HSR modules 1213 may exist in HSR unit 1212. The HSR module can perform HSR in parallel on different patches. The texturing / shading unit 1214 includes multiple processing engines 1216, each configured to apply one or both of textures and shadows to primitive fragments. The texturing / shading unit 1214 also includes a cache system 1218 configured to store graphics data associated with primitive fragments. The cache system 1218 is a multi-level cache and corresponds to the cache system 218 described above. The cache system 1218 includes multiple level 1 cache subsystems 1220 and level 2 caches 1222. Each cache subsystem 1220 is coupled to a set of processing engines 1216. Figure 12 In the example shown, there are four Level 1 cache subsystems 12200 to 12203. The texturing / shading unit 1214 also includes: a fragment allocation unit 1224, which includes allocation logic 1226; and a collection of queues 1228 for storing indications of fragments allocated to the processing engine. The HSR allocation unit 1211 and the fragment allocation unit 1224 provide a two-tiered fragment allocation system 1200. (See reference...) Figure 13 The operation of HSR partition allocation unit 1211 and partition allocation unit 1224 is described in the context of the operation of the graphics processing system 1200 described in the flowchart shown.

[0085] In step S1302, the geometry processing stage is implemented in the same manner as described above, such that the segmentation unit 208 generates a display list (or control flow) of segments for the rendering space. The display list and primitives are output from the segmentation unit 208 and stored in the memory 2041.

[0086] During the rasterization stage, the display list and graphics data for primitives are provided to the rasterization module 1210. In step S1304, the HSR patch allocation unit 1211 allocates patches to HSR modules 12130 and 12131. In step S1306, HSR modules 12310 and 12131 of the HSR unit 1212 perform hidden surface removal on the primitive fragments of the patches for the rendering space.

[0087] In step S1308, the texturing / shading unit 214 receives graphic data for primitive fragments of HSR performed by the HSR module 1213 of the HSR unit 1212.

[0088] In step S1310, on a per HSR module basis, the partition allocation unit 1224 allocates partitions to the processing engine in one or more allocation modes. These allocation modes may include, for example, the space allocation mode and the load balancing allocation mode described above.

[0089] Steps S1312 and S1318 correspond to steps S410 to S416 described above. Therefore, in step S1312, the graphic data of the primitives present in the slice is stored in the cache system 1218. Specifically, the graphic data of the primitives present in the slice is stored in the cache subsystem 1220 coupled to the cache subsystem 1220 to which the slice has been assigned. In step S1314, the processing engine 1216 processes the primitive fragment by applying one or both of texturing and shading to the primitive fragment. The processing engine 1216 uses the graphic data stored in the cache system 1218 to process the primitive fragment. In step S1316, the post-processing module 1230 may apply post-processing steps (such as filtering, compression, format conversion, gamma compression, color space conversion, or format packing) to the processed primitive fragment output from the texturing / shading unit 1214 to generate pixel data representing the rendered image. In step S1318, pixel data (which may be compressed) is output from post-processing module 1230 and stored in a pixel buffer, for example, in memory 2042.

[0090] In the example described above, cache system 218 (or cache system 1218) includes a Level 2 cache 222 and four Level 1 cache subsystems 2200 to 2203. In other embodiments, the cache system may not include a Level 2 cache or may include more than two levels within a cache hierarchy. Furthermore, other examples may include different numbers of L1 cache subsystems and / or processing engines. For example, a cache subsystem may be coupled to more than two processing engines. Moreover, not all cache subsystems within a cache system are necessarily coupled to more than one processing engine. Furthermore, each processing engine may be coupled to more than one cache subsystem within the cache subsystem. In the example described above, the partition block is a 4×4 partition block (e.g., block 500), but more generally, a partition block can be any suitable size and / or shape. For example, a partition block can be a 6×2 partition block. In this case, twelve processing engines can exist such that when a partition block is allocated, a partition from the block can be allocated to each of the processing engines.

[0091] Figure 14A computer system in which a graphics processing system 200 or 1200 can be implemented is shown. The computer system includes a CPU 1402, a GPU 202, a memory 1404 (which may include memories 2041 and 2042), and other devices 1406 (such as a display 1408, speakers 1410, and a camera 1412). The components of the computer system can communicate with each other via a communication bus 1414. As an example, an application can execute on the CPU 1402 and can send data to the GPU 202 for rendering an image that can be stored in the memory 1404 and / or displayed on the display 1408.

[0092] Generally, any of the functions, methods, techniques, or components (e.g., components of the graphics processing system 202) described above can be implemented in modules using software, firmware, hardware (e.g., fixed logic circuitry), or any combination of these implementations. The terms “module,” “function,” “component,” “block,” “unit,” and “logic” are used herein to generally refer to software, firmware, hardware, or any combination thereof.

[0093] In software implementations, modules, functions, components, or logic represent program code that performs a specified task when executed on a processor (e.g., one or more CPUs). In one example, the described method can be performed by a computer configured with software in a machine-readable form stored on a computer-readable medium. One such configuration of the computer-readable medium is a signal-bearing medium and is therefore configured to transmit instructions (e.g., as a carrier wave) (such as via a network) to a computing device. The computer-readable medium can also be configured as a non-transitory computer-readable storage medium and is therefore not a signal-bearing medium. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk storage, and other memory devices that can use magnetic, optical, and other techniques to store machine-accessible instructions or other data.

[0094] The software may be in the form of a computer program including computer program code for configuring a computer to perform the described methods, or a computer program including computer program code means adapted to perform all steps of any of the methods described herein when the program is run on a computer and where the computer program can be implemented on a computer-readable medium. The program code may be stored on one or more computer-readable media. A characteristic of the technology described herein is its platform independence, meaning that the technology described herein can be implemented on a variety of computing platforms having various processors.

[0095] Those skilled in the art will also recognize that all or part of the functions, techniques, or methods described herein can be performed by dedicated circuits, application-specific integrated circuits (ASICs), programmable logic arrays (PLA), field-programmable gate arrays (FPGAs), etc. For example, modules, functions, components, units, or logic (e.g., components of graphics processing system 202) may include hardware in the form of circuits. Such circuits may include transistors and / or other hardware elements available during the manufacturing process. Such transistors and / or other elements may be used to form circuits or structures that implement and / or contain memory (such as, for example, registers, flip-flops or latches, logical operators (such as Boolean operations), mathematical operators (such as adders, multipliers, shifters), and interconnections). Such elements may be provided as custom circuits or standard cell libraries, macros, or at other levels of abstraction. Such elements may be interconnected in a specific arrangement. Modules, functions, components, units, or logic (e.g., components of graphics processing system 202) may include circuits as fixed functions and circuits that can be programmed to perform one or more functions; such programming may be provided according to firmware or software updates or control mechanisms. In the example, the hardware logic has circuits that implement fixed-function operations, state machines, or processes.

[0096] It is also anticipated that software (such as HDL (Hardware Description Language) software) describing or defining the configuration of hardware that implements the modules, functions, components, units, or logic described above (e.g., components of graphics processing system 202) may be used, such as for designing integrated circuits or configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided on which computer-readable program code, encoded in the form of an integrated circuit definition dataset, is provided, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing system configured to perform any of the methods described herein, or to manufacture a graphics processing system including any of the devices described herein. The IC definition dataset may, for example, be in the form of computer code written in a suitable HDL (such as register transfer level (RTL) code). Figure 15An example of an integrated circuit (IC) manufacturing system 1502 is shown, which includes a layout processing system 1504 and an integrated circuit generation system 1506. The IC manufacturing system 1502 is configured to receive an IC definition dataset (e.g., a graphics processing system as defined in any of the examples described herein), process the IC definition dataset, and generate an IC based on the IC definition dataset (e.g., its implementation as described in any of the examples described herein). The processing of the IC definition dataset configures the IC manufacturing system 1502 to manufacture integrated circuits implementing the graphics processing system as described in any of the examples herein. More specifically, the layout processing system 1504 is configured to receive and process the IC definition dataset to determine a circuit layout. Methods for determining a circuit layout based on an IC definition dataset are known in the art and may, for example, involve synthesizing RTL code to determine the gate-level representation of the circuit to be generated (e.g., in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components)). The circuit layout can be determined based on the gate-level representation of the circuit by determining the location information for the logic components. This can be done automatically or with user intervention to optimize the circuit components. Once the layout processing system 1504 has determined the circuit layout, it can output the circuit component definition to the IC generation system 1506. The IC generation system 1506 generates an IC based on the circuit layout definition, as known in the art. For example, the IC generation system 1506 can implement a semiconductor device manufacturing process to generate an IC, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are progressively created on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask, which can be used in a photolithography process for generating an IC based on the circuit definition. Alternatively, the circuit layout definition provided to the IC generation system 1506 may be in the form of computer-readable code, which the IC generation system 1506 can use to form a suitable mask for use in generating the IC. The different processes performed by the IC manufacturing system 1502 can all be implemented in one location (e.g., by one party). Alternatively, the IC manufacturing system 1502 can be a distributed system, such that some processes in the process can be performed at different locations and by different parties. For example, some of the multiple levels include: (i) synthesizing RTL code representing the IC definition dataset to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) performing the fabrication of the integrated circuit using the mask at different locations and / or in different ways.

[0097] The terms “processor” and “computer” are used herein to refer to any device or part of a device that has processing power such that it can execute all or part of instructions or special circuitry capable of performing functions or methods or any combination thereof.

[0098] When compared with known implementations, implementations of the concepts set forth in this application in devices, apparatuses, modules, and / or systems (and in the methods implemented herein) can result in performance improvements. Performance improvements may include one or more of the following: increased computing performance, reduced latency, increased throughput, and / or reduced power consumption. During the manufacture of such devices, apparatuses, modules, and systems (e.g., in integrated circuits), performance improvements may be traded off against physical implementations, thereby improving the method of manufacture. For example, performance improvements may be traded off against layout area, thereby matching the performance of the implementations but using less silicon. This can be accomplished, for example, by reusing functional blocks in a serialized manner or by sharing functional blocks between elements of the device, apparatus, module, and / or system. Conversely, the concepts set forth in this application that result in improvements in the physical implementations of devices, apparatuses, modules, and systems (such as reduced silicon area) can be exchanged for improved performance. This can be accomplished, for example, by manufacturing multiple instances of modules within a predefined area budget.

[0099] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims. It will be understood that the benefits and advantages described above may relate to one example or multiple examples.

[0100] Without loss of the desired effect, any range or value given herein may be extended or modified, as will be apparent to a person skilled in the art. The steps of the methods described herein may be performed in any suitable order or simultaneously where appropriate. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without loss of the desired effect.

Claims

1. A graphics processing system configured to process primitive fragments using a rendering space further divided into multiple regions, the graphics processing system comprising: Multiple processing engines; as well as A partition allocation unit is configured to operate in multiple allocation modes to allocate partitions to the multiple processing engines, wherein the multiple allocation modes include a space allocation mode and a load balancing allocation mode. The segment allocation unit is configured to switch between the space allocation mode and the load balancing allocation mode by the following operations: For each of the plurality of processing engines, maintain a queue of allocated segments assigned for processing by that processing engine; and Monitor the status of the queue to determine the allocation pattern in which slices will be assigned to the multiple processing engines.

2. The graphics processing system according to claim 1, wherein, The plurality of processing engines are configured to apply one or both of texturing and shading to primitive fragments.

3. The graphics processing system according to claim 1, wherein, The partition allocation unit is configured to use two thresholds for the number of partitions in the queue to control the allocation mode of the partition allocation unit operation, wherein the two thresholds are an allocation threshold and a loading threshold.

4. The graphics processing system according to claim 3, wherein, The allocation threshold is greater than the loading threshold.

5. The graphics processing system according to claim 3, wherein, The allocation threshold and the loading threshold are fixed, and the maximum number of slices that can be allocated to the processing engine at any given time is fixed.

6. The graphics processing system according to claim 1, wherein, In the load balancing distribution mode, the shards are distributed to the multiple processing engines based on their computational load.

7. The graphics processing system of claim 1, further comprising a cache system configured to store graphics data used in processing the primitive fragments, the cache comprising a plurality of cache subsystems, wherein, Each of the plurality of cache subsystems is coupled to a corresponding set of one or more of the plurality of processing engines.

8. The graphics processing system according to claim 7, wherein, In the space allocation mode, spatially adjacent fragment groups are allocated to the plurality of processing engines according to a space allocation scheme that ensures that each of the spatially adjacent fragment groups is allocated to a set of processing engines coupled to the same cache subsystem.

9. The graphics processing system according to claim 1, wherein, In the space allocation mode, the slice allocation unit is configured to allocate slice blocks to the plurality of processing engines in an allocation process, thereby allocating one or more slices from the slice block to each of the plurality of processing engines, wherein the slice block comprises a plurality of spatially adjacent slice groups.

10. The graphics processing system according to claim 9, wherein, The segment allocation unit is configured to process a sequence of segment blocks.

11. The graphics processing system according to claim 9, wherein, For each of the plurality of processing engines, a queue of allocated slices is maintained for processing by that processing engine, and wherein the slice allocation unit is configured to perform an allocation process in the space allocation mode in response to detecting that the number of allocated slices in each queue is not greater than an allocation threshold, thereby allocating slice blocks to the plurality of processing engines.

12. The graphics processing system according to claim 3, wherein, The partition allocation unit is configured to monitor the status of the queues and, in response to detecting that the number of allocated partitions in any queue is less than the loading threshold, allocate partitions to the plurality of processing engines in the load balancing allocation mode.

13. The graphics processing system according to claim 12, wherein, The partition allocation unit is configured to: in response to detecting that the number of allocated partitions in any of the queues is less than the loading threshold, allocate sufficient partitions to the plurality of processing engines in the load balancing allocation mode to fill each queue in the queues.

14. The graphics processing system according to claim 12, wherein, The partition allocation unit is configured to switch back to the space allocation mode once the load on the plurality of processing engines has been rebalanced when operating in the load balancing allocation mode.

15. The graphics processing system according to claim 7, wherein, The cache system is a multi-level cache, wherein the plurality of cache subsystems are level 1 cache subsystems in the multi-level cache, and wherein each cache subsystem in the plurality of cache subsystems is coupled to a corresponding pair of the plurality of processing engines.

16. The graphics processing system according to claim 8, wherein, The spatially adjacent slice group is a 2×2 slice group, and wherein, in the space allocation mode according to the space allocation scheme, the slice allocation unit is configured to: allocate each spatially adjacent slice group to a pair of processing engines coupled to the same cache subsystem, such that each processing engine in the pair of processing engines is allocated two slices from the spatially adjacent slice group.

17. The graphics processing system according to claim 1, wherein, The graphics processing system is configured to render an image, and wherein the plurality of processing engines are configured to output processed primitive fragments for use in generating pixel data representing the rendered image, wherein the graphics processing system includes a repository configured to store the pixel data representing the rendered image.

18. The graphics processing system of claim 1, further comprising a hidden surface removal unit configured to perform hidden surface removal on the primitive fragment, wherein, The hidden surface removal unit includes multiple hidden surface removal modules and an HSR patch allocation unit, wherein the HSR patch allocation unit is configured to allocate patches to the hidden surface removal modules.

19. A computer-readable storage medium storing an integrated circuit definition dataset, the integrated circuit definition dataset configuring the integrated circuit manufacturing system to manufacture a graphics processing system according to any one of claims 1 to 18 when processed in an integrated circuit manufacturing system.

20. A method for processing primitive fragments in a graphics processing system using a rendering space that is further divided into multiple regions, the method comprising: Process primitive fragments at multiple processing engines; as well as The partitions are allocated to the multiple processing engines in multiple allocation modes, including a space allocation mode and a load balancing allocation mode. The method includes switching between the space allocation mode and the load balancing allocation mode. The step of switching between the space allocation mode and the load balancing allocation mode includes: For each of the plurality of processing engines, maintain a queue of allocated segments assigned for processing by that processing engine; and Monitor the status of the queue to determine the allocation pattern in which slices will be assigned to the multiple processing engines.

21. The method according to claim 20, further comprising: In the load balancing distribution mode, shards are allocated to the multiple processing engines based on their computational load.

22. The method according to claim 20, further comprising: Graphics data for use in processing the primitive fragments is stored in a cache system comprising multiple cache subsystems, wherein each cache subsystem is coupled to a corresponding set of the multiple processing engines; and In the space allocation mode, spatially adjacent fragment groups are allocated to the plurality of processing engines according to a space allocation scheme, wherein the space allocation scheme ensures that each of the spatially adjacent fragment groups is allocated to a set of processing engines coupled to the same cache subsystem.

Images