Rendering method, system, chip and equipment

Abstract

The invention provides a rendering method and system, a chip and equipment, and relates to the technical field of image rendering. The rendering system comprises a plurality of GPU cores and storage units respectively corresponding to the plurality of GPU cores, the rendering method comprises the following steps: a plurality of GPU cores respectively obtain a control configuration set from corresponding storage units; and the plurality of GPU cores asynchronously execute the tile rendering task based on the control configuration set. According to the scheme, the processing efficiency of the tile rendering task is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of image rendering, and in particular, relate to a rendering method, system, chip and device. BACKGROUND

[0002] A graphics processing unit (GPU) is used to render an image displayed on an electronic device.

[0003] In related technologies, there is a GPU architecture: tile based rendering (TBR). In the TBR architecture, the screen of the electronic device is divided into multiple tiles, and then rendering is performed on a tile-by-tile basis. Specifically, input data streams are first processed by a geometry processing pipeline to generate primitives in the screen, and a tile partitioner then divides the primitives into primitive data in units of tiles. Further, multiple pixel processing pipelines read the tiles and perform tile rendering tasks, thereby obtaining the final rendering result.

[0004] However, in the above related technology, when the tile rendering tasks corresponding to different tiles are uneven, the processing efficiency of the tile rendering tasks will be reduced. SUMMARY

[0005] Embodiments of the present application provide a rendering method, system, chip and device. The technical solutions provided by the embodiments of the present application include the following contents.

[0006] According to an aspect of the embodiments of the present application, a rendering method is provided, the method being applied to a rendering system, the rendering system comprising: a plurality of GPU cores, and a storage unit corresponding to each of the plurality of GPU cores; the method comprising: the plurality of GPU cores respectively acquiring a control configuration set from the storage unit corresponding thereto; the plurality of GPU cores respectively executing a tile rendering task asynchronously based on the control configuration set.

[0007] According to an aspect of the embodiments of the present application, a rendering system is provided, the rendering system comprising: a plurality of GPU cores, and a storage unit corresponding to each of the plurality of GPU cores; the plurality of GPU cores, configured to respectively acquire a control configuration set from the storage unit corresponding thereto; the plurality of GPU cores, further configured to respectively execute a tile rendering task asynchronously based on the control configuration set.

[0008] According to an aspect of the embodiments of the present application, a GPU chip is provided, the GPU chip comprising the above rendering system.

[0009] According to an aspect of the embodiments of the present application, an electronic device is provided, which includes a GPU chip including the rendering system described above.

[0010] The technical solutions provided by the embodiments of the present application can include the following beneficial effects.

[0011] The technical solutions provided by the embodiments of the present application can include the following beneficial effects. The technical solutions provided by the embodiments of the present application can include the following beneficial effects.

[0012]

[0013] Figure 1 is a schematic diagram of a rendering system provided in a possible implementation manner of the present application; Figure 2 is a schematic diagram of a mapping relationship between a tile and a GPU core provided in a possible implementation manner of the present application; Figure 3 is a schematic diagram of a plurality of GPU cores executing tile rendering tasks asynchronously provided in a possible implementation manner of the present application; Figure 4 is a schematic diagram of a rendering task duration comparison provided in a possible implementation manner of the present application; Figure 5 is a flowchart of a rendering method applied to a rendering system provided in a possible implementation manner of the present application; Figure 6 is a simplified structural block diagram of an electronic device provided in a possible implementation manner of the present application. DETAILED DESCRIPTION

[0014] In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.​

[0015] Before introducing the technical solutions proposed in the present application, the following brief description is made of the image rendering technology involved in the related art.

[0016] The TBR architecture, i.e., a tile-based image rendering architecture, is a relatively common GPU architecture. For TBR, the entire rendering process needs to be broken down into the following two steps. In the entire rendering process, a geometry processing pipeline and a pixel processing pipeline are included. The geometry processing pipeline is used to perform geometry processing on the input data stream of a rendering task to generate primitives in the screen. The geometry processing performed by the geometry processing pipeline on the input data stream includes, but is not limited to, at least one of the following aspects: vertex shader, tessellator, geometry shader, viewport transformation, etc. Then, a tile divider in the GPU core performs tile division on the primitives in the screen within the screen range, i.e., calculates which tiles a primitive covers, to obtain multiple pieces of primitive data in the unit of tiles. For each piece of primitive data in a tile, the GPU core concatenates it to generate a tile linked list and stores it in an external memory.

[0017] As can be seen, if it is a multi-core multi-pipeline GPU core system, the system can process multiple tiles in parallel, i.e., different tiles are sent to different pixel processing pipelines of the GPU core for processing, and the pixel processing pipelines of different GPU cores can be processed in parallel.

[0018] It is worth noting that for the input data stream of each rendering task, the geometry processing pipeline is first used to process the input data stream to generate primitives, and then the tile divider is used to send the primitives to the pixel processing pipeline for processing. After the primitives are all divided into tiles, the GPU core sends the multiple pieces of primitive data in the unit of tiles to the pixel processing pipeline and executes the tile rendering task. It can be found that after the input data stream of a rendering task is processed by the geometry processing pipeline and the tile divider, the input data stream of the next rendering task can be sent to the geometry processing pipeline, i.e., the pipeline operation of the geometry processing pipeline and the tile divider can be implemented. However, for the pixel processing pipeline, the completion of a rendering task means that all the tiles covered by the primitives in the entire screen have been processed. Since the primitives in each rendering task are assigned to an arbitrary position in the screen coordinates, there can be up to full-screen tiles containing primitives, i.e., all the tiles in the full screen need to be processed by the pixel processing pipeline.

[0019] For each rendering task, before starting rendering, the system sets the same control configuration for all the pixel processing pipelines of the GPU cores, i.e., all the pixel processing pipelines share the same control configuration, and after the current tile rendering task is completed, the system refreshes a control configuration for the next tile rendering task.

[0020] In summary, for a multi-core system, if multiple GPU cores are enabled, i.e., each GPU core includes a pixel processing pipeline, the following problems will be encountered.

[0021] For each rendering task, all the tiles in the screen are assigned to the pixel processing pipelines of different GPU cores for processing. If the tiles covered by the primitives are unevenly distributed, the tile rendering tasks of the pixel processing pipelines of some GPU cores will be particularly complex, while the tile rendering tasks of the pixel processing pipelines of some other GPU cores will be relatively simple. The above situation will cause an imbalance between different GPU cores, i.e., the pixel processing pipelines of some GPU cores execute tile rendering tasks faster, while the pixel processing pipelines of some other GPU cores execute tile rendering tasks slower.

[0022] Based on the above situation, for each tile rendering task, all the tiles in the screen must be rendered by the pixel processing pipelines of all the GPU cores before the task is completed. When the tile rendering tasks corresponding to different tiles are uneven, a tailing effect will be caused, i.e., even if the pixel processing pipeline of a certain GPU core completes the current tile rendering task first, it still needs to wait for the pixel processing pipelines of other GPU cores to complete before executing the next tile rendering task. That is, the pixel processing pipelines of multiple GPU cores need to be run synchronously, which will eventually cause some GPU cores to be in an idle state between different tile rendering tasks, unable to continue to execute new tile rendering tasks, resulting in a reduction in the processing efficiency of tile rendering tasks.

[0023] Based on the above problems, the present application provides a rendering system. Exemplarily, please refer to Figure 1 , Figure 1 is a schematic diagram of the rendering system provided in a possible implementation manner of the present application.

[0024] In some embodiments, as shown in Figure 1 , the rendering system includes a plurality of GPU cores 110 and a plurality of storage units 120 corresponding to the plurality of GPU cores 110 respectively. Each storage unit 120 includes a control configuration set 130.

[0025] The plurality of GPU cores 110 are configured to respectively acquire the control configuration set 130 from the storage unit 120 corresponding thereto.

[0026] The plurality of GPU cores 110 are further configured to perform the tile rendering task asynchronously based on the control configuration set 130, respectively.

[0027] Exemplarily, each GPU core comprises at least one pixel processing pipeline, and different pixel processing pipelines are configured to perform the tile rendering task in parallel. In some embodiments, the pixel processing pipeline is configured to perform the tile rendering task on the plurality of pieces of tile unit meta data processed by the tile divider to obtain the final rendering result. In some embodiments, each GPU core comprises one or more pixel processing pipelines. The number of pixel processing pipelines in different GPU cores can be the same or different. Exemplarily, the pixel processing pipeline can also be distributed outside the GPU core. Exemplarily, each pixel processing pipeline is configured to process the tile rendering task of a plurality of tiles on the screen. In some embodiments, one GPU core comprises N pixel processing pipelines, i.e., the number of GPU cores corresponding to the N pixel processing pipelines is 1, and N is a positive integer. In some other embodiments, one GPU core comprises 1 pixel processing pipeline, i.e., the number of GPU cores corresponding to the N pixel processing pipelines is N, and N is a positive integer. It is worth noting that the pixel processing pipeline is only an illustrative example, and the present embodiment is not limited in this regard.

