Graphics processing device, method, graphics processor and computer device

Abstract

The application provides a graphics processing device, a method, a graphics processor and a computer device, wherein the graphics processing device comprises a pixel processing pipeline, at least two graphics pipeline clusters and a cache unit corresponding to each graphics pipeline cluster, wherein: the graphics pipeline cluster is configured to cut a rendering task in a geometry data stream to obtain a plurality of data segments, obtain a target data segment from the plurality of data segments, perform a geometry processing process on the target data segment in parallel to obtain a corresponding data segment processing result, and store the data segment processing results belonging to a same subtask to the same cache unit; wherein at least two data segments belonging to the same subtask in the geometry data stream are processed by all or part of the at least two graphics pipeline clusters; the pixel processing pipeline is configured to obtain all data segment processing results of a target subtask from the cache unit and perform a pixel processing process on the target subtask. The application can reduce the probability of memory overflow.

Description

Technical Field

[0001] This application relates to graphics processing technology, and more particularly to a graphics processing apparatus, method, graphics processor, and computer device. Background Technology

[0002] In the field of graphics processing technology, the demand for large-scale and highly complex tasks is constantly increasing. Traditional single-core processing is no longer sufficient to meet the requirements of efficient rendering, and multi-core parallel processing is gradually becoming the industry mainstream. To ensure that multiple cores can independently and efficiently process tasks, each parallel core needs to be configured with a dedicated cache unit to achieve distributed storage of processed data. However, in actual operation, it is difficult to achieve an absolutely balanced task allocation among cores. Some cores need to process more task data, and the corresponding cache unit's memory usage will increase accordingly. At the same time, the objective requirement of memory address alignment will generate a certain amount of redundant memory consumption. These two factors combined result in the total memory usage of all cache units exceeding the theoretically calculated value, increasing the pressure on memory resources and thus increasing the possibility of memory overflow. Memory overflow will cause graphics processing tasks to fail to proceed normally, leading to stuttering, crashes, and other problems, seriously affecting the operational stability of graphics processing devices. Summary of the Invention

[0003] This application provides a graphics processing device, method, graphics processor, and computer equipment that can reduce the data pressure on a single cache unit, thereby reducing the probability of memory overflow and ensuring the stable operation of the graphics processing device.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a graphics processing apparatus, comprising a pixel processing pipeline, at least two graphics pipeline clusters, and cache units corresponding to the graphics pipeline clusters, wherein: the graphics pipeline clusters are configured to cut rendering tasks in a geometric data stream into multiple data segments, obtain a target data segment from the multiple data segments; execute the geometric processing of the target data segment in parallel to obtain the corresponding data segment processing result; and store the data segment processing results belonging to the same subtask in the same cache unit; wherein at least two data segments belonging to the same subtask in the geometric data stream are processed by all or part of the at least two graphics pipeline clusters; the pixel processing pipeline is configured to obtain all data segment processing results of the target subtask from the cache unit and perform the pixel processing of the target subtask.

[0006] This application provides a graphics processing method applied in a graphics processing device, the graphics processing device including a pixel processing pipeline, at least two graphics pipeline clusters, and cache units corresponding to the graphics pipeline clusters respectively; the method includes: cutting a rendering task in a geometric data stream into multiple data segments through the graphics pipeline clusters, obtaining a target data segment from the multiple data segments; executing the geometric processing of the target data segment in parallel to obtain the corresponding data segment processing result; storing the data segment processing results belonging to the same subtask in the same cache unit; wherein at least two data segments belonging to the same subtask in the geometric data stream are all or partly processed by the at least two graphics pipeline clusters; obtaining all data segment processing results of the target subtask from the cache unit through the pixel processing pipeline, and performing the pixel processing of the target subtask.

[0007] This application provides a graphics processor, including the graphics processing device described above.

[0008] This application provides a computer device including the graphics processor described above.

[0009] The embodiments of this application have the following beneficial effects:

[0010] In this embodiment, the geometric data stream is segmented and target data segments are obtained through a graphics pipeline cluster, and the geometric processing is executed in parallel. This fully utilizes the processing power of multiple graphics pipeline clusters, improving the parallelism and efficiency of data processing. Furthermore, the storage objects of the cache units are transformed from the entire rendering task to subtasks, allowing the results to be quickly passed to the pixel processing pipeline via the cache units after the geometry stage completes the subtasks, making data storage and transfer more accurate and efficient. Thus, even if memory address alignment and inter-core task balancing issues may increase the total space used, the data pressure on a single cache unit is reduced compared to previous solutions because the data is distributed across multiple cache units for subtasks. This reduces the probability of memory overflow and ensures the stable operation of the graphics processing device. Attached Figure Description

[0011] Figure 1 This application provides a schematic diagram of a system architecture that employs parallel geometry processing pipelines corresponding to one or more pixel processing pipelines.

[0012] Figure 2 A schematic diagram of a multi-level parallel GPU geometry processing pipeline provided in an embodiment of this application;

[0013] Figure 3 This is a schematic diagram of a first architecture of a graphics processing device provided in an embodiment of this application;

[0014] Figure 4 A schematic diagram illustrating the relationship between geometric data streams and data segments provided in an embodiment of this application;

[0015] Figure 5 This is a schematic diagram of a second architecture of a graphics processing device provided in an embodiment of this application;

[0016] Figure 6 This is a schematic diagram of a third architecture of a graphics processing device provided in an embodiment of this application;

[0017] Figure 7 A flowchart illustrating a graphics processing method provided in an embodiment of this application;

[0018] Figure 8 This is a schematic diagram illustrating the distribution of a data segment according to an embodiment of this application.

[0019] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] In the following description, references to "some embodiments" are made, which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0023] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0024] Tile-Based Rendering (TBR) is a common graphics processing unit (GPU) architecture. TBR divides the rendering task into two parts: the geometry pipeline and the pixel pipeline, with a tile divider in between. The tile divider divides the output (fragments) of the geometry pipeline into tiles within the screen area, testing which tiles each fragment covers and storing the fragment information in a data structure describing the set of fragments within a tile. This data is then written to video memory. In the pixel pipeline, the GPU sequentially reads the fragment data covering the tile from video memory, sends the fragment data to the pixel pipeline, and proceeds with the next rendering task.

[0025] Out of Memory (OOM) is a common problem in TBR architectures, and vendors need to find ways to solve it. This is because a pre-allocated portion of video memory may not be able to hold all the primitive information. Specifically, the geometry pipeline may use techniques such as tessellation and geometry shaders (GS) to inflate the primitives.

[0026] Existing solutions generally try to compress primitive information or pre-allocate a large block of video memory, but this results in wasted video memory. In particularly large scenes, such as when a single draw contains a large number of fragments or has a very large area, even with tessellation or geometry shaders (GS) enabled, video memory overflow can still occur.

[0027] Therefore, how to solve the OOM problem that may occur in the pixel processing pipeline of a multi-core GPU system under the TBR architecture is the technical problem that this application needs to solve.

[0028] Please see Figure 1 This illustrates a system architecture diagram that employs parallel geometry processing pipelines corresponding to one or more pixel processing pipelines. For example... Figure 1As shown, the graphics pipeline cluster includes a first pipeline cluster 110. The input data of the first pipeline cluster 110 is a geometric data stream. The first pipeline cluster 110 includes a primitive distribution module 111, at least one geometry processing pipeline 112, a merging arbitrator 113, and a block divider 114. The primitive distribution module 111 divides the input geometric data stream into multiple parts and sends them to at least one geometry processing pipeline 112 respectively. After the at least one geometry processing pipeline 112 completes its processing, the output data of the at least one geometry processing pipeline 112 is merged by the merging arbitrator 113 in its original order and then enters the block divider 114 for processing. The block divider 114 divides the processed geometric data stream into different blocks of processed geometric data according to a preset block division strategy and caches them in a cache unit 120. Then, at least one parallel pixel processing pipeline 130 reads the processed geometric data of the corresponding blocks from the cache unit 120 to complete the pixel processing process and obtain the final output data.

[0029] It is understandable that the aforementioned graphics pipeline cluster is both a logical concept and a chip physical design concept. Physically, the geometry processing pipelines and modules within the same graphics pipeline cluster are physically located in the same region on the chip die (referring to a single wafer region containing a complete functional unit or a group of related functional units of the chip). Logically, the primitive distribution module and merging arbitrator in the graphics pipeline cluster merge the input and output ends of multiple geometry processing pipelines, thereby allowing at least one geometry processing pipeline to have the same input and output interfaces as the original geometry processing pipeline, which can directly replace the original single geometry processing pipeline to increase throughput.

[0030] In the above scheme, each GPU core has a graphics pipeline cluster, and each graphics pipeline cluster contains multiple geometry processor pipelines. At the front end of these geometry processor pipelines is a primitive distribution module responsible for distributing the input geometry data stream to the geometry processing pipelines within the graphics pipeline cluster. At the end of each geometry processing pipeline is a merging arbiter, which is responsible for reordering the data processed by the multiple geometry processing pipelines within the graphics pipeline cluster and sending it to the downstream modules.

[0031] In some embodiments, a multi-level distribution mode can be adopted, which simultaneously sends the input geometry data stream to multiple GPU cores, enabling the graphics processing pipeline cluster of each GPU core to work, greatly improving the multi-core processing capability for geometry tasks. This distribution mode uses a two-level parallel approach (adding a level to the original) and outputs multiple cache units. The pixel processing pipeline reorders the data from higher levels (between cores), thereby achieving efficient parallel processing across multiple cores.