[0028] For example, a tile rendering task refers to the pixel processing pipeline of the GPU core performing pixel processing on metadata in units of tiles. In the embodiments of this application, the processing within the pixel processing pipeline can all be referred to as a tile rendering task. In some embodiments, a tile rendering task includes, but is not limited to, at least one of the following processing methods: rasterization, pixel shading, depth testing, stencil testing, and color blending. Rasterization refers to the process of converting primitives in a tile into pixel fragments. Specifically, rasterization determines which pixels are located inside primitives based on the vertex data of primitives in the tile, and generates a pixel fragment for each such pixel; pixel shading refers to calculating the final color value for each pixel fragment generated by rasterization. Specifically, the pixel shader can perform operations such as texture sampling, lighting calculation, and color interpolation, and output the color, transparency, and other attributes of the pixel fragment; depth testing refers to comparing the depth value of the current pixel fragment with the existing depth values ​​stored in the depth buffer to determine whether the current fragment is occluded. Depth testing discards occluded segments, ensuring the accuracy of the final rendering result. Stencil testing uses values ​​stored in the stencil buffer to conditionally evaluate the current pixel segment, enabling special effects such as contour drawing and shadow volume. Color blending combines the color of the current pixel segment with colors stored in the frame buffer. Specifically, color blending uses a preset blending formula (such as transparency-based blending) to combine the color of the new pixel segment with the background color to generate the final display color. It is worth noting that the above tile rendering task is merely illustrative and is not intended to limit the scope of this embodiment.

[0029] For example, the system pre-assigns tiles to be processed by each GPU core, meaning there is a pre-defined mapping relationship between tiles and GPU cores. In some embodiments, the implementation of the above mapping relationship includes, but is not limited to, the following: 1. Register mapping: Each GPU core has a dedicated register to store information about the range of tiles it is responsible for processing, such as the starting coordinates, size, or address of a tile sequence list. When performing a tile rendering task, the GPU core directly reads the above information from its local configuration register to determine the set of tiles to be processed; 2. Lookup table mapping: A tile allocation table is stored in system memory, indexed by tile identifiers. Each entry records the identifier of the GPU core responsible for processing that tile. The GPU core queries the tile allocation table to determine whether a tile belongs to its processing range, thereby determining the set of tiles to be processed; 3. Bitmap mapping: The system allocates a bitmap to each GPU core, where each bit in the bitmap corresponds to a tile (a bit value of 1 indicates that the tile is processed by that GPU core, and 0 indicates that the tile is not processed by that GPU core). The GPU core reads the bitmap to determine the set of tiles to be processed. The establishment of the mapping relationship between the tiles and GPU cores ensures that each GPU core can determine the tiles to be processed before executing the tile rendering task. It is worth noting that the above method is merely illustrative and is not intended to limit the scope of this embodiment.

[0030] In the embodiments of this application, such as Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the mapping relationship between tiles and GPU cores in one possible implementation of this application. Assuming the rendering system includes four GPU cores (GPU core 111, GPU core 112, GPU core 113, and GPU core 114), and the screen coordinates are divided into 16 tiles, the mapping relationship between each tile and different GPU cores can be... Figure 2As shown. For example, if the 16 tiles on the screen are sorted from left to right and from top to bottom, then: tiles with tile numbers 1, 3, 9, and 11 are mapped to GPU core 111, meaning GPU core 111 performs tile rendering tasks on the metadata corresponding to tiles with tile numbers 1, 3, 9, and 11; tiles with tile numbers 5, 7, 13, and 15 are mapped to GPU core 112, meaning GPU core 112 performs tile rendering tasks on the metadata corresponding to tiles with tile numbers 5, 7, 13, and 15. The corresponding image data of each tile is used to perform tile rendering tasks; tiles with tile numbers 2, 4, 10, and 12 are mapped to GPU core 113, that is, GPU core 113 performs tile rendering tasks on the image data corresponding to tiles with tile numbers 2, 4, 10, and 12; tiles with tile numbers 6, 8, 14, and 16 are mapped to GPU core 114, that is, GPU core 114 performs tile rendering tasks on the image data corresponding to tiles with tile numbers 6, 8, 14, and 16.

[0031] For example, the mapping relationship between the tiles and GPU cores is established before the pixel processing pipeline of the GPU core executes the tile rendering task and remains unchanged during the rendering process. This divides each GPU core into non-overlapping processing areas, providing a basis for subsequent asynchronous execution of tile rendering tasks. It is worth noting that the above mapping method and the specific values ​​involved are merely illustrative examples. Those skilled in the art will understand that other schemes that can realize the mapping relationship between tiles and GPU cores also fall within the protection scope of this application, and this embodiment does not limit them.

[0032] In some embodiments, the control configuration set corresponding to the GPU core includes: control configurations assigned to at least one tile rendering task executed by the GPU core, different tile rendering tasks corresponding to different control configurations, and the control configuration of each tile rendering task being used to control the GPU core to execute the tile rendering task.

[0033] In some embodiments, the control configuration set is a collection of control configurations for all tile rendering tasks required by the GPU core during the execution of tile rendering tasks. This set is used to uniformly manage and schedule the execution of each tile rendering task within the GPU core's pixel processing pipeline. In some embodiments, the control configuration set is uniformly configured during the tile rendering task initialization phase and encoded in the data stream. This configuration is generated by the driver at the Central Processing Unit (CPU) and broadcast to each GPU core. Upon receiving the set, each core parses the corresponding control configuration from the data stream, stores it in the corresponding memory unit, and manages it using the hardware within the GPU core. This allows the GPU core to sequentially perform operations such as rasterization, pixel shading, depth testing, stencil testing, and color blending according to the corresponding control configuration in the control configuration set when processing each tile, thereby efficiently and systematically completing the rendering tasks for each tile.

[0034] For example, the storage unit is used to store the control configuration set corresponding to the GPU core. In some embodiments, the storage unit is implemented in the following forms, including but not limited to: System Memory, i.e., main memory. The control configuration is allocated and initialized in system memory by the CPU or driver, and the GPU core accesses and reads the control configuration through the system bus; Global Graphics Memory, where the control configuration is stored in the global graphics memory dedicated to the GPU core, and the GPU core accesses it directly through the internal high-speed bus; Command Buffer, where the control configuration is stored in the form of a command sequence in a specific format in the command buffer maintained by the CPU or GPU core; Configuration Register File, a set of registers dedicated to storing various configuration parameters, which is logically regarded as a storage resource managed by the global controller and shared by all GPU cores. For example, in the embodiments of this application, a storage unit is independently configured for each GPU core, and its specific data structure is embodied as a First-In-First-Out (FIFO) cache. The storage unit is used to store the control configuration of multiple tile rendering tasks to be executed by the corresponding GPU core in sequence, ensuring that the tasks are processed sequentially. It is worth noting that the specific implementation of the storage unit is merely illustrative and is not limited in this embodiment. In this application embodiment, the storage unit generally refers to any physical or logical storage entity that can provide the GPU core with the control configuration set required for performing tile rendering tasks.

[0035] For example, the control configuration is used to instruct the GPU core to perform a tile rendering task. In some embodiments, the control configuration specifically includes parameters and instructions corresponding to each processing stage in the tile rendering task, to drive the GPU core to complete the tile rendering task step by step.

[0036] In one possible implementation of this disclosure, the control configuration set is configured via software and sent to the GPU hardware along with the task flow between the CPU and the GPU, and broadcast to each GPU hardware core.

[0037] For example, in the rasterization process of a tile rendering task, the control configuration includes rasterization control parameters. The pixel processing pipeline converts primitive data into pixel fragments based on these rasterization control parameters. Specifically, the rasterization control parameters include the vertex data of the primitive. For example, the pixel processing pipeline determines which screen pixels in screen space are located inside the primitive based on the vertex data, and generates a pixel fragment for each pixel located inside the primitive, thus completing the conversion from primitive to pixel fragment.

[0038] For example, in the pixel shading process of a tile rendering task, the control configuration includes pointers to the pixel shading procedure and associated descriptors. The pixel processing pipeline performs shading calculations on each pixel fragment generated by rasterization based on the aforementioned pixel shading procedure. For example, the pixel shading procedure instructs the pixel processing pipeline to perform texture sampling, lighting calculations, color interpolation operations, and outputs the color and transparency attributes of the pixel fragment.