[0032] Please see Figure 2 This diagram illustrates a multi-layered parallel GPU geometry processing pipeline. The first layer is the Graphics Pipelines Cluster (GPC, also known as GPU core or GPU in some manufacturers), comprising n graphics pipeline clusters from second pipeline cluster 21 to second pipeline cluster 2n. The second layer is the Geometry Processing Pipeline (GPP), which includes at least two geometry processing pipelines. The first second pipeline cluster includes a primitive distribution module unit 211, at least two geometry processing pipelines 212, a merging arbitrator 213, and a block divider 214, ..., the nth second pipeline cluster includes a primitive distribution module unit 2n1, at least two geometry processing pipelines 2n2, a merging arbitrator 2n3, and a block divider 2n4. The output data of each second pipeline cluster can be stored in a corresponding cache unit, such as cache unit 215 for the first second pipeline cluster and cache unit 2n5 for the nth second pipeline cluster. In other words, each GPC can have multiple GPPs. In front of all GPCs, there is a primitive distribution module unit, which is responsible for fetching vertex information from memory and splitting the data stream into two layers of data partitioning and distribution using a fixed algorithm (such as round-robin).

[0033] To facilitate understanding of the above scheme, the following explanation will use an architecture comprising m graphics pipeline clusters, each containing n geometry processing pipelines. The input graph data stream is first uniformly divided into fixed-size primitive clusters (PCs) according to a certain rule. Each primitive cluster is assigned to a graphics pipeline cluster in a round-robin order. For the reading process, there are two methods: one is for each graphics pipeline cluster to read the entire input geometry data stream and discard data that does not belong to its processing needs; the other is for each graphics pipeline cluster to calculate the range of data it needs to process and only read the input geometry data stream within this range.

[0034] Within the graphics pipeline cluster, a primitive block is further divided into n primitive groups, which are then assigned to each geometry processing pipeline. After processing, the primitives are merged and restored in order by a merging arbitrator before being sent to the chunker. The distribution and merging arbitration mechanism is consistent with the aforementioned scheme (it can be distributed using a round-robin method or a dynamic load balancing method), and will not be elaborated further here.

[0035] Finally, each tiler outputs a list of polygons to a unique buffer space for each graphics pipeline cluster. Subsequent pixel processing pipelines (also known as rasterization pipelines or fragment processing pipelines), whether in single-path, multi-path, or multi-path cluster form, will merge and restore the order of the polygon lists output by each graphics pipeline cluster before rasterization.

[0036] Research revealed a problem with this approach: instead of one cache unit, N cache units are now required, where N is the number of graphics pipeline clusters (or GPU cores). Since each cache unit is pre-allocated memory space by the software, more cache units mean a higher probability of memory overflow. Although tasks are distributed across different geometry processing pipelines, theoretically the total cache unit usage should remain the same. However, due to memory address alignment issues and task balancing between cores, the total memory usage exceeds that of a single cache unit in the previous approach.

[0037] This application provides a graphics processing device. This graphics processing device can be applied to computer devices, which can include servers, laptops, tablets, desktop computers, smart TVs, set-top boxes, mobile devices (such as mobile phones, portable video players, personal digital assistants, dedicated messaging devices, portable gaming devices), and other devices with data processing capabilities.

[0038] Figure 3 This is a schematic diagram of a first architecture of a graphics processing device provided in an embodiment of this application, as shown below. Figure 3 As shown, the graphics processing device includes a pixel processing pipeline 33, at least two graphics pipeline clusters 31, and cache units 32 corresponding to each of the graphics pipeline clusters, wherein:

[0039] The graphics pipeline cluster is configured to cut the rendering task in the geometry data stream into multiple data segments, obtain a target data segment from the multiple data segments, execute the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result, and store the data segment processing result belonging to the same subtask in the same cache unit; wherein, at least two data segments belonging to the same subtask in the geometry data stream are processed by all or part of the at least two graphics pipeline clusters;

[0040] The pixel processing pipeline is configured to obtain the processing results of all data segments of the target subtask from the cache unit and perform the pixel processing process of the target subtask.

[0041] In some embodiments, a graphics processing device includes at least two graphics pipeline clusters. Physically, the modules within the same graphics pipeline cluster are physically located in the same region of the chip. That is, different graphics pipeline clusters can be distributed in different locations within the chip.

[0042] In some embodiments, the at least two graphics pipeline clusters included in the graphics processing apparatus described above may employ the same cluster configuration or different cluster configurations. The cluster configuration here is used at least to determine the number of geometry processing pipelines included in the graphics pipeline cluster. For example, when employing the same cluster configuration, different graphics pipeline clusters all include the same number of geometry processing pipelines, and the number of geometry processing pipelines is at least two. When employing different cluster configurations, different graphics pipeline clusters may include different numbers of geometry processing pipelines; wherein, at least one graphics pipeline cluster exists in the graphics processing apparatus, and this graphics pipeline cluster contains at least two geometry processing pipelines. In some cases, the graphics processing apparatus may further include a graphics pipeline cluster containing one geometry processing pipeline.

[0043] In this embodiment, the aforementioned geometric data stream is the raw input data of the graphics processing device. Since the graphics processing device includes at least two parallel graphics pipeline clusters, each graphics pipeline cluster can acquire the geometric data it needs to process.

[0044] Please see Figure 4 This diagram illustrates the relationship between a geometric data stream and data segments, where the geometric data stream 41 represents the raw input data for the graphics processing device. From the perspective of rendering tasks, the geometric data stream 41 may include at least one rendering task 42. Figure 4 An exemplary rendering task is shown, but it can also include other rendering tasks 42. In this embodiment, the geometric data stream is divided into data segments 43. That is, the graphics pipeline cluster can divide the original input geometric data stream into multiple data segments with a data segment order. Here, the data segment order is used to determine the position of each data segment in the original geometric data stream.

[0045] In some embodiments, the boundary between two adjacent subtasks can be determined by the subtask end signal 44, or in other words, the boundary between the last data segment of the previous subtask and the first data segment of the next subtask can be determined.

[0046] In some embodiments, after receiving the geometric data stream, the graphics pipeline cluster can divide the rendering task into multiple data segments based on data characteristics. From the divided data segments, target data segments are selected according to the processing capabilities and task allocation strategy of the graphics pipeline cluster, in preparation for subsequent geometric processing. The aforementioned data characteristics may include, but are not limited to, at least one of the following: number of primitives, number of vertices, and primitive type. Here, primitives are the basic geometric units that constitute the rendered graphics, including the smallest rendering units that can be directly processed by graphics hardware, such as points, lines, and triangles.

[0047] For example, such as Figure 4 As shown, a data segment can include N primitives. The graphics pipeline cluster receives the input geometric data stream, parses the primitive information contained in the data stream, and, based on the preset number of primitives N per data segment, continuously divides the rendering task according to the arrangement order of the primitives, generating multiple data segments containing a fixed number of primitives.

[0048] In some embodiments, the target data segment is a data segment selected by the graphics pipeline cluster from the globally segmented data segment set according to a preset data segment allocation rule and assigned to it for processing. Here, the data segment allocation rule is a pre-defined allocation strategy used to divide the data segment processing scope among multiple graphics pipeline clusters, which can realize the distribution and parallel processing of data segments.

[0049] For a parallel processing architecture of multiple graphics pipeline clusters, a global data segment is divided into ranges using preset allocation rules. This allows each graphics pipeline cluster to independently locate its corresponding data segment, providing a data distribution basis for parallel geometry processing. The process of obtaining the target data segment from the multiple data segments can include: each graphics pipeline cluster performing matching and filtering operations on the globally segmented data segment set according to pre-agreed data segment allocation rules, extracting the data segment allocated to its own processing and using it as the target data segment.

[0050] For example, if there are two graphics pipeline clusters, an odd-even number allocation rule can be used. The first graphics pipeline cluster matches and obtains data segments with even numbers, and the second graphics pipeline cluster matches and obtains data segments with odd numbers, forming their respective target data segments. In this way, a balanced distribution of data segments can be achieved among multiple graphics pipeline clusters, improving the rationality of data scheduling under the parallel processing architecture and providing stable data support for subsequent parallel geometry processing.

[0051] In some embodiments, a graphics pipeline cluster may include at least two geometry processing pipelines. Based on this, the geometry processing process of the target data segment is executed in parallel. Within a single graphics pipeline cluster, multiple geometry processing pipelines within the graphics pipeline cluster are scheduled to synchronously execute the geometry processing flow on the graphics data in the target data segment. Then, the data segment processing result corresponding to the target data segment is output to the cache unit corresponding to the graphics pipeline cluster.

[0052] It should be noted that a subtask is a task unit formed by logically dividing a rendering task, and it consists of at least two data segments. A cache unit corresponding to this graphics pipeline cluster stores the processing results of all target data segments for a subtask.

[0053] In some embodiments, the above-mentioned storage of data segment processing results belonging to the same subtask in the rendering task to the same cache unit can be achieved by at least one of the following methods: During the data segmentation process, a corresponding subtask identifier is added to the data segment; the graphics pipeline cluster performs intra-cluster parallel geometry processing on the target data segment; the affiliation relationship is identified based on the subtask identifier carried by the data segment; and the data segment processing results corresponding to the same subtask are written to the same cache unit of the graphics pipeline cluster. Alternatively, during the data segmentation process, a subtask end signal is inserted between data segments belonging to different subtasks; the graphics pipeline cluster performs intra-cluster parallel geometry processing on the target data segment; the subtask data boundary is identified based on the subtask end signal; and the data segment processing results corresponding to the same subtask within the boundary range are written to the same cache unit of the graphics pipeline cluster. Thus, the data segment processing results belonging to the same subtask can be stored in the same cache unit.