[0039] For example, in the depth testing process of a tile rendering task, the control configuration includes depth test control parameters. Based on these parameters, the pixel processing pipeline compares the depth value of the current pixel fragment with existing depth values ​​stored in the storage area corresponding to the tile; exemplarily, the storage area is a depth buffer. Specifically, the depth test control parameters include a depth comparison function. The pixel processing pipeline calculates whether the current pixel fragment is occluded according to this function and discards occluded pixel fragments to ensure the correctness of the final rendering result.

[0040] For example, in the template testing process, which is heavy on tile rendering tasks, the control configuration includes template testing control parameters. The pixel processing pipeline makes conditional judgments based on the template testing parameters and the current pixel fragment. Specifically, the template testing parameters define rules such as template reference values, comparison functions, and corresponding operations for passing or failing the test. The pixel processing pipeline implements special rendering effects such as contour drawing and shadow volume according to these rules.

[0041] For example, in the color blending process of a tile rendering task, the control configuration includes color blending control parameters. Based on these color blending control parameters, the pixel processing pipeline blends the color of a pixel fragment with the color already stored in the frame buffer corresponding to the tile. Specifically, the control parameters include a blending formula; for example, such as a transparency-based blending operation, the pixel processing pipeline blends the pixel fragment color with the background color to generate a new display color.

[0042] In some embodiments, the control configuration set is determined before the input data stream of the tile rendering task enters the GPU core and participates in the pixel processing pipeline when processing the corresponding tiles. The pixel processing pipeline completes pixel processing of the graphic data in units of tiles by performing operations such as rasterization, pixel shading, depth testing, stencil testing, and color blending as indicated by the control configuration set, thus completing the tile rendering task. It is worth noting that the definition of the control configuration set and related operations described above are merely illustrative examples and are not intended to limit the scope of this embodiment.

[0043] In some embodiments, different tile rendering tasks correspond to different control configurations. The essence of this correspondence lies in the fact that each tile rendering task, as an independent rendering task, requires different graphics processing logic and states (such as rasterization rules, shading procedures, testing and blending functions). Therefore, the control configuration is specifically customized according to the rendering needs of the task itself (e.g., whether it deals with opaque geometry or semi-transparent effects, whether it requires complex lighting calculations or simple color filling). For example, a tile rendering task responsible for rendering scene shadow maps might have its control configuration disabled for color blending and load a simplified shading procedure; while another tile rendering task responsible for rendering the user interface (UI) might have its corresponding control configuration including specific transparency blending formulas. It is worth noting that the above tile rendering tasks and corresponding control configurations are merely illustrative examples, and this embodiment does not limit them.

[0044] By adopting the aforementioned control configuration set technology, an accurate correspondence between tile rendering tasks and control configurations can be established for each GPU core, ensuring precise and reliable task scheduling during the rendering process. Simultaneously, the control configuration set supports storing control configurations for multiple tile rendering tasks, allowing GPU cores to switch tasks without waiting for new control configurations to load, reducing the overhead of task switching and improving rendering efficiency.

[0045] For example, such as Figure 3 As shown, Figure 3 This is a schematic diagram illustrating multiple GPU cores asynchronously executing tile rendering tasks, as provided in one possible implementation of this application.

[0046] In some embodiments, the plurality of GPU cores includes a first GPU core 310. The first GPU core 310 is configured to execute a first tile rendering task for a first tile set based on a first control configuration stored in a storage unit 320 corresponding to the first GPU core 310. The first tile rendering task is one of at least one tile rendering task; the first control configuration is the control configuration for the first tile rendering task; the first tile set includes at least one tile processed by the first GPU core; and the plurality of GPU cores execute the first tile rendering task for different tile sets based on the first control configuration stored in their respective storage units.

[0047] After completing the first tile rendering task, the first GPU core 310 executes a second tile rendering task for the first tile set based on the second control configuration stored in the storage unit 320 corresponding to the first GPU core 310. The second tile rendering task is another tile rendering task different from the first tile rendering task among at least one tile rendering task; the second control configuration is the control configuration for the second tile rendering task.

[0048] In some embodiments, the plurality of GPU cores further includes a second GPU core 330. When the first GPU core 310 completes the first tile rendering task, if the second GPU core 330 has not completed the first tile rendering task, the first GPU core 310 begins to execute the second tile rendering task, while the second GPU core 330 continues to execute the first tile rendering task.

[0049] For example, the multiple GPU cores include a first GPU core and a second GPU core. In some embodiments, the first GPU core is any one of the multiple GPU cores, the second GPU core is any one of the multiple GPU cores, and the first GPU core and the second GPU core are two different GPU cores. In the embodiments of this application, the naming of "first" and "second" is intended to describe the relative progress states that may occur during the asynchronous execution of tile rendering tasks by multiple GPU cores, rather than specifically referring to two physical cores with fixed, inherent performance differences. Specifically, when describing the asynchronous execution process, the first GPU core is defined as the GPU core that, within a certain time window, performs the same tile rendering task (e.g., the first tile rendering task) faster than the second GPU core. Conversely, the second GPU core is defined as the GPU core that, within the same time window, performs the same task slower than the first GPU core. The relative speed of the above execution is dynamic and scene-dependent, and its causes include, but are not limited to: different primitive complexity within the tile sets processed by each core, different computational loads for the required visual effects, or differences in system load and resource scheduling. Therefore, the first GPU core and the second GPU core can be physically identical processing units, and their roles may interchange under different tasks or at different points in time. For example, when processing the next tile rendering task (i.e., the second tile rendering task mentioned above), the original second GPU core may become the "first GPU core" (i.e., the faster GPU core) because its task is simpler, while the original first GPU core 310 may become the "second GPU core" (i.e., the slower GPU core) because its task is more complex. It is worth noting that the first GPU core and the second GPU core mentioned above are only illustrative examples, and this embodiment does not limit them.

[0050] In some embodiments, the first GPU core 310 performs a first tile rendering task for the first tile set based on the first control configuration stored in the storage unit 320 corresponding to the first GPU core 310.

[0051] For example, the first tile set refers to the set of at least one tile assigned to a first GPU core for processing during the system's preset phase. Similarly, the second tile set refers to the set of at least one tile assigned to a second GPU core for processing during the system's preset phase. For example, the system pre-assigns tiles to each GPU core for processing. In some embodiments, the above mapping relationship is implemented in ways including but not limited to the following: register mapping, where the GPU core has dedicated registers to store information about the range of tiles it is responsible for processing, such as the starting coordinates, size, or a memory address pointing to a list of tile numbers; lookup table mapping, where a tile allocation table is stored in system memory, indexed by tile identifiers, with each entry recording the identifier of the GPU core responsible for processing that tile. The GPU core determines the tile set by querying this table; bitmap mapping, where the system allocates a bitmap to the GPU core, where each bit in the bitmap corresponds to a tile (a bit value of 1 indicates that the tile is processed by it). The GPU core determines the tile set by reading the bitmap. The above methods ensure that the GPU core can determine the set of tiles it needs to process before executing the tile rendering task. This set is organized as a tile list in the GPU's internal storage area, and the GPU core's pixel processing pipeline processes the tiles in the list sequentially. It is worth noting that the specific implementation and storage method of the tile set are merely illustrative examples and are not limited in this embodiment.

[0052] For example, the first tile rendering task does not refer to a task with different content depending on the core, but rather to a processing flow that all participating GPU cores must execute based on the first control configuration. In some embodiments, for the first GPU core, executing the first tile rendering task means that its internal pixel processing pipeline, according to the parameters and states set by the first control configuration (e.g., specific shader programs, blending equations, test functions, etc.), sequentially executes complete or partial pixel processing pipeline operations from rasterization to final blending for each tile in the first tile set.

[0053] For example, in a specific processing step, the system sets a unified first control configuration for the first tile rendering task (e.g., using a specific pixel shader for color calculation and enabling depth testing). At this time, the task of the first GPU core is to complete the rendering task of its corresponding tile set, i.e., all tiles within the first tile set, based on the aforementioned first control configuration. For example, if the first tile set contains the four tiles in the upper left corner of the screen, the first GPU core will process these four tiles one by one, performing rasterization, shading, testing, and blending rendering tasks for the primitives falling into each tile according to the first control configuration; this is the first tile rendering task.

[0054] For example, the progress of the first GPU core and the second GPU core may differ due to the different tile sets they correspond to. In some embodiments, when all tiles on the screen are assigned to different GPU cores for processing the same rendering task, the tile rendering tasks corresponding to different tile sets are unbalanced. Specifically, the reasons for this imbalance include, but are not limited to: uneven primitive quantity, where some tile sets, such as those located in areas with dense complex models, cover a large number of primitives, while other tiles, such as those located at the edge of the scene or in open areas, may only cover a small number of primitives, or even none at all; different computational complexity, where primitives in some tiles require complex pixel shading calculations such as complex lighting models and a large amount of texture sampling, while primitives in other tiles only require simple color calculations or interpolation; and differences in processing content, where the rendering task of some tiles may involve time-consuming operations, such as transparency blending, multiple iterations of stencil testing, or the execution of complex pixel shader programs, while the rendering task of other tiles may be relatively simple and do not require such operations. The above situations directly lead to the imbalance between the pixel processing pipelines of different GPU cores. GPU cores processing tile sets with lighter workloads execute the first tile rendering task faster via their pixel processing pipelines; conversely, GPU cores processing tile sets with heavier workloads execute the first tile rendering task slower via their pixel processing pipelines. Therefore, in the scenario described in this application's embodiments, because the complexity of the tile rendering task corresponding to the first tile set is less than the complexity of the tile rendering task corresponding to the second tile set, the first GPU core completes the first tile rendering task before the second GPU core. It is worth noting that the reason for the difference in processing speed between the first and second GPU cores described above is merely an illustrative example, and this embodiment does not limit it.

[0055] By configuring a dedicated storage unit for the first GPU core and a first control configuration corresponding to the first tile rendering task, a correspondence between tile rendering tasks and GPU cores is established, ensuring that each GPU core can independently access the control configuration required to execute its tile rendering task. Furthermore, based on the partitioning mechanism of the first tile set, the system can divide the screen area into multiple regions based on GPU cores, laying the foundation for parallel rendering. The advantage of this mechanism lies in achieving resource isolation and parallel processing; each GPU core can independently process the tile set allocated to it, avoiding resource contention and synchronization waiting, and improving the overall throughput of the rendering pipeline.

[0056] In some embodiments, such as Figure 3 As shown, after completing the first tile rendering task, the first GPU core 310 deletes the first control configuration stored in the storage unit 320 corresponding to the first GPU core 310.

[0057] For example, there is a correspondence between storage units and GPU cores, with each GPU core independently managing the control configuration in its corresponding storage unit. In this embodiment, after completing the first tile rendering task, the first GPU core 310 can delete the first control configuration stored in the corresponding storage unit 320. However, for other GPU cores in the rendering system that have not yet completed the first tile rendering task (e.g., the second GPU core 330), the first control configuration stored in their corresponding storage unit (storage unit 340) is still in use and must be retained to ensure that the second GPU core 330 continues to perform the first tile rendering task on the tiles in the second tile set. In some embodiments, the GPU core can delete control configurations in, but not limited to, the following ways: Instruction writing: The GPU core sends a deletion command to the controller of the storage unit, which contains the address or identifier of the control configuration to be deleted. The controller then performs the specific erase or release operation. Address management: In storage units that use data structures such as first-in-first-out queues to manage control configurations, after completing a tile rendering task, the GPU core can logically "remove" the used configuration by moving the head or tail pointer of the queue. Its storage space can then be overwritten by newly enqueued configurations. Marking bit mechanism: A valid bit is set for each control configuration in the storage unit. After the current tile rendering task is completed, the GPU core clears the valid bit corresponding to the control configuration, marking the space occupied by this control configuration as "reclaimable". Direct overwrite: After completing the current tile rendering task, the GPU core can directly write new data (the control configuration for the next tile rendering task) to the memory address where the corresponding control configuration is located, thus achieving deletion. The aforementioned deletion mechanism is general and, in this embodiment, is not limited to the first GPU core or the first control configuration. Any GPU core, after completing its current tile rendering task, will perform a similar deletion or release operation on the control configuration used by that task in its corresponding storage unit. It is worth noting that the above-described method of deleting control configurations is merely illustrative and is not intended to limit the scope of this embodiment.

[0058] By deleting the control configuration stored in the corresponding storage unit after completing the current tile rendering task, redundant control configurations from completed tasks are avoided, improving storage unit space utilization efficiency. Secondly, each GPU core manages only its own storage unit, and its storage release behavior is independent of the state of other GPU cores. This management mechanism makes adding or removing GPU cores in the rendering system easier, allowing the system to efficiently adapt to different scales of parallel processing needs without requiring global synchronization and resource coordination between GPU cores. Finally, timely resource release ensures that the control configurations for subsequent tile rendering tasks can be quickly written, clearing storage obstacles for the GPU core to immediately switch to the next tile rendering task. This maintains a continuous and smooth asynchronous rendering pipeline, reduces tile rendering task switching latency, and improves the processing efficiency of tile rendering tasks.

[0059] For example, after completing the first tile rendering task, the first GPU core, based on the second control configuration stored in the storage unit 320 corresponding to the first GPU core, executes the second tile rendering task for the first tile set. The second GPU core, based on the first control configuration stored in the storage unit corresponding to the second GPU core, executes the first tile rendering task for the second tile set. If the second GPU core has not completed the first tile rendering task while the first GPU core is completing it, the first GPU core begins executing the second tile rendering task, while the second GPU core continues executing the first tile rendering task.

[0060] For example, the triggering of asynchronous execution relies on each GPU core's ability to detect the completion status of its currently executing task. For example, each GPU core contains a task state machine and a tile list pointer. When a GPU core begins executing a tile rendering task, its task state machine is initialized to the "in progress" state, and the tile list pointer is set to point to the starting address of the set of tiles it is responsible for (i.e., the tile list). For example, the GPU core's pixel processing pipeline processes each tile in the tile list sequentially. After rendering each tile, the hardware logic automatically updates the tile list pointer to point to the next tile in the list. When the tile list pointer points to a preset end address or reads a predefined end marker, the hardware circuitry (e.g., a comparator) detects this condition and drives the task state machine to jump from the "in progress" state to the "completed" state. This state transition is, at the hardware level, a valid local event that triggers subsequent behavior. For example, when the GPU core's task state machine transitions to the "completed" state, its scheduling microcode or hardware state machine executes a series of predefined operations to complete the context switch. Specifically, in this embodiment, the first GPU core's predefined operations include: 1. Resource release: The first GPU core sends a command to the controller of the corresponding storage unit to release the memory area occupied by the first control configuration.

[0061] 2. Configuration Acquisition: The first GPU core reads the second control configuration from the corresponding storage unit and loads it into the corresponding configuration register of the pixel processing pipeline.

[0062] 3. State Reset: The first GPU core resets the task state machine to "in progress" and re-points the tile list pointer to the starting address of the first tile set (because the second tile rendering task is still targeting the same set of tiles).

[0063] 4. Task Startup: The pixel processing pipeline of the first GPU core starts executing the second tile rendering task on the first tile set based on the second control configuration.

[0064] Indicatively, in this embodiment of the application, based on the above mechanism, asynchronous operation is achieved between the two GPU cores: First GPU Core: After completing the first tile rendering task, the first GPU core will not enter an idle waiting state, nor will it query the progress of the second GPU core. The first GPU core executes the aforementioned context switching mechanism, deletes the first control configuration, reads the second control configuration preset for the second tile rendering task, and executes the second tile rendering task on the tiles within the first tile set based on the second control configuration. For example, the tile rendering operations defined by the second control configuration (such as post-processing, special effects rendering) are completely different in content and purpose from those defined by the first control configuration (such as basic color rendering), but both operate on the same first tile set.

[0065] Second GPU core: At the same time, since the tile list pointer of the second GPU core has not yet reached the end address of its list, its task state machine remains in the "in progress" state. Therefore, its scheduling logic will not initiate any context switching operation, but will continue to execute the first tile rendering task, that is, process the remaining tiles of its second tile set based on the first control configuration, until the corresponding tile list pointer reaches the end address of its list.

[0066] It is worth noting that the above implementation based on tile list pointers and hardware state machines is merely an illustrative example, and this embodiment does not limit it. Any hardware structure and control method capable of enabling multiple GPU cores to autonomously and asynchronously execute tile rendering tasks based on the control configuration of storage units falls within the protection scope of this application.

[0067] By enabling the first GPU core to immediately execute a second tile rendering task based on a second control configuration stored in the same memory unit after completing the first tile rendering task, seamless task switching is achieved. The key advantage of this design is the elimination of configuration loading latency during task switching. Since the second control configuration is pre-stored in the corresponding memory unit, the GPU core can start a new task without waiting for external configuration data transfer, significantly reducing idle time, ensuring the continuity of the rendering pipeline, and thus effectively improving hardware utilization and execution efficiency.