[0054] For example, a rendering task is divided into subtask A and subtask B. Subtask A contains 4 data segments (each containing 5 triangle primitives), and subtask B contains 3 data segments (each containing 5 triangle primitives). During the data segmentation phase, a subtask identifier "1" is added to each of the 4 data segments of subtask A, and a subtask identifier "2" is added to each of the 3 data segments of subtask B. Assume that 3 graphics pipeline clusters are deployed, where cluster 1 processes the 1st and 2nd data segments of subtask A, cluster 2 processes the 3rd and 4th data segments of subtask A, and cluster 3 processes the 3rd data segments of subtask B. Each cluster performs parallel geometric processing on its target data segment to generate the corresponding data segment processing result. After processing, cluster 1 reads the subtask identifier "1" from the data segment processing result and writes the two data segment processing results into its bound cache unit 1. Cluster 2 reads the subtask identifier "1" and writes the two data segment processing results into its bound cache unit 2. Cluster 3 reads the subtask identifier "2" and writes the three data segment processing results into its bound cache unit 3, thereby realizing the operation of storing the data segment processing results of the same subtask into the corresponding cache unit.

[0055] For example, a rendering task is divided into subtask C and subtask D, where subtask C contains 3 data segments (each containing 6 line primitives) and subtask D contains 2 data segments (each containing 6 line primitives). During the data segmentation phase, each graphics pipeline cluster inserts a subtask end signal "END" between the 3 data segments of subtask C and the 2 data segments of subtask D to define the data boundary between the two subtasks. Assuming two graphics pipeline clusters are deployed, cluster 1 processes the 1st and 2nd data segments of subtask C, and cluster 2 processes the 3rd data segment of subtask C and the 2nd data segments of subtask D. Each cluster performs intra-cluster parallel geometry processing on its own target data segment to generate the corresponding data segment. Processing results: After processing, cluster 1 detects an "END" signal after the data segment it processed, determines that the two target data segments it processed belong to the same subtask, and writes the processing results of these two data segments into its bound cache unit 1; cluster 2 detects that in the data segments it processed, there is an "END" signal after the first data segment, and the last two data segments are after the "END" signal. Therefore, it can write the processing result of one data segment corresponding to subtask C into its bound cache unit 2, and then write the processing results of two data segments corresponding to subtask D into its bound cache unit 3, thereby realizing the operation of storing the processing results of data segments of the same subtask into the corresponding cache units.

[0056] The aforementioned pixel processing pipeline is a hardware processing channel in a graphics processing device used to perform pixel-level rendering operations. It consists of multiple pixel processing units connected in series and is responsible for converting geometric processing results into displayable pixel image data.

[0057] To address the issue of scattered data storage after parallel processing of multiple graphics pipeline clusters, and considering that all data segments of a subtask have a clear sequential order, the pixel processing pipeline first determines all the scattered cache units of the data segment processing results corresponding to the target subtask, then completes data reading, sorting and merging in the original order, and finally performs pixel-level rendering to complete the conversion of geometric data to pixel image data, adapting to the complete graphics rendering process, meeting the final requirements of image display, and ensuring the correct order of rendering results.

[0058] In some embodiments, the process of obtaining all data segment processing results of the target subtask from the cache units corresponding to each graphics pipeline cluster and performing pixel processing on the target subtask includes: the pixel processing pipeline first determines the target subtask to be processed and obtains the identification information corresponding to the target subtask; based on the identification information of the target subtask, it determines all cache units where all data segment processing results corresponding to the target subtask are stored (i.e., cache units corresponding to each graphics pipeline cluster that has processed the data segment of the target subtask and which store the data segment processing results of the target subtask); iterates through all the determined cache units and reads the results from each cache unit according to the identification information of the target subtask. The system processes all data segments belonging to the target subtask. After reading, based on the positional order of each data segment in the original geometric data stream (i.e., the inherent positional order of each data segment in the target subtask), it sorts, summarizes, and merges all data segment processing results to obtain the complete geometric output result corresponding to the target subtask. After the geometric output result is generated, the pixel processing pipeline sequentially performs operations such as texture sampling, color calculation, depth testing, transparency blending, and pixel shading on the merged geometric data until the entire pixel processing process of the target subtask is completed. After a single target subtask is processed, other subtasks can be selected sequentially to repeat the above process until the pixel processing of the entire rendering task is completed.

[0059] For example, a rendering task includes subtasks E and F in a sequential order. Subtask E contains three data segments (each containing six primitives), and the order of these three data segments in the original geometric data stream is segment 1, segment 2, and segment 3. Subtask F contains two data segments (each containing six primitives), and the order of these segments is segment 4 and segment 5. Two graphics management clusters are deployed. Cluster 1 processes the first, third, and fifth data segments. The processing results of the first and third data segments (task E) are stored in cache unit 1 of graphics management cluster 1, and the processing result of the fifth data segment (task F) is stored in cache unit 2 of graphics management cluster 1. Cluster 2 processes the second and fourth data segments. The processing result of the second data segment (task E) is stored in cache unit 3 of graphics management cluster 2, and the processing result of the fourth data segment (task F) is stored in cache unit 4 of graphics management cluster 2. When the pixel processing pipeline selects subtask E as the target subtask, it first determines the cache unit that has processed the data segment of subtask E and stores the processing results of the data segment of subtask E based on the identification information corresponding to subtask E. That is, cache unit 1 corresponding to cluster 1 and cache unit 3 corresponding to cluster 2. The pixel processing pipeline accesses cache unit 1 and cache unit 3 respectively. It reads the processing results of two data segments belonging to subtask E from cache unit 1 (corresponding to the first and third segments of the original geometric data stream) and reads the processing result of one data segment belonging to subtask E from cache unit 3 (corresponding to the second segment of the original geometric data stream). After reading, the pixel processing pipeline sorts, summarizes and merges the processing results of the three data segments based on the inherent positional order of the three data segments in the original geometric data stream (segment 1 → segment 2 → segment 3) to finally obtain the complete geometric output result corresponding to subtask E. After the geometric output result is generated, the pixel processing pipeline starts the pixel processing flow and performs operations such as texture sampling, color calculation, depth testing, transparency blending and pixel shading on the merged geometric data in sequence until the entire pixel processing process of subtask E is completed. After subtask E is completed, the pixel processing pipeline selects subtask F as the target subtask and repeats the above process to complete the pixel processing of subtask F. Then, the other subtasks after subtask F continue to repeat the above process until the pixel processing of the entire rendering task is completed.

[0060] Based on the embodiments disclosed in this application, the geometric data stream is segmented and target data segments are obtained through a graphics pipeline cluster, and the geometric processing is executed in parallel. This fully utilizes the processing power of multiple graphics pipeline clusters, improving the parallelism and efficiency of data processing. Furthermore, the storage objects of the cache units are transformed from the entire rendering task to subtasks, allowing the results to be quickly passed to the pixel processing pipeline via the cache units after the geometry stage has processed the subtasks, making data storage and transfer more accurate and efficient. Thus, even if memory address alignment and inter-core task balancing issues may increase the total space used, the data pressure on a single cache unit is reduced compared to previous solutions because the data is distributed and stored in multiple cache units for subtasks. This reduces the probability of memory overflow and ensures the stable operation of the graphics processing device.

[0061] In some embodiments of this application, the pixel processing pipeline is configured to release the cache unit corresponding to the target subtask in response to the completion of the pixel processing process of the target subtask.

[0062] In some embodiments, the pixel processing pipeline is configured to release the cache unit corresponding to the target subtask in the cache unit corresponding to each of the graphics pipeline clusters in response to the pixel processing process of completing the target subtask.

[0063] The cache unit corresponding to the target subtask stores the processing results of all data segments of the target subtask. The first cache unit of this target object corresponds to a graphics pipeline cluster, but there may be cases where a graphics pipeline cluster does not have a cache unit corresponding to the target subtask. Here, the only storage object of the cache unit is the processing result of the data segment of the target subtask, and it does not store related data of other subtasks.

[0064] The aforementioned cache unit release refers to the release operation of the entire cache unit storing the processing results of the target subtask data segment after the pixel processing pipeline completes the pixel processing process of the target subtask. The released cache unit can be reassigned to other subsequent subtasks, rather than just clearing part of the cache space in the cache unit.

[0065] In some embodiments, in response to a signal indicating that the processing of the target subtask pixel has been completed, the pixel processing pipeline releases all previously located cache units that store the processing results of the target subtask data segment. The released cache units can be redistributed to other subsequent subtasks to store the processing results of new subtask data segments.

[0066] For example, based on the above example, the rendering task includes subtasks E and F in sequence. Cluster 1 processes the 1st, 3rd, and 5th data segments, where the processing results of the 1st and 3rd segments of subtask E are stored in cache unit 1 corresponding to cluster 1, and the processing result of the 5th segment of subtask F is stored in cache unit 2 corresponding to cluster 1. Cluster 2 processes the 2nd and 4th data segments, where the processing result of the 2nd segment of subtask E is stored in cache unit 3 corresponding to cluster 2, and the processing result of the 4th segment of subtask F is stored in cache unit 4 corresponding to cluster 2. Once the pixel processing pipeline completes pixel processing for subtask E, it immediately responds to the processing completion signal and releases cache unit 1 (corresponding to cluster 1) and cache unit 3 (corresponding to cluster 2) which store the processing results of the data segment of subtask E. After release, cache unit 1 and cache unit 3 can be reallocated to store the processing results of data segments of other subsequent subtasks (such as new subtasks after subtask F has been processed). After subtask F completes pixel processing, cache unit 2 (corresponding to cluster 1) and cache unit 4 (corresponding to cluster 2) which store the processing results of the data segment of subtask F are released as a whole, realizing the cyclic reuse of cache units.