[0068] By establishing an asynchronous execution mechanism between the first and second GPU cores, true task-level parallelism is achieved. When the first GPU core completes the first tile rendering task and begins executing the second tile rendering task, the second GPU core can still continue executing the unfinished first tile rendering task. The advantage of this mechanism is that the GPU cores can adaptively handle tile sets of different complexities, ensuring that the system does not block the overall rendering process due to a single tile rendering task, thereby maximizing the parallel computing potential of the multi-core GPU architecture and improving rendering efficiency.

[0069] Executing tile rendering tasks asynchronously between GPU cores brings the following benefits: like Figure 4 As shown, Figure 4 This is a schematic diagram showing a comparison of rendering task durations provided in one possible implementation of this application.

[0070] For example, assume that the multiple GPU cores include four GPU cores: GPU core 410, GPU core 420, GPU core 430, and GPU core 440. The tile rendering tasks include tile rendering task 0, tile rendering task 1, tile rendering task 2, and tile rendering task 3.

[0071] In this embodiment, the runtime of each tile rendering task is measured in a uniform time unit, and the runtime values ​​in the following text all represent the same time unit. For example, assume... Figure 4 The runtime of tile rendering task 0 on the four GPU cores is 100, 60, 30, and 15, respectively; the runtime of tile rendering task 1 on the four GPU cores is 15, 70, 60, and 15, respectively; the runtime of tile rendering task 2 on the four GPU cores is 10, 30, 80, and 40, respectively; and the runtime of tile rendering task 3 on the four GPU cores is 20, 35, 10, and 65, respectively.

[0072] In existing technologies, GPU cores need to execute tile rendering tasks synchronously. That is, a tile rendering task can only begin execution after all pixel processing pipelines on different GPU cores have completed. Therefore, the actual execution time of multiple tile rendering tasks is the sum of the maximum execution time of each individual tile rendering task. For example, tile rendering task 0 has an execution time of 100; tile rendering task 1 has an execution time of 70; tile rendering task 2 has an execution time of 80; and tile rendering task 3 has an execution time of 65. Therefore, for... Figure 4 The total runtime of the four tile rendering tasks shown on the four GPU cores is: 100+70+80+65=315.

[0073] This application embodiment executes tile rendering tasks asynchronously among GPU cores. When a tile rendering task is completed first in the pixel processing pipeline of a certain GPU core, that GPU core can immediately execute the next tile rendering task without waiting for other GPU cores. This mechanism allows the pixel processing pipelines of multiple GPU cores to independently complete multiple tile rendering tasks, thereby reducing the total runtime of multiple tile rendering tasks. Specifically, for example: The execution timeline of GPU core 0 is as follows: Tile rendering task 0 (0-100) → Tile rendering task 1 (100-115) → Tile rendering task 2 (115-125) → Tile rendering task 3 (125-145). The execution timeline of GPU Core 1 is as follows: Tile rendering task 0 (0-60) → Tile rendering task 1 (60-130) → Tile rendering task 2 (130-160) → Tile rendering task 3 (160-195). The execution timeline of GPU Core 2 is as follows: Tile rendering task 0 (0-30) → Tile rendering task 1 (30-90) → Tile rendering task 2 (90-170) → Tile rendering task 3 (170-180). The execution timeline of GPU Core 3 is as follows: Tile rendering task 0 (0-15) → Tile rendering task 1 (15-30) → Tile rendering task 2 (30-70) → Tile rendering task 3 (70-135).

[0074] The time it takes for the pixel processing pipeline of the four GPU cores to complete all four tile rendering tasks is the time when GPU core 1 completes tile rendering task 3, that is, the total time is: 195.

[0075] Compared to the total time of 315 required for synchronous execution in existing technologies, the asynchronous execution mechanism of this application reduces the total time of tile rendering tasks and improves the processing efficiency between pixel processing pipelines of GPU cores. Furthermore, in the synchronous execution mechanism, all GPU cores must wait for the slowest GPU core before the tile rendering task is completely completed, resulting in a large amount of computing resources being idle. This application ensures that each GPU core can immediately engage in the next tile rendering task after completing the current one, improving the utilization of computing resources.

[0076] In some embodiments, the storage unit corresponding to the GPU core is used to store the control configuration of at least one tile rendering task assigned to the GPU core for execution in the form of a queue, and the control configuration follows a first-in-first-out access mechanism in the queue.

[0077] For example, the above-mentioned storage unit implements a first-in-first-out (FIFO) storage mechanism in a structure including, but not limited to, the following forms: 1. Circular Buffer Structure: A contiguous storage area is designated as a circular buffer within the memory unit, managed by read and write pointers. The write pointer is maintained by the system side, indicating the next control configuration to be written; the read pointer is maintained by the GPU core, indicating the next control configuration to be read. When the pointer reaches the end of the buffer, it automatically wraps back to the starting address. The empty / full state of the queue is determined by comparing the relative positions of the read and write pointers. 2. Linked List Structure: The queue in the storage unit is implemented using a linked list. Each control configuration is a node, containing the control configuration itself and a pointer to the next node. The system maintains the head and tail pointers of the queue. When a new control configuration is written, a new node is added to the tail of the linked list; when the GPU core reads a configuration, it retrieves the node from the head of the linked list. For example, this structure supports dynamic memory allocation and is not limited by the buffer size; 3. Dual-Port Memory: A dual-port memory supporting simultaneous read and write operations is used as the storage unit. Independent address generators are provided on both the GPU core and system sides. The system-side address generator generates write addresses sequentially; the GPU core-side address generator generates read addresses sequentially. The queue state is managed by comparing the relative positions of the two addresses.

[0078] 4. Registers: A set of registers is used as storage units, and a finite state machine is used to manage the read and write indices. The state machine dynamically updates the head and tail positions of the current queue based on read and write operations, and outputs status signals such as empty or full.

[0079] It is worth noting that the above-described implementation of the storage unit is merely an illustrative example and is not intended to limit the scope of this embodiment.

[0080] In some embodiments, before the GPU core's pixel processing pipeline begins executing the first tile rendering task, the system sequentially writes all control configurations corresponding to all tile rendering tasks into the storage unit. For example, assuming there are N tile rendering tasks, the corresponding first, second, and up to the Nth control configurations are all stored in the storage unit before the first tile rendering task begins. The GPU core reads the control configurations sequentially and executes the corresponding tile rendering tasks. This approach ensures that the tile rendering task execution does not experience waiting due to unprepared control configurations.

[0081] In some embodiments, during the process of the system executing tile rendering tasks in the pixel processing pipeline of the GPU core, control configurations are dynamically written to the storage unit. Exemplarily, since the storage unit is a storage area in the form of a queue, and after the pixel processing pipeline of the GPU core completes the current tile rendering task, the GPU core deletes the corresponding control configuration. Therefore, as long as there is always a control configuration in the storage unit, the pixel processing pipeline of the GPU core can continue to work. Thus, when the GPU core executes the current tile rendering task, the system can prepare subsequent control configurations in parallel. For example, when the pixel processing pipeline of the first GPU core is executing the first tile rendering task based on the first control configuration, the system writes the second control configuration to the storage unit corresponding to the first GPU core. When the first GPU core completes the first tile rendering task and retrieves the second configuration and starts executing the second tile rendering task, the system starts to prepare the third configuration and writes it to the storage unit corresponding to the first GPU core, and so on. This method provides flexibility and is applicable to scenarios where the tile rendering task flow cannot be fully predicted.

[0082] In some embodiments, the system writes multiple control configurations to the storage unit in advance according to a preset batch size. Exemplarily, assume there are a total of N tile rendering tasks. The system does not write all N configurations at once, nor does it strictly write only the next configuration at a time. Instead, a preset quantity K (K is a positive integer greater than 1 and less than N) is set. Before the GPU core starts to execute tile rendering tasks, the system pre-writes the first K control configurations. When the GPU core starts to execute the Mth tile rendering task (M < K), if the system detects that the number of remaining unexecuted control configurations in the storage unit is lower than a preset threshold, a write operation will be triggered to write the subsequent K control configurations (i.e., the M + 1 to M + K configurations) to the corresponding storage unit. This method achieves a balance between determinacy and flexibility: by keeping multiple control configurations in the storage unit at all times, it effectively reduces the risk of the GPU core stalling due to the delay in preparing a single control configuration; at the same time, it avoids storing all control configurations at the beginning, reduces the capacity requirement for the storage unit, and allows the system to dynamically determine the specific content of subsequent control configurations based on the results of the executed tile rendering tasks.

[0083] It should be noted that the above loading strategy of the control configuration is only for illustrative purposes, and this embodiment does not limit it. Any mechanism that can ensure that when the GPU core needs to execute a certain tile rendering task, its corresponding control configuration has been stored in its corresponding storage unit belongs to the protection scope of this application.

[0084] By constructing storage units as a first-in-first-out (FIFO) queue to manage control configurations, an efficient and flexible task provisioning mechanism is provided for the asynchronous execution of GPU cores. This design ensures the sequential execution of tile rendering tasks, with each tile rendering task corresponding to a specific control configuration, reducing the probability of GPU core read errors or failures and enabling efficient pipelined execution between different tile rendering tasks. Furthermore, this design reduces the idle time of GPU cores waiting for control configurations, allowing them to execute tile rendering tasks according to their own progress, thereby improving the utilization of storage units.

[0085] In some embodiments, for a target tile rendering task, multiple GPU cores, provided that the target tile rendering task meets certain conditions, synchronously execute the target tile rendering task after all GPU cores have completed the tile rendering tasks preceding the target tile rendering task. These conditions include: the execution process of the target tile rendering task depends on the execution results of the tile rendering tasks preceding the target tile rendering task by the multiple GPU cores.

[0086] For example, while asynchronous execution between pixel processing pipelines in GPU cores can improve efficiency, in certain scenarios, specific target tile rendering tasks must be executed synchronously to ensure the correctness of the rendering results. This typically occurs when the control configuration of subsequent tile rendering tasks depends on the complete rendering results or global state produced by previous tile rendering tasks. For example, such target tile rendering tasks include, but are not limited to: 1. Post-processing tasks: When the control configuration of a subsequent tile rendering task is defined to perform post-processing operations such as screen space reflections, global illumination, or tone mapping, the control configuration explicitly specifies that it needs to access the complete framebuffer data (such as color, normals, and depth attachments) generated by the previous tile rendering task. If the pixel processing pipelines between GPU cores are not synchronized, the GPU core that is ahead in progress will perform post-processing based on incomplete buffer data, resulting in rendering errors.

[0087] 2. Transparency Rendering: When the control configuration for subsequent tile rendering tasks involves blending semi-transparent objects, the correct execution of its control configuration depends on strictly adhering to the blending order from back to front. If the pixel processing pipelines of each GPU core execute asynchronously, the above blending order cannot be guaranteed, leading to incorrect blending results. Therefore, the control configuration for transparency blending tasks needs to wait for all opaque objects to finish rendering and ensure that the blending order is maintained.

[0088] 3. Global Calculation Tasks: When the control configuration of a tile rendering task is defined as executing a global compute shader (such as calculating the average brightness of the scene), the execution logic of its control configuration depends on aggregating the previous rendering results of all tiles. Such tasks must wait for the previous rendering results of all tiles to be ready before their control configuration can be executed correctly.

[0089] 4. Shadow Resource Update and Usage Tasks: When the control configuration of a tile rendering task involves updating or using shadow maps, the correctness of its control configuration depends on the integrity of the global geometry data or the final state of the shadow map resources. Shadow update tasks require waiting for all GPU cores to complete processing of the geometry data in the metadata, while shadow usage tasks require waiting for the shadow maps to be fully updated.

[0090] To illustrate, target tile rendering tasks that need to be executed synchronously share a common technical characteristic—the generation of their control configuration, or the operational logic defined therein, depends on the rendering results, consistent global state, or eventual shared resources produced by previous tile rendering tasks. When such cross-tile global dependencies exist in the control configuration, asynchronous execution cannot guarantee the correctness of its execution results, and a synchronization mechanism must be introduced.

[0091] It is worth noting that the specific types and application scenarios of the target tile rendering tasks that need to be executed synchronously mentioned above are merely illustrative examples, and this embodiment does not limit them. Any target tile rendering task whose control configuration depends on the execution results of its previous tile rendering tasks falls within the protection scope of the tile rendering tasks that need to be executed synchronously as defined in this application.

[0092] In some embodiments, different synchronous execution mechanisms are employed depending on the specific characteristics of the target tile rendering task. Specifically, they are categorized into the following two types: For example, the first type is a synchronization mechanism where a control configuration depends on the complete rendering results of a previous tile rendering task. When the control configuration of a target tile rendering task requires the complete rendering results of its previous tile rendering tasks to be generated, a delayed generation mechanism for the control configuration is used.

[0093] Specifically, the system does not generate a control configuration for the target tile rendering task until all previous tile rendering tasks are completed. After each GPU core completes its previous tile rendering tasks, it enters an idle waiting state. Once the system detects that all GPU cores have completed their previous tile rendering tasks, it generates the control configuration for the target tile rendering task based on the complete rendering results. The generated control configuration is simultaneously distributed to the storage units corresponding to each GPU core. After detecting the presence of a new control configuration in the storage unit, each GPU core begins to synchronously execute the target tile rendering task. Synchronous execution of each GPU core is achieved through the generation and distribution of the control configuration.

[0094] For example, the second type is a mechanism where the control configuration can be prepared in advance but execution requires synchronization. When the control configuration for the target tile rendering task can be prepared in advance, but its execution process requires synchronization among all GPU cores, a control configuration pre-storage mechanism is adopted.

[0095] Specifically, the control configuration for the target tile rendering task is pre-stored in the storage unit of each GPU core. After completing a previous tile rendering task, each GPU core does not immediately execute the control configuration for the target tile rendering task, even if the storage unit already contains it; instead, each GPU core enters an idle waiting state. For example, in the above synchronization mechanism, the system detects the completion status of each GPU core in the following way: after completing a previous tile rendering task, each GPU core updates the corresponding status bit in its status register (which can be set to 1). The system monitors changes in the status register through polling or interrupts. When it detects that the status bits of all GPU cores indicate completion (i.e., the corresponding status of all GPU cores is 1), it triggers synchronous execution. For example, in the case where the control configuration can be pre-generated, the storage unit uses a queue structure to manage the control configuration, but the execution of the GPU cores is not strictly constrained by the queue order; instead, the configuration is retrieved from the queue and executed only after the synchronization conditions are met.

[0096] It is worth noting that the specific implementation of the above synchronization mechanism is merely illustrative and is not limited in this embodiment. Any scheme that can achieve synchronous execution of multiple GPU cores according to the generation characteristics and execution requirements of the control configuration falls within the protection scope of this application.

[0097] Through the synchronous execution mechanism provided in this embodiment, when a target tile rendering task is determined to require synchronous execution, the system can ensure that the pixel processing pipelines of multiple GPU cores synchronously begin executing the target tile rendering task after completing the previous tile rendering tasks. This synchronization mechanism effectively avoids rendering errors that may result from the different progress of tasks executed by each GPU core, fundamentally guaranteeing the correctness of rendering results for tile rendering tasks with specific dependencies. Furthermore, this mechanism triggers synchronization only during necessary target tile rendering tasks, maintaining asynchronous execution in other situations, thereby maximizing the processing efficiency of tile rendering tasks while ensuring rendering correctness.

[0098] The rendering system proposed in this application equips each GPU core with a dedicated storage unit to independently store a control configuration set, enabling the pixel processing pipelines of each GPU core to asynchronously execute tile rendering tasks based on the aforementioned control configuration set. Even if the uneven distribution of tile rendering tasks across different tiles leads to different execution speeds of tile rendering tasks among the pixel processing pipelines of the GPU cores, the GPU core executing the tile rendering task faster does not need to wait for the slower GPU core and can immediately execute the next tile rendering task based on the control configuration set in its corresponding storage unit. Therefore, when the tile rendering tasks across different tiles are uneven, the rendering system proposed in this application can improve the processing efficiency of tile rendering tasks.

[0099] The technical solutions provided in the embodiments of this application will be described in detail below using method embodiments. For content not described in the method embodiments, please refer to the above embodiments, which will not be repeated here.

[0100] Please refer to Figure 5 The diagram illustrates a flowchart of a rendering method applied to a rendering system, provided in one possible implementation of this application, which may include at least one of the following steps.

[0101] In some embodiments, the rendering system includes: a plurality of graphics processing unit (GPU) cores, and storage units corresponding to each of the plurality of GPU cores.

[0102] Step 510: Each of the multiple GPU cores retrieves its control configuration set from its corresponding storage unit.

[0103] For example, the implementation forms of the storage unit include, but are not limited to, the following: System Memory, i.e., main memory. The control configuration is allocated and initialized in system memory by the CPU or driver, and the GPU core accesses and reads the control configuration through the system bus; Global Graphics Memory, where the control configuration is stored in the global graphics memory dedicated to the GPU core, and the GPU core accesses it directly through the internal high-speed bus; Command Buffer, where the control configuration is stored in the form of a command sequence in a specific format in the command buffer maintained by the CPU or GPU core; Configuration Register File, a set of registers dedicated to storing various configuration parameters, which is logically regarded as a storage resource managed by the global controller and shared by all GPU cores. For example, in the embodiments of this application, each GPU core is independently configured with a storage unit, the specific data structure of which is embodied as a First-In-First-Out (FIFO) cache. The storage unit is used to store the control configuration of multiple tile rendering tasks to be executed by the corresponding GPU core in sequence, ensuring that the tasks are processed sequentially.