[0067] Based on the embodiments disclosed in this application, by adopting a subtask-specific cache unit design, the data of the entire rendering task is distributed and stored in multiple cache units for different subtasks. Compared with the traditional scheme of "one cache unit storing the entire rendering task data", the data capacity of a single cache unit is significantly reduced, effectively reducing the data pressure on a single cache unit. Furthermore, a single cache unit will not experience memory overflow due to carrying too much data, thereby reducing the probability of memory overflow for the entire graphics processing device and ensuring stable and continuous operation of the graphics processing device. Each cache unit corresponds to only one subtask. When the subtask completes pixel processing, the cache unit is released as a whole and can be quickly reallocated to subsequent subtasks, improving the reuse rate of cache resources and avoiding waste of cache resources.

[0068] Figure 5 This is a schematic diagram of a second architecture of a graphics processing device provided in an embodiment of this application, such as... Figure 5 As shown, the graphics pipeline cluster 31 includes a primitive distribution module 311 and a parallel geometry processing module 312, wherein:

[0069] The primitive distribution module is configured to cut the geometric data stream into multiple data segments, obtain the target data segment corresponding to the graphics pipeline cluster from the multiple data segments, and send the target data segment to the parallel geometry processing module.

[0070] The primitive distribution module is further configured to send a subtask end signal to the parallel geometry processing module when the subtask to which the data segment belongs ends.

[0071] The parallel geometry processing module is configured to execute the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result; and to store the data segment processing result belonging to the same subtask to the cache unit based on the subtask end signal.

[0072] The primitive distribution module 311 is used for cutting geometric data streams, filtering target data segments, and sending subtask end signals to realize data distribution and scheduling. The parallel geometry processing module 312 is used to receive target data segments and subtask end signals sent by the primitive distribution module 311, perform parallel geometry processing within the cluster, and complete the caching and storage of data segment processing results.

[0073] In some embodiments, each primitive distribution module 311 of the graphics pipeline cluster independently performs the cutting of the geometric data stream. The primitive distribution module 311 synchronously receives the input geometric data stream, parses all primitive information, vertex data and topological relationships contained in the data stream, and continuously divides the rendering task according to the same preset single data segment primitive carrying quantity N and the arrangement order of the primitives, generating multiple discrete data segments containing a fixed number of primitives. After the cutting is completed, the primitive distribution module 311 of the graphics pipeline cluster selects the data segments to be allocated to the current graphics pipeline cluster for processing and marks them as target data segments according to the pre-agreed data segment allocation rules (such as round-robin allocation, sequence number interval allocation, odd and even sequence number allocation, etc.). After the selection is completed, the primitive distribution module 311 sends the selected target data segments one by one to the parallel geometry processing module 312 of the current graphics pipeline cluster to provide adapted data objects for the subsequent geometry processing flow.

[0074] For example, suppose there is a geometric data stream rendering task with one thousand triangular primitives. Two graphics pipeline clusters (cluster 1 and cluster 2) are deployed. The primitive distribution module 311 of each cluster independently performs the segmentation work: both receive and parse the data stream synchronously, and each segment the complete task into ten independent data segments, each encapsulating one hundred triangular primitives, according to the same segmentation rule that a single data segment contains one hundred primitives. Each data segment contains complete geometric information. Then, according to the preset allocation rule (serial numbers 1-5 are processed by cluster 1, and serial numbers 6-10 are processed by cluster 2), the primitive distribution module of cluster 1 selects serial numbers 1-5 as target data segments from the ten data segments it has segmented and sends them to the parallel geometry processing module of cluster 1; the primitive distribution module of cluster 2 selects serial numbers 6-10 as target data segments from the ten data segments it has segmented and sends them to the parallel geometry processing module of cluster 2, realizing differentiated selection and sending of target data segments.

[0075] In some implementation scenarios, each graphics pipeline cluster corresponds to a cache unit. The subtask end signal is a marker signal actively inserted and sent to the parallel geometry processing module 312 by the primitive distribution module 311 after it has detected that all data segments of the previous subtask have been cut. The core function is to inform the parallel geometry processing module that "the previous subtask has ended and the data segment of the next subtask will be sent later", and at the same time stop storing the processing result of the next subtask in the current cluster's unique cache unit.

[0076] Since each cluster is configured with only one cache unit, and this cache unit can only store the processing result of the data segment of one subtask, when it is detected that all data segments of the previous subtask have been cut, a subtask end signal is sent to inform the parallel geometry processing module to stop storing the processing result of the next subtask into the current cache unit. The processing result of the next subtask will be stored after the cache unit is released.

[0077] In some embodiments, when the primitive distribution module 311 of each graphics pipeline cluster cuts the geometric data stream, it synchronously identifies the subtask to which each data segment generated by the cut belongs. When the primitive distribution module detects that all data segments corresponding to the previous subtask have been cut, it immediately inserts a subtask end signal and sends it to the parallel geometry processing module 312 of the current cluster. After receiving the signal, the parallel geometry processing module 312 does not stop the geometry processing of the current subtask, but only stops storing the processing result of the data segment of the next subtask into the current unique cache unit. If the current cache unit still stores the processing result of the previous subtask, the parallel geometry processing module enters a waiting state until the cache unit is read and released by the pixel processing pipeline, and then receives the data segment of the next subtask, performs geometry processing, and stores its processing result.

[0078] For example, based on the aforementioned example, the rendering task includes subtask E (corresponding to data segments 1-3) and subtask F (corresponding to data segments 4-5). Both clusters' primitive distribution modules cut the same geometric data stream. Therefore, after cutting the third segment (the last segment of data in subtask E), both insert and send a subtask end signal. After cutting the third segment, the primitive distribution module of cluster 1 sends a subtask end signal to its own parallel geometry processing module. Upon receiving the signal, the parallel geometry processing module continues processing the first and third segments of data in subtask E, storing the results in a single cache unit 1. Simultaneously, it stops storing the processing results of subtask F in cache unit 1 and enters a waiting state until cache unit 1 is released. Then, it processes the fifth segment of data in subtask F and stores the results. Cluster 2 also employs the same strategy.

[0079] Based on the above embodiments disclosed in this application, the primitive distribution module sends an end signal when the subtask ends, and the parallel geometry processing module stops storing the processing result of the next subtask into the current cache unit. It waits for the cache unit to be released before storing the processing result of the new subtask. This can ensure that the data segment processing results of different subtasks are stored in an orderly manner, avoid data confusion, and help improve the accuracy and stability of rendering task execution.

[0080] In some implementation scenarios, each graphics pipeline cluster corresponds to at least two cache units. Figure 6 This is a schematic diagram of a third architecture of a graphics processing device provided in an embodiment of this application, wherein the graphics pipeline cluster corresponds to at least two of the cache units; as shown Figure 6 As shown, the graphics pipeline cluster 31 corresponds to at least two cache units 32, wherein:

[0081] The parallel geometry processing module is configured to store the data segment processing result of the target data segment into a target cache unit; the target cache unit is the cache unit corresponding to the subtask to which the target data segment belongs among the at least two cache units;

[0082] The parallel geometry processing module is further configured to determine, in response to receiving the subtask end signal, the corresponding cache unit for the next subtask among the at least two cache units.

[0083] The subtask end signal is a marker signal actively inserted and sent to the parallel geometry processing module 312 by the primitive distribution module 311 after it has cut the geometric data stream and identified the subtask to which the data segment belongs. The signal informs the parallel geometry processing module that "all data segments corresponding to the current (previous) subtask have been processed and the subsequently received data segments will belong to the next subtask". This signal also triggers the parallel geometry processing module to perform a cache unit switching operation, which is a key triggering condition to ensure that "one cache unit only stores the data segment processing result of one subtask".

[0084] Since each cache unit can only store the processing result of one subtask's data segment, after processing one subtask, if the parallel geometry processing module needs to process the target data segment of the next subtask, it must determine the corresponding cache unit for the next subtask from the at least two cache units and switch to that cache unit. It can be understood that during the switch, the cache unit is the currently available cache unit in the graphics pipeline cluster. When the primitive distribution module performs geometry data stream cutting, it will determine in real time the subtask to which each data segment generated by the cutting belongs. When the primitive distribution module determines that all data segments corresponding to the previous subtask have been cut (without waiting for the data segment to be sent), it immediately inserts and sends a subtask end signal to inform the parallel geometry processing module to perform subtask switching and cache unit switching. The parallel geometry processing module determines the corresponding cache unit for the next subtask from the at least two cache units. If there is no available cache unit in the current cluster, the parallel geometry processing module enters a waiting state until an available cache unit becomes available. Then, it uses that available cache unit as the corresponding cache unit for the next subtask, receives the data segment of the next subtask, and performs processing.

[0085] In some embodiments, when performing data segmentation, the primitive distribution module 311 of each graphics pipeline cluster determines which subtask the currently generated data segment belongs to. When the primitive distribution module 311 detects that all data segments corresponding to the previous subtask have been segmented (without waiting for data segment filtering and sending to be completed), it immediately inserts a subtask end signal and sends it to the parallel geometry processing module 312 of the current graphics pipeline cluster, clearly informing it that "the previous subtask has ended, and the data segment of the next subtask will be sent subsequently." After receiving the signal, the parallel geometry processing module 312 immediately triggers a buffer unit switching operation, attempting to switch to an idle buffer unit corresponding to the current graphics pipeline cluster; if an idle buffer unit exists, the switch is completed, and it prepares to receive the data segment of the next subtask, perform geometry processing, and store its data segment processing results; if there is no idle buffer unit in the current cluster, it enters a waiting state until a buffer unit is released (such as when the pixel processing pipeline releases the buffer unit after completing the corresponding subtask processing), then the buffer unit switch is completed, and subsequent processing continues.