[0104] For example, the control configuration set is determined before the input data stream of the rendering task enters the GPU core and participates in the pixel processing pipeline when processing the corresponding tiles. The pixel processing pipeline completes the pixel processing of the graphic data in units of tiles by performing operations such as rasterization, pixel shading, depth testing, stencil testing, and color blending as indicated by the control configuration, thus completing the tile rendering task.

[0105] Step 520: Multiple GPU cores asynchronously execute tile rendering tasks based on the control configuration set.

[0106] In some embodiments, the plurality of GPU cores includes: a first GPU core.

[0107] The first GPU core, based on the first control configuration stored in its corresponding storage unit, executes a first tile rendering task for a first tile set. The first tile rendering task is one of at least one tile rendering task; the first control configuration is the control configuration for the first tile rendering task; the first tile set includes at least one tile processed by the first GPU core; multiple GPU cores, each based on the first control configuration stored in their respective storage units, execute first tile rendering tasks for different tile sets.

[0108] After completing the first tile rendering task, the first GPU core, based on the second control configuration stored in the memory unit corresponding to the first GPU core, executes a second tile rendering task for the first tile set. The second tile rendering task is another tile rendering task, distinct from the first tile rendering task, within at least one tile rendering task; the second control configuration is the control configuration for the second tile rendering task.

[0109] In some embodiments, the plurality of GPU cores further includes a second GPU core. After the first GPU core completes the first tile rendering task, if the second GPU core has not completed the first tile rendering task, the first GPU core begins to execute the second tile rendering task, while the second GPU core continues to execute the first tile rendering task.

[0110] For example, the multiple GPU cores include a first GPU core and a second GPU core. In some embodiments, the first GPU core is any one of the multiple GPU cores, the second GPU core is any one of the multiple GPU cores, and the first GPU core and the second GPU core are two different GPU cores. In the embodiments of this application, the naming of "first" and "second" is intended to describe the relative progress states that may occur during the asynchronous execution of tile rendering tasks by multiple GPU cores, rather than specifically referring to two physical cores with fixed, inherent performance differences. Specifically, when describing the asynchronous execution process, the first GPU core is defined as the GPU core that, within a certain time window, performs the same tile rendering task (e.g., the first tile rendering task) faster than the second GPU core. Conversely, the second GPU core is defined as the GPU core that, within the same time window, performs the same task slower than the first GPU core. The relative speed of the above execution is dynamic and scene-dependent, and its causes include, but are not limited to: different primitive complexity within the tile sets processed by each core, different computational loads for the required visual effects, or differences in system load and resource scheduling. Therefore, the first GPU core and the second GPU core can be physically identical processing units, and their roles may interchange under different tasks or at different points in time. For example, when processing the next tile rendering task (i.e., the second tile rendering task mentioned above), the original second GPU core may become the "first GPU core" (i.e., the faster GPU core) because its task is simpler, while the original first GPU core 310 may become the "second GPU core" (i.e., the slower GPU core) because its task is more complex. It is worth noting that the first GPU core and the second GPU core mentioned above are only illustrative examples, and this embodiment does not limit them.

[0111] For example, a first GPU core executes a first tile rendering task for a first tile set based on a first control configuration stored in the memory unit corresponding to the first GPU core. The first control configuration is the control configuration for the first tile task, and the first tile set includes at least one tile processed by the first GPU core. A second GPU core executes a first tile rendering task for a second tile set based on a first control configuration stored in the memory unit corresponding to the second GPU core. The second tile set includes at least one tile processed by the second GPU core.

[0112] For example, after completing the first tile rendering task, the first GPU core executes a second tile rendering task for the first tile set based on the second control configuration stored in the memory unit corresponding to the first GPU core. The second control configuration is the control configuration for the second tile rendering task. If the second GPU core has not completed its first tile rendering task while the first GPU core is completing it, the second GPU core will still continue executing the first tile rendering task.

[0113] For example, the triggering of asynchronous execution relies on each GPU core's ability to detect the completion status of its currently executing task. For example, each GPU core contains a task state machine and a tile list pointer. When a GPU core begins executing a tile rendering task, its task state machine is initialized to the "in progress" state, and the tile list pointer is set to point to the starting address of the set of tiles it is responsible for (i.e., the tile list). For example, the GPU core's pixel processing pipeline processes each tile in the tile list sequentially. After rendering each tile, the hardware logic automatically updates the tile list pointer to point to the next tile in the list. When the tile list pointer points to a preset end address or reads a predefined end marker, the hardware circuitry (e.g., a comparator) detects this condition and drives the task state machine to jump from the "in progress" state to the "completed" state. This state transition is, at the hardware level, a valid local event that triggers subsequent behavior. For example, when the GPU core's task state machine transitions to the "completed" state, its scheduling microcode or hardware state machine executes a series of predefined operations to complete the context switch. Specifically, in this embodiment, the first GPU core's predefined operations include: resource release, where the first GPU core sends a command to the controller of the corresponding storage unit to release the memory area occupied by the first control configuration; configuration acquisition, where the first GPU core reads the second control configuration from the corresponding storage unit and loads it into the corresponding configuration register of the pixel processing pipeline; state reset, where the first GPU core resets the task state machine to "in progress" and re-points the tile list pointer to the starting address of the first tile set; and task startup, where the pixel processing pipeline of the first GPU core starts executing the second tile rendering task on the first tile set based on the second control configuration.

[0114] Indicatively, based on the above mechanism, asynchronous communication is established between the two GPU cores: First GPU Core: After completing the first tile rendering task, the first GPU core will not enter an idle waiting state, nor will it query the progress of the second GPU core. The first GPU core executes the aforementioned context switching mechanism, deletes the first control configuration, reads the second control configuration preset for the second tile rendering task, and executes the second tile rendering task on the tiles within the first tile set based on the second control configuration. For example, the tile rendering operations defined by the second control configuration (such as post-processing, special effects rendering) are completely different in content and purpose from those defined by the first control configuration (such as basic color rendering), but both operate on the same first tile set.

[0115] Second GPU core: At the same time, since the tile list pointer of the second GPU core has not yet reached the end address of its list, its task state machine remains in the "in progress" state. Therefore, its scheduling logic will not initiate any context switching operation, but will continue to execute the first tile rendering task, that is, process the remaining tiles of its second tile set based on the first control configuration, until the corresponding tile list pointer reaches the end address of its list.

[0116] The underlying logic of this application embodiment is that each GPU core autonomously schedules and switches tasks based on its corresponding memory unit, eliminating the synchronous waiting dependency between GPU cores. The GPU core with the leading progress triggers a state transition by detecting the end condition of its local tile list and autonomously loads the configuration for the next task, thereby transforming the traditional synchronous advancement model into a more efficient asynchronous model. This maximizes the utilization of the parallel computing capabilities of the rendering system and effectively improves the generation efficiency of rendering results. It is worth noting that the above implementation method based on tile list pointers and hardware state machines is only an illustrative example and is not limited in this embodiment. Any hardware structure and control method that can enable multiple GPU cores to autonomously and asynchronously execute tile rendering tasks based on the control configuration of memory units is within the protection scope of this application embodiment.

[0117] In some embodiments, the above method further includes: after the first GPU core completes the first tile rendering task, deleting the first control configuration stored in the storage unit corresponding to the first GPU core.

[0118] For example, after completing a tile rendering task, the GPU core can delete the control configuration stored in the corresponding memory unit. However, for other GPU cores in the rendering system that have not yet completed the aforementioned tile rendering task, the first control configuration stored in their corresponding memory units is still in use and must be retained to ensure that the GPU core continues to perform tile rendering tasks on the tiles in the tile set. In some embodiments, the GPU core can delete the control configuration in, but is not limited to, the following ways: instruction writing, where the GPU core sends a delete command to the controller of the memory unit, which contains the address or identifier of the control configuration to be deleted, and the controller performs the specific erase or release operation; address management, where in a memory unit that uses a data structure such as a first-in-first-out queue to manage the control configuration, after the GPU core completes a tile rendering task, it can logically "remove" the used configuration by moving the head or tail pointer of the queue, and its storage space can then be overwritten by the newly enqueued configuration; and a flag bit mechanism, where a valid bit is set in the memory unit for each control configuration. After completing the current tile rendering task, the GPU core clears the valid bits of the corresponding control configuration, marking the space occupied by this control configuration as "reclaimable." Alternatively, it can directly overwrite the data; after completing the current tile rendering task, the GPU core can directly write new data to the memory address where the corresponding control configuration resides (for the control configuration of the next tile rendering task), thus deleting it. This deletion mechanism is universal; any GPU core, after completing its current tile rendering task, will perform a similar deletion or release operation on the control configuration used by that task in its corresponding storage unit.