[0086] For example, based on the above example, the rendering task includes subtask E and subtask F (subtask E first, subtask F second). Subtask E contains 3 data segments (segments 1, 2, and 3 of the original geometric data stream), and subtask F contains 2 data segments (segments 4 and 5 of the original geometric data stream). Since the primitive distribution modules of the two graphics pipeline clusters segment the same geometric data stream, all data segments corresponding to subtask E are segments 1, 2, and 3 of the original geometric data stream. Therefore, the primitive distribution modules of both clusters will insert and send a subtask end signal after cutting the 3rd segment (the last segment of data in subtask E). Specifically, the primitive distribution module of cluster 1 immediately inserts and sends a subtask end signal when it detects that all data segments (segments 1 and 3) corresponding to the previous subtask E have been cut (i.e., after the 3rd segment is cut). Upon receiving the signal, the parallel geometry processing module triggers a buffer unit switch. Since buffer unit 2 in cluster 1 is idle, it switches to buffer unit 2 to prepare to receive the 5th data segment of subtask F, perform geometry processing, and store the data segment processing results. If buffer unit 2 is occupied (no free space), the parallel geometry processing module enters a waiting state until buffer unit 2 is released before completing the switch. Correspondingly, when the primitive distribution module of cluster 2 detects that all data segments (including segments 2 and 3) corresponding to the previous subtask E have been cut (i.e., after the 3rd segment is cut), it inserts and sends a subtask end signal, triggering the parallel geometry processing module to switch to the idle buffer unit 4 to prepare to receive the 4th data segment of subtask F, perform geometry processing, and store the data segment processing results.

[0087] In some embodiments, after receiving the target data segment sent by the primitive distribution module 311, the parallel geometry processing module 312 schedules multiple internal geometry processing pipelines to perform parallel geometry processing on the target data segment; it then summarizes and integrates the output results of all geometry processing pipelines to generate a data segment processing result corresponding to the target data segment. When the parallel geometry processing module 312 receives a subtask end signal sent by the primitive distribution module 311, it does not stop the geometry processing of the current subtask, but continues to complete the remaining data segment processing work of the current subtask, and stores all data segment processing results of the current subtask in the cache unit before the switch; the subtask end signal triggers the parallel geometry processing module to prepare for cache unit switching in advance, and when the next subtask starts geometry processing and generates processing results, it switches to the idle cache unit corresponding to the current graphics pipeline cluster, stores the data segment processing result of the next subtask in the newly switched cache unit, and completes the storage operation.

[0088] It should be noted that the data segment processing result of the current subtask is always stored in the cache unit before the switch, and is only switched to the idle cache unit when the next subtask starts processing and generates a result; at least two data segments corresponding to the same subtask are processed in parallel by at least two graphics pipeline clusters. The parallel geometry processing module of each cluster stores the data segment processing result of the same subtask it processes into its corresponding cache unit before the switch, in order to prepare for the data reading of the subsequent pixel processing pipeline.

[0089] For example, the parallel geometry processing module of cluster 1 receives the target data segments (segments 1, 3, and 5) and the end signals of subtasks E and F sent by the primitive distribution module. When the end signal of subtask E is received, the geometry processing of subtask E is not stopped, and the geometry processing of segments 1 and 3 (subtask E) continues. The data segment processing results are still retained and eventually written to cache unit 1 before the switch of cluster 1. This end signal only triggers the parallel geometry processing module of cluster 1 to prepare for cache unit switching. After receiving the 5th data segment of subtask F and starting the geometry processing of subtask F, it switches to cache unit 2 of cluster 1 and writes the data segment processing results of subtask F to cache unit 2. Similarly, cluster 2 also uses the same strategy to switch cache units.

[0090] Based on the embodiments disclosed in this application, the primitive distribution module independently segments the geometric data stream and filters target data segments, and the parallel geometry processing module processes these target data segments in parallel. This can improve the parallelism of data processing and thus improve the overall processing efficiency. At the same time, the primitive distribution module sends a subtask completion signal to trigger the switching of the cache unit of the parallel geometry processing module, and ensures that the same cache unit stores only the data segment processing result of one subtask. This can avoid data confusion, ensure the orderliness of data storage, and provide an accurate data reading basis for subsequent pixel processing pipelines.

[0091] In some embodiments of this application, the primitive distribution module includes a counter, and the subtask includes a preset threshold number of data segments; the primitive distribution module is configured to count the plurality of data segments using the counter; in response to the counter value reaching the preset threshold, the subtask end signal is generated and sent to the parallel geometry processing module.

[0092] In some embodiments of this application, the primitive distribution module is configured to receive the preset number of primitives configured by the driver.

[0093] The counter is a built-in counting component of the primitive distribution module 311, configured to count each data segment generated by the primitive distribution module in real time. In some embodiments, the counter starts at 0, and increments by 1 for each data segment generated, used to determine whether the subtask has completed the cutting.

[0094] The preset threshold is a pre-configured fixed value used to define the number of data segments contained in a single subtask. The primitive distribution module compares the count with this threshold using a counter to determine whether the subtask has been successfully segmented. In some embodiments of this application, the primitive distribution module is configured to receive the preset threshold configured by the driver. That is, the preset threshold is not fixed and can be flexibly configured by the driver according to the rendering task requirements and hardware resource conditions. After receiving the preset threshold sent by the driver, the primitive distribution module uses it as a standard to perform counting and subtask end signal generation operations.

[0095] In some embodiments, each primitive distribution module 311 of the graphics pipeline cluster independently performs the cutting of the geometric data stream, and each primitive distribution module has a built-in counter, with the initial count value set to 0. Each time a data segment is generated by a primitive distribution module, the module increments the count value of its built-in counter by 1, and simultaneously associates the data segment with its corresponding subtask in real time, with the association relationship determined based on a preset threshold. After the cutting is completed, each primitive distribution module, according to a preset data segment allocation rule, selects the target data segments belonging to the current graphics pipeline cluster from all the data segments it has generated, and sends them one by one to the parallel geometry processing module 312 of the current cluster. The counting process continues until all data segments are cut. The counter can be reset to 0 to start counting again, or it can maintain continuous counting, with the subsequent subtask assignment determined by a threshold range, depending on the subtask switching requirements.

[0096] In some embodiments, when the counter reaches a preset threshold, the primitive distribution module immediately generates a subtask end signal and sends it to the parallel geometry processing module 312 of the current cluster, clearly informing it that "the previous subtask has ended and the data segment of the next subtask will be sent subsequently"; at this time, the counter can be reset to 0 (for recounting the next subtask) or continue counting (the next subtask is determined by the threshold range).

[0097] For example, after cutting the first data segment, the counter value becomes 1; after cutting the second data segment, the count value becomes 2; after cutting the third data segment, the count value becomes 3; after cutting the fourth data segment, the count value becomes 4, and so on. Assuming a preset threshold of 3 (each subtask contains 3 data segments), the primitive distribution modules of both clusters cut the same geometric data stream, and their built-in counters count synchronously. When the primitive distribution modules of both clusters have cut the third data segment, the count values ​​of their respective built-in counters reach the preset threshold of 3. At this point, both primitive distribution modules automatically generate a subtask end signal and send it to their respective parallel geometry processing modules; simultaneously, the counters of both clusters are reset to 0, ready to count the data segments of the next subtask F.

[0098] Based on the embodiments disclosed in this application, the primitive distribution module uses a built-in counter to count the data segments obtained from the cutting process in real time, and generates a subtask end signal based on the comparison between the counter value and a preset threshold. This allows for dynamic tracking of the cutting progress of the subtask and timely notification to the parallel geometry processing module, enabling the parallel geometry processing module to process the subtasks in an orderly manner according to their status. At the same time, by receiving the preset threshold configured by the driver through the primitive distribution module, the number of data segments in the subtask can be flexibly adjusted according to the actual situation, improving the adaptability of the solution to different rendering tasks and hardware resources, and helping to improve the overall processing efficiency and flexibility of the rendering task.

[0099] In some embodiments of this application, the parallel geometry processing module includes at least two geometry processing pipelines and a merging arbiter;

[0100] The primitive distribution module is further configured to divide the target data segment into primitive group data and distribute the primitive group data to the geometry processing pipeline;

[0101] The at least two geometry processing pipelines are configured to perform geometry processing on the corresponding primitive group data in parallel, obtain primitive group processing results, and output the primitive group processing results to the merging arbiter;

[0102] The merging arbiter is configured to merge the processing results of the primitive group data based on the position of the primitive group data in the target data segment, so as to obtain the data segment processing result corresponding to the primitive group data.

[0103] The parallel geometry processing module includes at least two geometry processing pipelines and a merging arbiter. Through parallel processing across multiple pipelines and integration with the arbiter, it improves geometry processing efficiency and result accuracy. Here, each geometry processing pipeline is a parallel processing unit within the parallel geometry processing module, with at least two configured. These pipelines can independently execute geometry processing operations, receive primitive group data sent by the primitive distribution module, perform geometric processing on it, and output the primitive group processing results. Multiple geometry processing pipelines can work synchronously in parallel, improving overall processing efficiency. The merging arbiter is the result integration unit within the parallel geometry processing module. It establishes data connections with all geometry processing pipelines, receives the primitive group processing results output by each pipeline, and can sequentially merge all primitive group processing results based on the original positions of the primitive group data in the target data segment to generate a complete data segment processing result.

[0104] Accordingly, primitive group data consists of data units obtained by splitting the target data segment using the primitive distribution module. Each primitive group contains several consecutive primitive information units and is capable of independent geometric processing. Each primitive group is assigned to a corresponding geometric processing pipeline. The primitive group processing result is the geometric data output by a single geometric processing pipeline after performing geometric processing on the received primitive group data. This data includes primitive information processed by vertex transformation, spatial clipping, and projection operations. The data segment processing result is the complete processing result corresponding to the original target data segment, generated by the merging arbitrator after orderly merging of all primitive group processing results. This result can be directly used for subsequent cache storage and pixel processing, preserving the original data order and integrity of the target data segment.

[0105] In some embodiments, after the primitive distribution module completes the filtering and sending of the target data segment, it further divides the target data segment into several primitive groups. During the division process, the position information of each primitive group in the original target data segment is retained. Then, the divided primitive groups are distributed in a round-robin fashion to each geometry processing pipeline of the parallel geometry processing module (with the goal of balancing the processing load of each geometry processing pipeline). After receiving the corresponding primitive group data, each geometry processing pipeline synchronously and in parallel performs geometry processing operations, completes core processes such as vertex transformation, spatial clipping, and projection operations, generates the corresponding primitive group processing result, and outputs the result synchronously to the merging arbiter, along with the position information of the primitive group data in the original target data segment. After receiving the primitive group processing results and corresponding position information output by all geometry processing pipelines, the merging arbiter sorts and merges all primitive group processing results according to the original order of the primitive group data in the target data segment, and finally generates a complete data segment processing result corresponding to the original target data segment, completing the entire parallel geometry processing process.

[0106] For example, the parallel geometry processing module of the graphics pipeline cluster is configured with three geometry processing pipelines (pipeline 1, pipeline 2, and pipeline 3) and one merging arbiter. The primitive distribution module selects a target data segment containing nine consecutive primitives. The primitive distribution module divides the target data segment into three primitive groups (primitive group 1: primitives 1-3, primitive group 2: primitives 4-6, and primitive group 3: primitives 7-9), and records the position order of each primitive group in the target data segment. Then, primitive group 1 is distributed to pipeline 1, primitive group 2 to pipeline 2, and primitive group 3 to pipeline 3. Three geometry processing pipelines synchronously and in parallel perform geometry processing on their respective received primitive data sets, generating primitive processing result 1, primitive processing result 2, and primitive processing result 3, respectively. They then output their respective processing results and corresponding position information to the merging arbitrator. Upon receiving the results, the merging arbitrator performs ordered merging of the three primitive data sets based on their original position order in the target data segment (primitive 1 → primitive 2 → primitive 3), integrating them into a complete data segment processing result. This result is consistent with the primitive order of the original target data segment and can be directly used for subsequent cache storage and pixel processing.

[0107] Based on the embodiments disclosed in this application, at least two geometry processing pipelines and a merging arbiter are set up through the parallel geometry processing module. The primitive distribution module splits the target data segment into primitive group data and distributes it to each pipeline. After each pipeline processes the primitive group data in parallel, the merging arbiter merges them in an orderly manner to obtain the data segment processing result. Moreover, this architecture design realizes multi-layer parallel processing, which can be specifically decomposed into three related levels: First, parallelism between clusters, that is, multiple graphics pipeline clusters simultaneously process different subtasks and different data segments of the same rendering task in parallel, and each cluster independently executes the geometry processing flow; Second, parallelism between geometry pipelines, that is, within a single parallel geometry processing module... At least two geometry processing pipelines synchronously and in parallel process different primitive group data distributed by the primitive distribution module, improving the processing efficiency within a single cluster; thirdly, multi-level parallelism at the task level, where the rendering task is split into multiple subtasks, each subtask is split into multiple data segments, and each data segment is further split into multiple primitive group data, forming a multi-level split of "rendering task-subtask-data segment-primitive group data", corresponding to multi-level parallelism between clusters and between geometry pipelines, further improving the overall parallelism of graphics rendering. The overall solution can improve the geometry processing capability of the graphics pipeline cluster, indirectly improving the operating efficiency and stability of the graphics processing device, and providing strong support for the graphics rendering process.

[0108] In some embodiments of this application, the graphics pipeline cluster corresponds to at least two cache units; the cache unit is used to store the data segment processing result of a subtask of the graphics pipeline cluster;

[0109] The graphics pipeline cluster is configured to store the data segment processing result of the target data segment to a target cache unit; the target cache unit is the cache unit corresponding to the subtask to which the target data segment belongs among the at least two cache units.

[0110] In this embodiment of the application, considering that a single cache unit cannot adapt to the parallel processing of multiple subtasks, at least two cache units are configured for a single graphics pipeline cluster, so that the graphics pipeline cluster can process multiple subtasks in parallel. Each subtask corresponds to an independent cache unit, thereby improving the parallelism of data storage and processing.

[0111] In some embodiments, at least two cache units can be allocated to each graphics pipeline cluster. All allocated cache units are fixedly associated with their corresponding graphics pipeline clusters, and only receive data segment processing results sent by the parallel geometry processing module of that graphics pipeline cluster, without interacting with other graphics pipeline clusters. That is, a single cache unit corresponds to only one subtask, and this correspondence is determined when the subtask needs to output its processing result.

[0112] In some embodiments, after receiving the target data segment sent by the primitive distribution module, the parallel geometry processing module schedules multiple internal geometry processing pipelines to perform parallel geometry processing on the target data segment. It then aggregates and integrates the outputs of all geometry processing pipelines to generate a data segment processing result corresponding to the target data segment. When a subtask needs to output a data segment processing result, the graphics pipeline cluster searches for an idle cache unit in at least two corresponding cache units. The found idle cache unit is used as the cache unit corresponding to the subtask, establishing a unique correspondence between the two. Subsequently, the parallel geometry processing module writes the data segment processing result into the target cache unit, completing the storage operation. At least two data segments corresponding to the same subtask are processed in parallel by at least two graphics pipeline clusters. Each cluster's parallel geometry processing module stores the data segment processing result of the same subtask it processes into its respective found target cache unit. The cache unit receives and stores the data, but does not receive data segment processing results from other subtasks.

[0113] For example, a graphics processing device deploys two graphics pipeline clusters, each with three cache units, all of which are initially idle. The rendering task is split into subtasks C and D according to preset rules. Subtask C contains three data segments, and subtask D contains two data segments. The primitive distribution modules of both clusters simultaneously cut the same geometric data stream, determine the subtask to which each data segment belongs in real time, filter out the corresponding target data segments, and send them to their respective parallel geometry processing modules. After receiving the target data segments, the parallel geometry processing modules schedule multiple internal geometry processing pipelines to perform parallel geometry processing, and summarize the data segment processing results. When subtask C needs to output the processing results... When the result is obtained, each of the two clusters selects one of its three free buffer units as the target buffer unit for subtask C and writes the data segment processing result of subtask C into the target buffer unit. When subtask D needs to output the processing result, each of the two clusters selects one of its remaining two free buffer units as the target buffer unit for subtask D and writes the data segment processing result of subtask D into the target buffer unit. The buffer units of the two clusters only store the data segment processing results of the corresponding subtasks and do not interfere with each other. The processing results of different data segments of the same subtask are stored in the target buffer units corresponding to the two clusters respectively, in preparation for subsequent pixel processing pipeline reading.

[0114] Based on the above embodiments disclosed in this application, by configuring at least two cache units for a single graphics pipeline cluster and dynamically allocating idle cache units as target cache units according to the needs of subtasks, independent storage of data under parallel processing of multiple subtasks can be achieved without interference, thereby improving the parallelism of data storage and processing and enhancing the graphics processing device's ability to handle complex rendering tasks.

[0115] In some implementation scenarios, the rendering task includes at least a first subtask and a second subtask; the first subtask precedes the second subtask; the parallel geometry processing of the second subtask by the at least two graphics pipeline clusters is executed in parallel with the processing of the first subtask by the pixel processing pipeline; and / or, the parallel geometry processing of the second subtask by the at least two graphics pipeline clusters is executed in parallel with the parallel geometry processing of the first subtask by the at least two graphics pipeline clusters.

[0116] In some embodiments, the rendering task is split into at least two ordered subtasks according to preset rules (the first subtask first, the second subtask second). First, the processing flow of the first subtask is started, and at least two graphics pipeline clusters are scheduled to perform parallel geometric processing on the data segments contained in the first subtask. After the parallel geometric processing of the first subtask is completely completed (written to the cache unit), two processing processes are started simultaneously: one is the pixel processing pipeline starting the processing process of the data segment processing results of the first subtask, and the other is the at least two graphics pipeline clusters starting the parallel geometric processing process of the data segments contained in the second subtask. The two processing processes are executed synchronously and in parallel without interfering with each other until they are completed, and then the subsequent summarization stage is entered, ensuring that the execution order of the first subtask and the second subtask is not disordered, while making full use of hardware resources.