[0119] For example, while the pixel processing pipeline of the GPU core is executing a tile rendering task, the control configuration required for the next tile rendering task can be configured in advance, so that the next tile rendering task can be started immediately after the current tile rendering task is completed.

[0120] In some embodiments, before the GPU core's pixel processing pipeline begins executing the first tile rendering task, the system sequentially writes all control configurations corresponding to all tile rendering tasks into the storage unit. For example, assuming there are N tile rendering tasks, the corresponding first, second, and up to the Nth control configurations are all stored in the storage unit before the first tile rendering task begins. The GPU core reads the control configurations sequentially and executes the corresponding tile rendering tasks. This approach ensures that the tile rendering task execution does not experience waiting due to unprepared control configurations.

[0121] In some embodiments, during the process of the system executing tile rendering tasks in the pixel processing pipeline of the GPU core, it dynamically writes control configurations to the storage unit. Exemplarily, since the storage unit is a storage area in the form of a queue, and after the pixel processing pipeline of the GPU core completes the current tile rendering task, the GPU core deletes the corresponding control configuration. Therefore, as long as there are always control configurations in the storage unit, the pixel processing pipeline of the GPU core can continue to work. Thus, when the GPU core executes the current tile rendering task, the system can prepare subsequent control configurations in parallel. For example, when the pixel processing pipeline of the first GPU core is executing the first tile rendering task based on the first control configuration, the system writes the second control configuration to the storage unit corresponding to the first GPU core. When the first GPU core completes the first tile rendering task, retrieves the second configuration, and starts executing the second tile rendering task, the system starts to prepare the third configuration and writes it to the storage unit corresponding to the first GPU core, and so on. This approach provides flexibility and is suitable for scenarios where the tile rendering task flow cannot be fully predicted.

[0122] In some embodiments, the system writes multiple control configurations to the storage unit in advance according to a preset batch size. Exemplarily, assume there are a total of N tile rendering tasks. The system does not write all N configurations at once, nor does it strictly write only the next configuration at a time. Instead, it sets a preset number K (K is a positive integer greater than 1 and less than N). Before the GPU core starts to execute tile rendering tasks, the system pre-writes the first K control configurations. When the GPU core starts to execute the Mth tile rendering task (M < K), if the system detects that the number of remaining unexecuted control configurations in the storage unit is lower than a preset threshold, it will trigger a write operation to write the subsequent K control configurations (i.e., the M + 1 to M + K configurations) to the corresponding storage unit. This approach strikes a balance between determinism and flexibility: by keeping multiple control configurations in the storage unit at all times, it effectively reduces the risk of the GPU core stalling due to the delay in preparing a single control configuration; at the same time, it avoids storing all the control configurations at the beginning, reduces the capacity requirement for the storage unit, and allows the system to dynamically determine the specific content of subsequent control configurations based on the results of the executed tile rendering tasks.

[0123] It should be noted that the above storage strategy for control configurations is only for illustrative purposes, and this embodiment does not limit it. Any mechanism that can ensure that when the GPU core needs to execute a certain tile rendering task, its corresponding control configuration has been stored in its corresponding storage unit belongs to the protection scope of this application.

[0124] In summary, the rendering method proposed in this application equips each GPU core with a dedicated storage unit to independently store the control configuration set, enabling the pixel processing pipelines of each GPU core to asynchronously execute tile rendering tasks based on the aforementioned control configuration set. Even if the uneven distribution of tile rendering tasks across different tiles leads to different execution speeds of tile rendering tasks among the pixel processing pipelines of the GPU cores, the GPU core executing the tile rendering task faster does not need to wait for the slower GPU core and can immediately execute the next tile rendering task based on the control configuration set in its corresponding storage unit. Therefore, when the tile rendering tasks across different tiles are uneven, the rendering method proposed in this application can improve the processing efficiency of tile rendering tasks.

[0125] In some embodiments, a GPU chip is also provided, which includes the rendering system described above.

[0126] Please refer to Figure 6 This is a simplified structural block diagram of an electronic device provided in one possible implementation of this application. For example... Figure 6 As shown, the electronic device 600 includes a GPU chip, which incorporates the rendering system described above. The electronic device 600 can be used to implement the rendering method applied to the rendering system provided in the above embodiments.

[0127] Typically, electronic device 600 includes a processor 610 and a memory 620.

[0128] Processor 610 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 610 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 610 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 610 may integrate a GPU, which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 610 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0129] The memory 620 may include one or more computer-readable storage media, which may be non-transitory. The memory 620 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 620 are used to store a computer program configured to be executed by one or more processors to implement the rendering method described above applied to the rendering system.

[0130] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on the electronic device 600, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0131] In some embodiments, the electronic device 600 may be a server, a server cluster, an artificial intelligence computing cluster, a cloud computing cluster, etc., wherein the artificial intelligence computing cluster may also be simply referred to as an intelligent computing cluster or a smart computing cluster, and this application does not limit it in this regard.

[0132] It should be understood that "multiple" as mentioned herein refers to two or more. Furthermore, the step numbers described herein are merely illustrative of one possible order of execution. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this practice.

[0133] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A rendering method, characterized in that, The method is applied to a rendering system, the rendering system comprising: multiple graphics processing unit (GPU) cores, and storage units corresponding to each of the multiple GPU cores; the method includes: The multiple GPU cores each obtain a control configuration set from their corresponding storage units; The multiple GPU cores execute tile rendering tasks asynchronously based on the control configuration set.

2. The method according to claim 1, characterized in that, The control configuration set corresponding to the GPU core includes: control configurations assigned to at least one tile rendering task executed by the GPU core, different tile rendering tasks corresponding to different control configurations, and the control configuration of each tile rendering task is used to control the GPU core to execute the tile rendering task.

3. The method according to claim 2, characterized in that, The plurality of GPU cores includes: a first GPU core; The plurality of GPU cores asynchronously execute the tile rendering task based on the control configuration sets stored in the storage units corresponding to the plurality of GPU cores, including: The first GPU core executes a first tile rendering task for the first tile set based on the first control configuration stored in the storage unit corresponding to the first GPU core. Wherein, the first tile rendering task is one of the at least one tile rendering tasks; the first control configuration is the control configuration of the first tile rendering task; the first tile set includes at least one tile that the first GPU core is responsible for processing; the plurality of GPU cores execute the first tile rendering task for different tile sets based on the first control configuration stored in their respective storage units.

4. The method according to claim 3, characterized in that, The method further includes: After the first GPU core completes the first tile rendering task, the first GPU core executes the second tile rendering task for the first tile set based on the second control configuration stored in the storage unit corresponding to the first GPU core. Wherein, the second tile rendering task is another tile rendering task that is different from the first tile rendering task among the at least one tile rendering tasks; the second control configuration is the control configuration of the second tile rendering task.

5. The method according to claim 3, characterized in that, The plurality of GPU cores also includes: a second GPU core; If the second GPU core has not completed the first tile rendering task after the first GPU core has completed the first tile rendering task, then the first GPU core starts executing the second tile rendering task, while the second GPU core continues to execute the first tile rendering task.

6. The method according to claim 3, characterized in that, The method further includes: After completing the first tile rendering task, the first GPU core deletes the first control configuration stored in the storage unit corresponding to the first GPU core.

7. The method according to claim 2, characterized in that, The method further includes: The storage unit corresponding to the GPU core stores the control configuration of at least one tile rendering task assigned to the GPU core in the form of a queue, and the control configuration follows a first-in-first-out access mechanism in the queue.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: For the target tile rendering task, if the target tile rendering task meets the conditions, the multiple GPU cores will synchronously execute the target tile rendering task after all the multiple GPU cores have completed the tile rendering tasks before the target tile rendering task. The conditions include: the execution process of the target tile rendering task depends on the execution results of the tile rendering tasks prior to the target tile rendering task by the multiple GPU cores.

9. A rendering system, characterized in that, The rendering system includes: multiple graphics processing unit (GPU) cores, and storage units corresponding to each of the multiple GPU cores; The plurality of GPU cores are used to obtain control configuration sets from their respective storage units; The multiple GPU cores are also used to asynchronously execute tile rendering tasks based on the control configuration set, respectively.

10. A GPU chip, characterized in that, The GPU chip includes the rendering system as described in claim 9.

11. An electronic device, characterized in that, The electronic device includes a GPU chip, and the GPU chip includes the rendering system as described in claim 9.

Images