[0117] For example, a graphics processing device is configured with three graphics pipeline clusters and one pixel processing pipeline. A rendering task is split into a first subtask (containing 6 data segments) and a second subtask (containing 4 data segments). The first subtask is executed before the second subtask. First, the three graphics pipeline clusters perform parallel geometric processing on the 6 data segments of the first subtask. After the geometric processing of the first subtask is completed, two processing processes are started simultaneously: on the one hand, the pixel processing pipeline starts pixel-level processing on the processing results of the first subtask; on the other hand, the three graphics pipeline clusters immediately start parallel geometric processing on the 4 data segments of the second subtask.

[0118] In some embodiments, considering the pipeline structure within each graphics pipeline cluster, which includes multiple consecutive hardware processing units, the geometry processing flow can be executed step by step. The rendering task is divided into at least two ordered subtasks according to preset rules (the first subtask comes first, followed by the second subtask). The processing flow of the first subtask is initiated first, scheduling at least two graphics pipeline clusters to perform parallel geometric processing on the data segments contained in the first subtask. After the data segments enter the long pipeline of the graphics pipeline cluster, they are processed sequentially by each hardware unit. When the hardware unit at the front of the pipeline completes the processing of a certain data segment of the first subtask, it can be released without waiting for the subsequent pipeline stages of that data segment to complete, or waiting for all data segments of the first subtask to be processed. It then begins receiving data segments from the second subtask and starts geometric processing on those data segments. At this point, in the graphics pipeline cluster, the hardware unit at the front processes the data segments of the second subtask, while the hardware unit at the back continues to process the data segments of the first subtask. Overall, the parallel geometric processing of the second subtask by at least two graphics pipeline clusters is executed synchronously and in parallel with the parallel geometric processing of the first subtask by at least two graphics pipeline clusters.

[0119] For example, the graphics processing device is configured with three graphics pipeline clusters, each with a long pipeline structure containing four consecutive hardware units: data reception, vertex transformation, spatial clipping, and projection operations. The rendering task is divided into a first subtask (containing six data segments) and a second subtask (containing four data segments), with the first subtask executed before the second subtask. First, the three graphics pipeline clusters perform parallel geometric processing on the six data segments of the first subtask. After the data segments enter the pipeline, they are processed sequentially by the four hardware units. When the two preceding hardware units of "data reception" and "vertex transformation" in the pipeline complete a certain data segment of the first subtask... After the segment is processed, there is no need to wait for the data segment to enter the subsequent "spatial clipping and projection operation" unit, nor is there a need to wait for all data segments of the first subtask to be processed. The two preceding hardware units can be released and start receiving the data segment of the second subtask, and start the "data reception and vertex transformation" processing of the data segment of the second subtask. At this time, in the pipeline of the three graphics pipeline clusters, the preceding hardware units process the data segment of the second subtask, while the subsequent hardware units are still processing the data segment of the first subtask. From the overall perspective, the parallel geometric processing of the second subtask by the three graphics pipeline clusters is executed synchronously and in parallel with the parallel geometric processing of the first subtask.

[0120] Based on the above embodiments disclosed in this application, by splitting the rendering task into ordered subtasks and rationally arranging the processing order of different subtasks by the graphics pipeline cluster and pixel processing pipeline, and by utilizing the internal pipeline structure of the graphics pipeline cluster to enable different subtasks to be processed in parallel at different stages of the pipeline, the parallel processing capability of the hardware can be fully utilized without changing the basic hardware architecture, so that different processing stages can be performed as simultaneously as possible, thereby reducing the overall processing time of the rendering task and improving rendering efficiency.

[0121] In some embodiments, the geometry data stream includes at least two rendering tasks and a rendering task end signal corresponding to each rendering task; the graphics pipeline cluster is further configured to process the next rendering task after processing the rendering task and emptying the graphics pipeline cluster in response to receiving the rendering task end signal.

[0122] Among them, the graphics pipeline cluster receives the geometric data stream. The primitive distribution module cuts and filters the data stream to obtain the target data segment of the current rendering task, and sends it to the parallel geometry processing module for geometry processing. When the primitive distribution module detects that all data segments of the current rendering task have been cut, it extracts and sends the rendering task end signal corresponding to the rendering task to the parallel geometry processing module. After receiving the rendering task end signal, the parallel geometry processing module does not stop the remaining processing work of the current rendering task, but continues to complete the geometry processing, result aggregation and storage of all data segments of the current rendering task, and then starts the evacuation operation of the graphics pipeline cluster. During the evacuation process, all occupied hardware units inside the cluster (such as parallel geometry processing pipelines, cache units, etc.) are released, and the temporary processing data inside the cluster is cleared to ensure that there is no data residue of the current rendering task. After the graphics pipeline cluster completes the evacuation and returns to the ready state, it receives the target data segment of the next rendering task in the geometric data stream, and starts the subsequent processes such as cutting and geometry processing of the next rendering task, and cycles forward in turn until all rendering tasks are processed.

[0123] It should be noted that the rendering task end signal is only used to trigger the graphics pipeline cluster to prepare for the evacuation operation and does not interrupt the processing of the current rendering task. The graphics pipeline cluster must complete the processing of all data of the current rendering task and complete the evacuation operation before it can receive and process the next rendering task, ensuring that the processing processes of different rendering tasks are independent of each other and the data does not interfere with each other, and preparing for the data reading and processing of the subsequent pixel processing pipeline.

[0124] Based on the above embodiments disclosed in the present application, by embedding the rendering task end signal corresponding to each rendering task in the geometric data stream and configuring the graphics pipeline cluster to respond to this signal, first complete all processing of the current rendering task, then evacuate the cluster, release the hardware resources, clear the temporary data, and then process the next rendering task. In this way, the orderly connection of different rendering tasks can be achieved, avoiding data residue and task confusion, ensuring the integrity and independence of the processing process of each rendering task, and further improving the stability and accuracy of the graphics processing device in processing multiple consecutive rendering tasks.

[0125] Figure 7 It is a schematic flowchart of a graphics processing method provided by an embodiment of the present application. This graphics processing method is applied to a graphics processing device. The graphics processing device includes a pixel processing pipeline, at least two graphics pipeline clusters, and cache units corresponding to the graphics pipeline clusters respectively; it will be described in combination with Figure 7 the steps shown.

[0126] Step S701: Through the graphics pipeline cluster, the rendering task in the geometric data stream is cut into multiple data segments, and a target data segment is obtained from the multiple data segments; the geometric processing of the target data segment is executed in parallel to obtain the corresponding data segment processing result; the data segment processing results belonging to the same subtask are stored in the same cache unit; wherein, at least two data segments belonging to the same subtask in the geometric data stream are all or partly processed by the at least two graphics pipeline clusters.

[0127] Step S702: Obtain all data segment processing results of the target subtask from the cache unit through the pixel processing pipeline, and perform the pixel processing process of the target subtask.

[0128] Based on the embodiments disclosed in this application, the geometric data stream is segmented and target data segments are obtained through a graphics pipeline cluster, and the geometric processing is executed in parallel. This fully utilizes the processing power of multiple graphics pipeline clusters, improving the parallelism and efficiency of data processing. Furthermore, the storage objects of the cache units are transformed from the entire rendering task to subtasks, allowing the results to be quickly passed to the pixel processing pipeline via the cache units after the geometry stage has processed the subtasks, making data storage and transfer more accurate and efficient. Thus, even if memory address alignment and inter-core task balancing issues may increase the total space used, the data pressure on a single cache unit is reduced compared to previous solutions because the data is distributed and stored in multiple cache units for subtasks. This reduces the probability of memory overflow and ensures the stable operation of the graphics processing device.

[0129] In some embodiments, the graphics pipeline cluster includes a primitive distribution module and a parallel geometry processing module. The process involves dividing the rendering task in the geometry data stream into multiple data segments using the graphics pipeline cluster, obtaining a target data segment from these multiple data segments, executing the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result, and storing the data segment processing results belonging to the same subtask in the same cache unit.

[0130] The primitive distribution module cuts the geometric data stream into multiple data segments, obtains the target data segment corresponding to the graphics pipeline cluster from the multiple data segments, and sends the target data segment to the parallel geometry processing module.

[0131] The primitive distribution module sends a subtask end signal to the parallel geometry processing module when the subtask to which the data segment belongs ends.

[0132] The parallel geometry processing module executes the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result; based on the subtask end signal, the data segment processing results belonging to the same subtask are stored in the cache unit.

[0133] In some embodiments, the graphics pipeline cluster corresponds to at least two cache units; the parallel execution of the geometric processing of the target data segment by the parallel geometry processing module to obtain the corresponding data segment processing result; and storing the data segment processing results belonging to the same subtask to the cache unit based on the subtask end signal, including:

[0134] The parallel geometry processing module stores the data segment processing result of the target data segment into the target cache unit; the target cache unit is the cache unit corresponding to the subtask to which the target data segment belongs among the at least two cache units; in response to receiving the subtask end signal, the cache unit corresponding to the next subtask is determined among the at least two cache units.

[0135] In some embodiments, the primitive distribution module includes a counter, and the subtask includes a preset threshold number of data segments; the step of sending a subtask end signal to the parallel geometry processing module when the subtask to which the data segment belongs ends includes the primitive distribution module counting the plurality of data segments using the counter; in response to the counter value reaching the preset threshold, generating the subtask end signal and sending the subtask end signal to the parallel geometry processing module.

[0136] In some embodiments, the primitive distribution module is configured to receive the preset number of primitives configured by the driver.

[0137] In some embodiments, the parallel geometry processing module includes at least two geometry processing pipelines and a merging arbiter; the process of dividing the rendering task in the geometry data stream into multiple data segments through a graphics pipeline cluster, obtaining a target data segment from the multiple data segments; executing the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result; and storing the data segment processing results belonging to the same subtask into the same cache unit includes:

[0138] The primitive distribution module divides the target data segment into primitive group data and distributes the primitive group data to the geometry processing pipeline.

[0139] The corresponding primitive group data is geometrically processed in parallel through the at least two geometric processing pipelines to obtain primitive group processing results, and the primitive group processing results are output to the merging arbiter.

[0140] The merging arbiter merges the processing results of the primitive group data based on the position of the primitive group data in the target data segment, thereby obtaining the data segment processing result corresponding to the primitive group data.

[0141] In some embodiments, the graphics pipeline cluster corresponds to at least two cache units; the cache unit is used to store the data segment processing result of a subtask of the graphics pipeline cluster; storing the data segment processing result belonging to the same subtask in the rendering task to the cache unit includes: storing the data segment processing result of the target data segment to the target cache unit through the graphics pipeline cluster; the target cache unit is the cache unit corresponding to the subtask to which the target data segment belongs among the at least two cache units.

[0142] In some embodiments, the method further includes: releasing the cache unit corresponding to the target subtask in response to the pixel processing process of completing the target subtask through the pixel processing pipeline.

[0143] The following describes the application of the graphics processing method provided in the embodiments of this application in a real-world scenario.

[0144] The input data stream (geometric data stream) is essentially composed of multiple rendering tasks. Each rendering task ends with an end signal. When the GPU pipeline receives the end signal, it will complete the rendering task, empty the entire pipeline, and start processing the next rendering task.

[0145] It is important to note that the tile rendering architecture divides the rendering task into two parts: the geometry processing pipeline and the pixel processing pipeline. When rendering task 0 is processed by the geometry processing pipeline, the geometry processing pipeline writes the processed part into the corresponding cache unit 0. After rendering task 0 is completely processed by the geometry processing pipeline, the geometry processing pipeline will start processing rendering task 1 and write the processed data into cache unit 1. At the same time, the pixel processing pipeline will start reading data from cache unit 0 and start processing rendering task 0.

[0146] To address the above issues, this application proposes a hardware-automatic data stream segmentation method. The data segment size of each GPU core's primitive distribution module is set to N (N primitives). It can be stipulated that after every M data segments, the hardware automatically inserts a rendering task end signal, effectively splitting the original large rendering task into several smaller rendering tasks (sub-rendering tasks, or simply subtasks). Furthermore, the granularity of these sub-rendering tasks is aligned with an integer multiple of the data segment size cut by the primitive distribution module (a sub-rendering task includes M data segments).

[0147] In some embodiments, the software pre-configures the granularity of the segmentation, with one sub-rendering task equaling M data segments. Each GPU core's primitive distribution module counts the data segments; when the total reaches M, a hardware-generated rendering task termination signal is inserted. Unlike other embodiments where each rendering task is written to a cache unit, this method writes each segmented sub-rendering task to a cache unit. The pixel processing pipeline processes the sub-rendering tasks stored in each cache unit sequentially. Whenever the pixel pipeline finishes processing a sub-rendering task, the corresponding cache unit's memory space is immediately released for use by subsequent rendering tasks.

[0148] For example, in a system with 4 GPU cores, if the sub-rendering task includes 6 data segments (M=6), then the distribution of the data segments can be referenced... Figure 8 As shown. Among them, data segments 0 to 5 belong to sub-rendering task 0, data segments 6 to 11 belong to sub-rendering task 1, and so on.

[0149] Accordingly, the data segments distributed to core 0 include: data segments 0 and 4 of sub-rendering task 0, and data segment 8 of sub-rendering task 1; the data segments distributed to core 1 include: data segments 1 and 5 of sub-rendering task 0, and data segment 9 of sub-rendering task 1; the data segments distributed to core 2 include: data segment 2 of sub-rendering task 0, and data segments 6 and 10 of sub-rendering task 1; the data segments distributed to core 3 include: data segment 3 of sub-rendering task 0, and data segments 7 and 11 of sub-rendering task 1.

[0150] It should be noted that when a sub-rendering task ends, the primitive distribution module inserts a sub-rendering task end signal. This sub-rendering task end signal is distributed to the geometry processing pipeline of each core to inform each core (geometry processing pipeline) that the current sub-rendering task has ended.

[0151] Let's continue with the example above to illustrate the location of the end signal for the sub-rendering task in the data segment.

[0152] Core 0: Data segment 0, Data segment 4, miniRT terminate, Data segment 8, ...;

[0153] Core 1: Data segment 1, data segment 5, miniRT terminate, data segment 9, ...;

[0154] Core 2: Data segment 2, miniRT terminate, data segment 6, data segment 10, ...;

[0155] Core 3: Data segment 3, miniRT terminate, data segment 7, data segment 11, ...

[0156] Among them, miniRT terminate is the end signal for the inserted subtask.

[0157] This application can automatically split rendering tasks via hardware, thereby reclaiming cache units for subtasks and preventing memory overflow. This is purely a hardware-driven process, requiring no software awareness.

[0158] This application provides a graphics processor, including the graphics processing device provided in the above embodiments.

[0159] This application provides a computer device including the graphics processor provided in the above embodiments.

[0160] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0161] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0162] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0163] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0164] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0165] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0166] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0167] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0168] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0169] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0170] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A graphics processing device, characterized in that, The graphics processing device includes a pixel processing pipeline, at least two graphics pipeline clusters, and cache units corresponding to each graphics pipeline cluster, wherein: The graphics pipeline cluster is configured to cut the rendering task in the geometry data stream into multiple data segments, obtain a target data segment from the multiple data segments, execute the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result, and store the data segment processing result belonging to the same subtask in the same cache unit; wherein, at least two data segments belonging to the same subtask in the geometry data stream are processed by all or part of the at least two graphics pipeline clusters; The pixel processing pipeline is configured to obtain the processing results of all data segments of the target subtask from the cache unit and perform the pixel processing process of the target subtask.

2. The graphics processing apparatus according to claim 1, characterized in that, The graphics pipeline cluster includes a primitive distribution module and a parallel geometry processing module, wherein... The primitive distribution module is configured to cut the geometric data stream into multiple data segments, obtain the target data segment corresponding to the graphics pipeline cluster from the multiple data segments, and send the target data segment to the parallel geometry processing module. The primitive distribution module is further configured to send a subtask end signal to the parallel geometry processing module when the subtask to which the data segment belongs ends. The parallel geometry processing module is configured to execute the geometry processing of the target data segment in parallel to obtain the corresponding data segment processing result; and to store the data segment processing results belonging to the same subtask into the same cache unit based on the subtask end signal.

3. The graphics processing apparatus according to claim 2, characterized in that, The graphics pipeline cluster corresponds to at least two of the cache units; The parallel geometry processing module is configured to store the data segment processing result of the target data segment into the target cache unit; The target cache unit is the cache unit corresponding to the subtask to which the target data segment belongs among the at least two cache units; The parallel geometry processing module is further configured to determine, in response to receiving the subtask end signal, the corresponding cache unit for the next subtask among the at least two cache units.

4. The graphics processing apparatus according to claim 2, characterized in that, The primitive distribution module includes a counter, and the subtask includes a preset threshold of data segments; The primitive distribution module is configured to count the plurality of data segments using the counter; In response to the counter value reaching the preset threshold, the subtask end signal is generated and sent to the parallel geometry processing module.

5. The graphics processing apparatus according to claim 4, characterized in that, The primitive distribution module is configured to receive the preset threshold configured by the driver.

6. The graphics processing apparatus according to claim 2, characterized in that, The parallel geometry processing module includes at least two geometry processing pipelines and a merging arbiter; The primitive distribution module is further configured to divide the target data segment into primitive group data and distribute the primitive group data to the geometry processing pipeline; The at least two geometry processing pipelines are configured to perform geometry processing on the corresponding primitive group data in parallel, obtain primitive group processing results, and output the primitive group processing results to the merging arbiter; The merging arbiter is configured to merge the processing results of the primitive group data based on the position of the primitive group data in the target data segment, so as to obtain the data segment processing result corresponding to the primitive group data.

7. The graphics processing apparatus according to any one of claims 1 to 6, characterized in that, The graphics pipeline cluster corresponds to at least two cache units; the cache unit is used to store the data segment processing result of a subtask of the graphics pipeline cluster; The graphics pipeline cluster is configured to store the data segment processing results of the target data segment into the target cache unit; The target cache unit is the cache unit corresponding to the subtask to which the target data segment belongs among the at least two cache units.

8. The graphics processing apparatus according to any one of claims 1 to 6, characterized in that, The pixel processing pipeline is configured to release the cache unit corresponding to the target subtask in response to the completion of the pixel processing process of the target subtask.

9. A graphics processing method, characterized in that, Applied in a graphics processing device, the graphics processing device includes a pixel processing pipeline, at least two graphics pipeline clusters, and cache units corresponding to each of the graphics pipeline clusters; the method includes: The graphics pipeline clusters divide the rendering tasks in the geometric data stream into multiple data segments, and obtain the target data segment from the multiple data segments; the geometric processing of the target data segment is executed in parallel to obtain the corresponding data segment processing result; the data segment processing results belonging to the same subtask are stored in the same cache unit; wherein, at least two data segments belonging to the same subtask in the geometric data stream are processed by all or part of the at least two graphics pipeline clusters; The pixel processing pipeline retrieves all data segment processing results of the target subtask from the cache unit and performs the pixel processing procedure of the target subtask.

10. A graphics processor, characterized in that, The graphics processing apparatus includes any one of claims 1 to 8.

11. A computer device, characterized in that, Includes the graphics processor of claim 10.

Images