Rendering method, tile allocation apparatus, graphics processing device, and computing device

Abstract

The present disclosure relates to a rendering method for a graphics processing device, a tile allocation apparatus, a graphics processing device, and a computing device. The method comprises: obtaining a plurality of tiles of a rendering object, wherein the rendering object comprises a plurality of primitives, and each of the plurality of tiles is covered by at least one primitive of the rendering object; on the basis of a hardware configuration of a graphics processing device, determining at least one available core and the number of available computing units included in each of the at least one available core; and on the basis of the number of available computing units included in each available core, allocating the plurality of tiles among the at least one available core, such that the graphics processing device, on the basis of the allocation of the plurality of tiles among the at least one available core, calls a corresponding available core to perform a rendering operation on a corresponding tile. The method helps to improve system load balancing and enhances rendering efficiency.

Description

Rendering method, tile allocation device, graphics processing device and computing device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Chinese patent application No. 202410340377.5 filed on March 25, 2024, all contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to graphics processing technology, and in particular, to a rendering method for a graphics processing device, a tile allocation device, a graphics processing device, and a computing device. Background Art

[0004] Graphics processing technology refers to the use of various hardware and software devices to process two-dimensional or three-dimensional visuals and images to achieve specific presentation effects. A graphics processing device can refer to a device used to perform graphics processing-related operations, such as a graphics processing unit (GPU) or other similar devices. Generally speaking, a graphics processing device may include multiple processing cores to achieve higher graphics processing efficiency through parallel operation. Therefore, how to distribute graphics processing tasks across multiple processing cores to maximize the computing power of the graphics processing device has become a highly concerned issue. Summary of the Invention

[0005] In view of this, the present disclosure provides a rendering method for a graphics processing device, a tile allocation apparatus, a graphics processing device, and a computing device to solve or at least alleviate the above-mentioned problems.

[0006] According to one aspect of the present disclosure, a rendering method for a graphics processing device is provided, comprising: obtaining a plurality of tiles of a rendering object, wherein the rendering object includes a plurality of primitives, and each tile of the plurality of tiles is covered by at least one primitive of the rendering object; determining, based on a hardware configuration of the graphics processing device, at least one available core and the number of available computing units included in each of the at least one available cores; and allocating the plurality of tiles among the at least one available core according to the number of available computing units included in each of the available cores, so that the graphics processing device calls the corresponding available core to perform rendering operations on the corresponding tiles according to the allocation of the plurality of tiles among the at least one available core.

[0007] In some embodiments, allocating multiple tiles among at least one available core according to the number of available computing units included in each available core includes: based on the coordinates of each tile in the multiple tiles, allocating each tile in the multiple tiles to the corresponding available core according to a core allocation rule, wherein the core allocation rule is a rule for allocating a specified number of tiles to each available core in a specified order, wherein the number of tiles allocated to each available core is determined according to the number of available computing units of each available core.

[0008] In some embodiments, based on the coordinates of each tile in the multiple tiles, according to the core allocation rule, each tile in the multiple tiles is allocated to the corresponding available core, including: for each tile in the multiple tiles, according to the coordinates of the tile and the specified number in the core allocation rule, determining the allocation round of the tile; according to the position of the tile in the corresponding allocation round and the specified order in the core allocation rule, each tile in the multiple tiles is allocated to the corresponding available core.

[0009] In some embodiments, based on the coordinates of each tile in the multiple tiles, according to the core allocation rule, allocating each tile in the multiple tiles to the corresponding available core includes: dividing the multiple tiles into multiple tile groups; for each tile group in the multiple tile groups, determining the core allocation rule corresponding to the tile group; for each tile group, based on the coordinates of each tile in the tile group, according to the core allocation rule corresponding to the tile group, allocating each tile in the tile group to the corresponding available core.

[0010] In some embodiments, different tile groups correspond to different core allocation rules.

[0011] In some embodiments, core allocation rules corresponding to different tile groups have the same core ordering and different starting cores.

[0012] In some embodiments, allocating multiple tiles among at least one available core based on the number of available computing units included in each available core includes: in response to the rendering object belonging to a preset scene, obtaining an allocation table corresponding to the preset scene; and allocating multiple tiles among at least one available core according to the allocation table.

[0013] In some embodiments, allocating multiple tiles among at least one available core based on the number of available computing units included in each available core also includes: for each tile in the multiple tiles, determining a signature value of the tile based at least on the coordinates of the tile and the available core to which the tile is allocated; and updating the available core to which at least some of the multiple tiles are allocated based on the signature value of the tile.

[0014] In some embodiments, based on the signature value of the tile, updating the available cores to which at least part of the multiple tiles are assigned includes: initializing the tile identifier of the current tile and the tile count of each available core, the current tile is the tile currently being processed, and the tile count indicates the number of tiles assigned to the corresponding available cores; performing an iterative allocation step, the iterative allocation step including: in response to the tile count corresponding to the available core to which the current tile is assigned reaching a first threshold, according to the signature value of the current tile, allocating the current tile to another available core to update the available core to which the current tile is assigned, and increasing the tile count of the other available core by 1; in response to the tile count corresponding to the available core to which the current tile is assigned not reaching the first threshold, increasing the tile count of the available core by 1; in response to the current tile being the last tile, stopping the iteration; in response to the current tile being not the last tile, updating the tile identifier of the current tile to the tile identifier of the next tile along the specified direction.

[0015] In some embodiments, the iterative allocation step further includes: in response to a tile count corresponding to an available core reaching a first threshold, disabling the available core in the current round; in response to the number of tiles processed in the current round reaching a second threshold, entering the next round and resetting the tile counts of each available core.

[0016] According to another aspect of the present disclosure, a tile allocation device is provided, which is integrated in a graphics processing device and includes: an input end, configured to: obtain multiple tiles of a rendering object, the rendering object includes multiple primitives, and each tile of the multiple tiles is covered by at least one primitive of the rendering object; a preprocessing module, configured to: determine at least one available core and the number of available computing units included in each of the at least one available core based on the hardware configuration of the graphics processing device; a tile allocation module, configured to: allocate multiple tiles among the at least one available core according to the number of available computing units included in each of the available cores, so that the graphics processing device calls the corresponding available core to perform rendering operations on the corresponding tiles according to the allocation of the multiple tiles among the at least one available core.

[0017] In some embodiments, the apparatus further includes: a primitive allocation module configured to allocate primitives covering corresponding tiles to each available core according to the allocation of the plurality of tiles among at least one available core.

[0018] In some embodiments, the apparatus further includes a post-processing module configured to maintain status information of a plurality of tiles being rendered by corresponding available cores.

[0019] According to another aspect of the present disclosure, a graphics processing device is provided, including: a tile division device, configured to: obtain a rendering object and divide the rendering object into multiple tiles, wherein the rendering object includes multiple primitives and each tile is covered by at least one primitive of the rendering object; a tile allocation device according to any embodiment of the aforementioned aspect; and a tile rendering device, configured to: call a corresponding available core to perform a rendering operation on a corresponding tile based on the allocation of multiple tiles among at least one available core.

[0020] According to yet another aspect of the present disclosure, a computing device is provided, comprising the graphics processing device described in the aforementioned aspect.

[0021] Through the rendering method provided by the present invention, multiple tiles of the rendering object can be obtained, and the multiple tiles can be distributed among the available cores in the graphics processing device according to the number of available computing units of each available core. This helps to more evenly utilize the computing resources of each available core, reduce the probability of some cores or some computing units being overloaded, thereby achieving better load balancing, and helps to reduce the idle time of the computing units, improve parallelism and concurrency, thereby maximizing the parallel computing capabilities of multiple available cores and achieving more adequate utilization of computing resources. These in turn help to improve the overall graphics processing efficiency, reduce processing time, improve the overall performance of graphics processing, such as improving throughput, improving response speed, etc., and reduce overall energy consumption.

[0022] These and other aspects of the disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Further details, features and advantages of the present disclosure are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0024] FIG1 schematically shows an exemplary block diagram of a tile-based rendering pipeline according to the related art;

[0025] FIG2A schematically shows an exemplary flowchart of a rendering method for a graphics processing device according to some embodiments of the present disclosure;

[0026] FIG2B schematically illustrates an exemplary block diagram of a core according to some embodiments of the present disclosure;

[0027] FIG3 schematically illustrates an example of rendering an object according to some embodiments of the present disclosure;

[0028] FIG4 schematically illustrates an example of core allocation according to some embodiments of the present disclosure;

[0029] FIG5 schematically illustrates an example of an application allocation table according to some embodiments of the present disclosure;

[0030] FIG6 schematically illustrates another example of core allocation according to some embodiments of the present disclosure;

[0031] FIG7 schematically shows an example flow chart of a tile allocation process according to some embodiments of the present disclosure;

[0032] FIG8 schematically shows an exemplary block diagram of a tile allocation apparatus according to some embodiments of the present disclosure;

[0033] FIG9 schematically illustrates an example architecture including a tile allocation apparatus according to some embodiments of the present disclosure;

[0034] FIG10 schematically shows an exemplary block diagram of a graphics processing device according to some embodiments of the present disclosure;

[0035] FIG11 schematically illustrates an exemplary block diagram of a computing device according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0036] The technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. It should be understood that the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments described in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure. Those skilled in the art will understand that the embodiments described below are intended to explain the present disclosure and should not be regarded as limitations on the present disclosure. Unless otherwise specified, if specific techniques or conditions are not clearly described in the embodiments below, those skilled in the art can understand them according to the commonly used techniques or conditions in the field or according to the product manual.

[0037] In the description of this specification, the description with reference to the terms "one embodiment", "another embodiment" and the like means that the specific features, structures, materials or characteristics described in conjunction with the embodiment are included in at least one embodiment of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are mutually inconsistent. In addition, it should be noted that in this specification, the terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0038] As will be appreciated by those skilled in the art, although the various steps of the method of the present disclosure are described in a particular order in the accompanying drawings, this does not require or imply that the steps must be performed in that particular order unless the context clearly indicates otherwise. Additionally or alternatively, multiple steps may be combined into a single step and / or a single step may be broken down into multiple steps and performed. In addition, other method steps may be inserted between steps. An inserted step may represent an improvement to a method such as that described herein, or may be unrelated to the method. In addition, a given step may not be fully completed before the next step begins.

[0039] Before introducing the embodiments of the present disclosure in detail, some related concepts are first explained for the sake of clarity.

[0040] A render target may refer to an object to be rendered, which may be a part of a virtual scene to be rendered, or may be a picture or video frame to be rendered.

[0041] A primitive may refer to a basic geometric shape that constitutes a graphic, such as a point, a line, a triangle, etc. For example, a graphic drawn by an application may be represented in a computer by combining a large number of basic geometric shapes.

[0042] The rendering pipeline is a key concept in computer graphics. It is a stage within the graphics processing unit (GPU) responsible for processing and converting graphics data for rendering. The rendering pipeline's primary task is to convert input geometric primitives (such as points, lines, triangles, etc.) into visible pixels on the screen. The goal of the rendering pipeline is to efficiently process the graphics and generate the final image. Through parallel processing and specialized hardware support, the GPU is able to perform these calculations quickly, enabling real-time graphics rendering.

[0043] In the related art, the rendering process can be implemented with the help of a graphics pipeline. In a standard graphics pipeline, the primitives included in the rendering object can be rasterized, and then the valid pixels are sent to the pixel shader for shading. In order to improve processing performance, it is proposed to divide the rendering object into multiple tiles and perform tile-based rendering (TBR) on the rendering object, where each tile can be used to render a small part of the scene. Optionally, the tile-level scheduler in the graphics processing unit (GPU) can be used to schedule GPU resources based on the complexity and importance of each tile, so as to allocate more computing resources to tiles that require more details. This method can implement tile-level resource allocation at the GPU hardware level to make greater use of the GPU's computing power and help reduce power consumption. Therefore, it is often used in scenarios with limited computing resources, such as the GPU of a mobile device. Schematically, Figure 1 shows an exemplary block diagram of a tile-based rendering pipeline 100. As shown in the figure, the rendering pipeline 100 may include a front end and a back end, wherein the front end may include modules such as vertex processing (Vertex Processing) 110, clipping / culling (Clip / Cull) 120, and tiling (Tiling) 130, and the back end may include modules such as rasterization (Raster) 140, HSR (Hidden Surface Remove) 150, pixel processing (Pixel Processing) 160, and output merging (Output Merge) 170. Specifically, the front end can perform vertex and primitive transformation, graphics processing (including clipping, culling, etc.), and then complete the screen segmentation and record the graphics data covering each tile in the tile stage, and write the above-mentioned generated data (such as primitive lists, vertex data, etc.) into memory or other storage structures, such as writing into primitive blocks shown in Figure 1, where primitive blocks can be used to store indexes, coordinates, and other data of primitives covering tiles. For a tile, one or more primitive blocks can be used to store the data of primitives covering the tile. Primitive blocks can be stored, for example, through region arrays; the back end can perform rasterization, depth testing, pixel shading, and other operations, and finally output the rendering results. For a tile, the rendering pipeline will load all the primitives it contains (such as triangle primitives) into the fragment stage for processing. All primitives covering the tile can be read directly from the corresponding primitive blocks. When all the primitives of the tile are processed, the next tile can be processed.

[0044] However, although the above-mentioned tile-based rendering pipeline helps to improve the utilization of computing resources and reduce power consumption, it still has the problem of uneven distribution of computing tasks among the processing cores, which in turn affects the efficiency of graphics processing.

[0045] To address or at least alleviate the aforementioned issues, the present disclosure provides a rendering method for a graphics processing device. For example, FIG2A illustrates a schematic block diagram of a rendering method 200 for a graphics processing device according to some embodiments of the present disclosure. In the present disclosure, a graphics processing device may refer to any device with graphics processing capabilities, such as a GPU or other device. As shown in FIG2A , rendering method 200 may include steps 210 to 250, as described below.

[0046] In step 210, a plurality of tiles of a rendering object may be obtained, wherein the rendering object may include a plurality of primitives, and each of the plurality of tiles may be covered by at least one primitive of the rendering object. Exemplarily, the tile information of the rendering object may be obtained from a previous module or a storage device (such as a memory), for example, the plurality of tiles of the rendering object may be received from a tiling module 130 or other preceding modules such as shown in FIG. 1 , or control information may be received from a preceding module and the tile information of the rendering object may be read from a storage device based on the control information, etc. Exemplarily, obtaining the plurality of tiles of the rendering object may include obtaining tile information of the plurality of tiles, and the tile information may include tile identifiers (such as tile coordinate data, index data, etc.) and information of the primitive covering the tile (such as primitive identifiers, coordinates, or addresses storing such data). Optionally, the primitive may be a triangle primitive, or may be other geometric shapes. Exemplarily, the plurality of tiles may be obtained by dividing the rendering object. Exemplarily, the tiles may be squares of a preset size, such as 16×16, 32×32, 64×64, etc. Alternatively, according to specific application requirements, the rendering object can also be divided into tiles of other preset sizes, or tiles of other shapes. For example, when the rendering object is divided into multiple tiles, the primitives covering each tile can be read, and a primitive list corresponding to each tile can be generated. The primitive list may include, for example, information such as the identification and storage address of the primitives covering the corresponding tiles. This primitive list can be passed to a subsequent processing module, or it can be stored in a storage device such as a memory. Alternatively, according to specific application requirements, information about tiles and primitives can also be transmitted or stored in other ways. Optionally, the tiles can be tiles under the aforementioned TBR architecture, or they can be similar objects obtained by dividing the rendering object.

[0047] In step 220, the number of available computing units included in at least one available core and each of the at least one available cores can be determined based on the hardware configuration of the graphics processing device. Exemplarily, the hardware configuration of the graphics processing device can be obtained from a structure such as a memory, such as hardware state information and registers. Hardware state information can include information such as fragment event words and event states, and registers can include various parameters and configuration information required for hardware processing and operation. Once the hardware configuration is determined, the number of available processing cores and computing resources can be obtained. A processing core can include one or more computing units. As mentioned above, a graphics processing device such as a GPU can include multiple cores, some or all of which can be currently available cores, and different cores can have the same or different numbers of currently available computing units. Exemplarily, at least one available core can be determined based on the hardware configuration information, and the number of available computing units included in each of the at least one available cores can be determined. Exemplarily, a core identifier of the at least one available core can be obtained. The core identifier can be a mask or other identifier that is pre-set or set at runtime. For example, the different cores and / or different computing units can be numbered using software or hardware-implemented methods.

[0048] For example, FIG2B schematically shows an exemplary block diagram of the core 201 involved in the present disclosure. As shown in FIG2B , the core 201 may include a plurality of computing units 203-1 to 203-n, where n may be an integer greater than or equal to 1. The computing units 203-1 to 203-n may be used to perform various computing functions. In addition, the core 201 may further include a control unit 202 and a storage unit 204, where the control unit 202 may be used to control the interaction between the core 201 and external devices or modules and various operations within the core 201, and the storage unit 204 may be used to store data required for use in the process of the core 201 running or performing various tasks. It should be understood that the structure shown in FIG2B is merely exemplary, and the core mentioned in the present disclosure may also have other structures.

[0049] In step 230, the aforementioned multiple tiles can be allocated among at least one available core according to the number of available computing units included in each available core, so that the graphics processing device can call the corresponding available core to perform rendering operations on the corresponding tiles according to the distribution of the multiple tiles among the at least one available core. Exemplarily, more tiles can be allocated to the available cores with more available computing units. For example, the number of tiles allocated to each available core can be proportional to the number of available computing units included in each available core. Optionally, the distribution of the multiple tiles among the at least one available core can be stored in a form such as a lookup table or other forms, such as in a memory, so that the distribution can be read later and the corresponding core can be called to process the corresponding tiles. Exemplarily, according to the distribution of the tiles among the available cores, the graphics processing device can call different cores to perform rasterization on the corresponding tiles, as well as subsequent HSR, pixel processing and other operations.

[0050] Through the rendering method 200 , allocation can be performed in units of tiles, and different numbers of available computing units of different cores can be considered. This helps achieve the following effects: First, tiles can be dynamically allocated at runtime based on the current rendering task and core load. Compared to a fixed allocation scheme, this can better adapt to load changes, more fully utilize the computing resources in the graphics processing device, balance the task allocation and load between different cores, reduce the idle time of cores or computing units, maximize the parallel computing capabilities of the graphics processing device, and improve computing resource utilization. Second, by balancing the allocation of computing resources, the probability of certain cores or computing units being overloaded can be reduced, and the degree of parallelism can be increased. This parallelization and load balancing helps improve overall processing efficiency and reduce processing time. Third, it can reduce the probability of resource contention and conflict, optimize the parallelism of the graphics processing process, and improve the overall performance of the system, such as improving the system's throughput and responsiveness. Fourth, by reducing the probability of certain cores or computing units being overloaded, it can reduce overall energy consumption, avoid wasting computing resources and unnecessary energy consumption, thereby helping to improve overall energy efficiency. This in turn helps avoid allocating too many resources to certain rendering tasks, improve overall resource utilization, and enable the entire computing system (such as the entire graphics processing device) to maintain good performance when facing larger-scale computing tasks. The above advantages can improve computing performance, resource utilization, etc., which helps to improve rendering effects.

[0051] For example, the rendering method 200 can be used in the TBR architecture described above to improve tile scheduling and allocation, thereby enhancing rendering performance. Alternatively, the rendering method 200 can also be used in graphics processing devices with other similar architectures.

[0052] In some embodiments, the aforementioned step 230 may include: based on the coordinates of each tile in the multiple tiles, according to the core allocation rule, allocating each tile in the multiple tiles to the corresponding available core. The core allocation rule may be a rule for allocating a specified number of tiles to each available core in a specified order, wherein the number of tiles allocated to each available core is determined according to the number of available computing units of each available core. Exemplarily, the coordinates of the tile can represent the position of the tile in the entire rendering object, and the order in which the tiles are allocated can be determined according to the coordinates of each tile. For example, an index can be determined for each tile according to the coordinates, and the index can indicate the order in which the tiles are allocated. For example, the index can be determined for the tiles at each position from top to bottom, from left to right or other rules. In conjunction with the aforementioned core allocation rule, the core to which each tile is allocated can be determined. Optionally, in the aforementioned core allocation rule, the specified number can be determined based on the number of available computing units included in each available core, such as being equal to the total number of available computing units included in each available core, a value proportional to the total number of available computing units, or any desired value lower than the total number of available computing units. The specified order can be pre-set based on actual application requirements or adaptively determined based on preset rules. Optionally, the number of tiles allocated to each available core can be equal to or proportional to the number of available computing units in each available core. Optionally, the core allocation rule can be pre-designed or adaptively determined at runtime. For example, after determining the number of available cores and the available computing units in each available core based on the hardware configuration, the available cores can be arranged according to a preset order or a random order, such that the number of occurrences of each available core is equal to or corresponds to the number of available computing units in each available core, thereby obtaining the aforementioned core allocation rule, wherein the total number of occurrences of each available core is the aforementioned specified number, and the order of arrangement of the available cores is the aforementioned specified order. For further example, assuming that there are 4 cores, core 0, core 1, core 2, and core 3 include 1, 2, 3, and 4 available computing units respectively, and the cores are arranged in ascending order until the available computing units of all cores are exhausted, the following core allocation rule can be obtained, "0, 1, 2, 3, 1, 2, 3, 2, 3, 3" (where each number represents the corresponding core). Through the above steps, each tile can be allocated to the corresponding available core in an orderly manner, and allocation can be achieved according to the number of available computing units of each available core, so as to improve the balanced allocation of computing resources, improve the degree of parallelism of each core, and thus improve rendering efficiency.

[0053] For example, as shown in Figure 3, rendering object 300 may include 9 tiles, each numbered T0 to T8 from left to right and from top to bottom. Assuming there are 2 available cores, core 1 includes 2 available compute units, core 2 includes 1 available compute unit, and the core allocation rule is to allocate 3 tiles in the order of "core 1, core 2, core 1", then, when the core allocation rule is applied to the first row of tiles shown in Figure 3, T0 can be allocated to core 1, T1 can be allocated to core 2, and T2 can be allocated to core 1. In this example, the allocation of T0 to T2 belongs to one allocation round.

[0054] In some embodiments, each tile in a plurality of tiles can be allocated to a corresponding available core by the following steps: for each tile in a plurality of tiles, an allocation round of the tile is determined according to the coordinates of the tile and the specified number in the core allocation rule; and each tile in a plurality of tiles is allocated to a corresponding available core according to the position of the tile in the corresponding allocation round and the specified order in the core allocation rule. In the present disclosure, an allocation round can be understood as a process of allocating a specified number of tiles. In other words, when a specified number of tiles are allocated to each available core in a specified order according to the core allocation rule, these specified number of tiles can be regarded as belonging to the same allocation round. For example, as described above, the order in which a certain tile is allocated can be determined based on its coordinates, and the allocation round of the tile can be determined based on the order and the aforementioned specified number. For example, the allocation round can be determined based on the quotient of the sequence number and the specified number. Furthermore, the core to which the tile should be allocated can be found based on the position of the tile in the corresponding allocation round and the specified order in the core allocation rule. For example, the core to which the tile should be allocated can be found based on the sequence number and the specified number. After the core allocation rule is determined in the above manner, the allocation round and the available core to which the tile should be allocated can be queried based on the coordinates of each tile, thereby helping to quickly complete the allocation process of each tile. At the same time, after the concept of allocation rounds is introduced, each core can be made to perform the rendering operation of the tile allocated to it in order according to the allocation round, thereby facilitating subsequent core scheduling operations.

[0055] For example, assuming the core allocation rule of "core 1, core 2, core 1" is applied to the nine tiles shown in Figure 3, then T4, which is the fifth tile in the ranking, should belong to the second allocation round because 5 divided by 3 equals 1 with a remainder of 2. Furthermore, according to the order of "core 1, core 2, core 1," it can be found that T4 should be allocated to core 2. Similar logic can be used to allocate other tiles.

[0056] In some embodiments, each tile in a plurality of tiles can be assigned to a corresponding available core by the following steps: dividing the plurality of tiles into a plurality of tile groups; for each tile group in the plurality of tile groups, determining a core assignment rule corresponding to the tile group; for each tile group, based on the coordinates of each tile in the tile group, assigning each tile in the tile group to a corresponding available core according to the core assignment rule corresponding to the tile group. Exemplarily, the plurality of tiles can be divided into a plurality of tile groups based on the processing granularity of the graphics processing device or other rules. For example, assuming that the graphics processing device can process two rows of tiles at a time, each two rows of tiles can be considered a group. Exemplarily, the tiles included in each group can be determined based on the coordinates of each tile, for example, the index values ​​of the tiles included in each tile group can be determined based on the coordinates of each tile. Exemplarily, within each tile group, each tile in the tile group can be assigned to a corresponding available core according to the method described in the aforementioned embodiments. In the above manner, allocation of tiles to cores can be implemented in units of tile groups, so as to adapt to the processing capability or processing granularity of the graphics processing device.

[0057] For example, as shown in Figure 4, rendering object 400 includes 64 tiles, namely T0 to T63. Assuming that every two rows form a tile group, rows 1-2 in rendering object 400 are the first group, rows 3-4 are the second group, rows 5-6 are the third group, and rows 7-8 are the fourth group. For Group 1, i.e., the first two rows, assuming the rule applied is "0, 1, 2, 3, 1, 2, 3, 2, 3, 3" (where the numbers represent core numbers), the allocation result shown in the figure can be obtained, where the fill pattern of the box representing the tile indicates the core to which the tile is assigned.

[0058] In some embodiments, different tile groups may correspond to different core allocation rules. Different core allocation rules may be understood as specifying at least one of different starting cores, different core orderings, different numbers of cores, and the like. In other words, as long as there is a difference between two core allocation rules, they may be considered different core allocation rules. Optionally, different core allocation rules may have the same specified number and different specified order, wherein the same specified number means that the number of cores included in each core allocation rule is the same, and the different specified order may involve at least one of different starting cores and different core orderings. In this way, the regularity with which each tile is assigned to the corresponding core may be disrupted to a certain extent, avoiding the concentrated allocation of tiles in the same row or column (or otherwise adjacent) to one or several cores. For a certain rendering object, different areas may have different rendering complexities, which is reflected in the tiles. Some adjacent (or in the same row or column) tiles may involve a larger number of primitives, while some adjacent (or in the same row or column) tiles may involve a smaller number of primitives. Therefore, by making different tile groups correspond to different core allocation rules, it helps to reduce the possibility of allocating relatively complex or relatively simple tiles to one or several cores, thereby further helping to improve the load balance of each core.

[0059] In some embodiments, the core allocation rules corresponding to different tile groups may have the same core ordering and different starting cores. The above-mentioned same core ordering can be understood as each core conforming to the same ordering method in different core allocation rules, or in other words, in different core allocation rules with the same core ordering, different core allocation rules can be obtained by shifting the same core sequence forward or backward, and the cores overflowing in the front can be moved to the end of the sequence, and the cores overflowing in the back can be moved to the beginning of the sequence. For example, "1, 2, 3", "2, 3, 1", and "3, 1, 2" can be understood as having the same ordering. Exemplarily, the core allocation rules for different tile groups can be determined in a swizzle manner, for example, the starting cores of adjacent tile groups can be in adjacent positions in the core ordering. In this way, it is convenient to adaptively determine the core allocation rules corresponding to each tile group at runtime. Continuing with the example of rendering object 400 shown in Figure 4, assuming the core allocation rule applied to the first two rows (i.e., the rows containing T0 and T1) is "0, 1, 2, 3, 1, 2, 3, 2, 3, 3," the core allocation rule applied to the rows containing T16 and T17 is "1, 2, 3, 1, 2, 3, 2, 3, 3, 0." The core allocation rule applied to the rows containing T32 and T33 is "2, 3, 1, 2, 3, 2, 3, 3, 0, 1." The core allocation rule applied to the rows containing T48 and T49 is "3, 1, 2, 3, 2, 3, 3, 0, 1, 2." Clearly, in this example, the core allocation rules for different tile groups have the same core ordering but different starting cores, resulting in the allocation results shown in Figure 4.

[0060] In some embodiments, step 230 may include: in response to the target image belonging to a preset scene, obtaining an allocation table corresponding to the preset scene, and allocating the plurality of tiles among at least one available core based on the obtained allocation table. The allocation table may be a table describing the correspondence between tiles and cores. For example, the allocation table may be an n×m table (where n and m are integers greater than 0 and may be equal or unequal). Each position in the table may correspond to an available core, for example, a core identifier of an available core, such as the core mask mentioned above. To fully utilize the available cores and avoid processing errors, the number of times each core appears in the allocation table may be determined based on the number of available computing units included in each core. Optionally, there may be one or more allocation tables, each of which may correspond to one or more scenes, such as a gaming scene or a virtual meeting scene. When a rendering object belongs to a preset scene, the corresponding allocation table may be directly called and the tiles of the rendering object may be allocated based on the allocation table. Exemplarily, the allocation table may be slid over the rendering object. During the sliding process, tiles covered by corresponding positions in the allocation table may be allocated to the available cores corresponding to those positions. For example, as shown in Figure 5, the rendering object 510 may include 64 tiles from T0 to T63, and the allocation table 520 may be a 3×3 table, and may represent the correspondence between tiles at 9 positions and cores 0 to 3. When the allocation table 520 is applied to allocate tiles in the rendering object 510, the allocation table 520 may be slid on the rendering object 510, for example, from left to right or from top to bottom. The positions through which it slides may be shown by the thick dotted lines in the figure. Each time it slides to a dotted box, the allocation of the corresponding tile may be determined based on the coverage of the tile by the allocation table. For example, in the upper left dotted box, T0 may be allocated to core 0, T1 may be allocated to core 1, T16 may be allocated to core 2, T2 may be allocated to core 1, T3 may be allocated to core 3, T18 may be allocated to core 1, T4 may be allocated to core 2, T5 may be allocated to core 0, and T20 may be allocated to core 3. By analogy, all tiles can be allocated. When the slider reaches a certain position where only a portion of the allocation table covers the tiles, such as the right and lower frames in the figure, only the covered tiles can be allocated. It should be understood that the tile numbers in FIG5 are merely for ease of description and are not necessarily numbered when allocating tiles according to the allocation table.

[0061] Exemplarily, developers can select some relatively effective allocation structures that have been analyzed and verified, and store them in hardware as allocation tables for certain scenarios. Alternatively, for example, users can be allowed to customize allocation tables through hardware interfaces such as APIs or registers, for example, writing customized allocation tables into hardware (such as memory or other storage structures) for the graphics processing device to call. Alternatively, for example, during the graphics processing process, the graphics processing device can automatically determine the allocation method that has better application effect in certain scenarios through various monitoring or feedback parameters related to the processing process, and store this allocation method in a table as an allocation table for the corresponding scenario. Alternatively, for example, allocation table generation rules for certain scenarios can be pre-specified, and the allocation table to be used can be automatically generated at runtime according to the pre-specified generation rules. Exemplarily, Figure 6 shows a rendering target 600 with 64 tiles, where each tile is allocated according to the allocation table, and the fill pattern and number in each tile box represent the core to which the tile is allocated.

[0062] Optionally, the above-described allocation table-based embodiment can be applied independently to the allocation of tiles to available cores, or it can be used in combination with the aforementioned various embodiments based on core allocation rules. For example, by default, tile allocation can be implemented based on core allocation rules, and when one or more preset scenarios occur, tile allocation can be implemented based on the allocation table. Alternatively, the allocation table can be applied to some areas of the render target, while the core allocation rules can be applied to other areas of the render target.

[0063] With the help of the above-mentioned allocation table, in certain preset scenarios, a more decentralized allocation result can be obtained, which helps to optimize the tile allocation in these preset scenarios and improve the adaptability and flexibility of the rendering method 200 in different scenarios. For example, when one core has a large number of available computing units and other cores have only a small number of available computing resources, if tile allocation is implemented according to the aforementioned embodiment based on the core allocation rule, it may cause the tiles in a certain area to be allocated to the same core, which may cause the core to be overloaded (for example, when the area happens to be an area with higher rendering complexity). With the help of the above-mentioned allocation table, such situations can be avoided in the corresponding preset scenarios, which helps to further improve the load balancing in such preset scenarios, and then improve the normal rendering efficiency. In addition, for example, when each core has the same number of available computing units, through the above-mentioned allocation table, the tiles of every two adjacent rows in each column can be allocated to different cores for processing, thereby better ensuring the dispersion of the allocation results.

[0064] In some embodiments, the aforementioned step 230 may further include: determining a signature value for each tile in the plurality of tiles based at least on the coordinates of the tile and the available core to which the tile is assigned; and updating the available cores to which at least some of the tiles in the plurality of tiles are assigned based on the signature value of the tile. The signature value can be understood as a value used to characterize that a certain tile is assigned to a certain core. The value can be unique and can be determined by various existing or custom algorithms, such as a hash algorithm. Exemplarily, the available cores to which some tiles are assigned can be updated according to preset rules or randomly. For example, the available cores to which each tile is assigned can be determined based on the aforementioned core allocation rule or based on an allocation table. The available core can be regarded as the initial core. The signature value of the tile can then be determined based on the tile coordinates and the initial core of the tile (optionally, other parameters may also exist), and some or all of the tiles can be reallocated according to preset rules or randomly. Optionally, for reassigned tiles, their signature values ​​can be updated based on the cores to which they are reassigned, so that the processing status of each tile can be located based on the signature value, such as the core to which it is currently assigned, whether it has been reassigned, etc. Therefore, when the allocation operation of tiles is interrupted due to a failure of the graphics processing device or other unexpected circumstances, the allocation status of each tile can be determined based on the signature value, thereby quickly restoring to the state before the interruption. Optionally, when reassigning some tiles, information such as the number of primitives in the tile, the complexity, and the number of tiles already allocated to each core can be considered to assist in the allocation, so as to further improve the load balancing of different cores. For example, when a tile that needs to be reassigned contains more primitives, it can be preferentially allocated to a core that has fewer tiles allocated or a core that has fewer tiles allocated. By updating the available cores to which at least some tiles are allocated, the tile allocation situation can be further optimized, further improving the load balancing in some complex scenarios, such as virtual meetings, games, and other scenarios with diverse or delicate objects.

[0065] In some embodiments, the available cores to which at least some of the multiple tiles are allocated can be updated by the following steps: initializing the tile identifier of the current tile and the tile count of each available core, the current tile is the tile currently being processed, the tile count indicates the number of tiles allocated to the corresponding available core, and performing an iterative allocation step. Exemplarily, the coordinates of the tile or other forms of index, encoding, etc. can be used as the tile identifier, and the tile identifier of the current tile can be recorded with the help of a register or other software or hardware module. Exemplarily, the number of tiles allocated to each available core, i.e., the aforementioned tile count, can be recorded by a counter or other software or hardware module. Optionally, during initialization, the tile identifier of the current tile can be initialized to the coordinates of the starting tile selected according to a preset rule, such as the upper left corner tile, the lower left corner tile, the upper right corner tile, the lower right corner tile, etc., and the tile count of each available core can be initialized to 0 or other preset values.

[0066] The iterative allocation step may include: in response to the tile count corresponding to the available core to which the current tile is allocated reaching a first threshold, allocating the current tile to another available core based on the signature value of the current tile, thereby updating the available core to which the current tile is allocated and incrementing the tile count of the other available core by 1; in response to the tile count corresponding to the available core to which the current tile is allocated not reaching the first threshold, incrementing the tile count of the available core by 1; in response to the current tile being the last tile, stopping the iteration; and in response to the current tile being not the last tile, updating the tile identifier of the current tile to the tile identifier of the next tile in a specified direction. The first threshold may be pre-set or adaptively set, and the same or different first thresholds may be set for different available cores. Optionally, the first threshold may be determined based on the number of available computing units of each available core. For example, the first threshold for each available core may be set equal to the number of available computing units of the available core, or other desired values, such as any value proportional to or lower than the number of available computing units. Alternatively, the first threshold may be determined based on other parameters such as the size of the render target. For example, assuming that the number of available computing units of a certain available core is 5, its first threshold value can be set to 5 or a value less than 5, such as 4, 3 or other expected values. Exemplarily, the above-mentioned first threshold value can be determined before executing the iterative step. Optionally, the specified direction can be selected according to the actual application requirements, and the present disclosure does not specifically limit this. Exemplarily, you can start from the tile in the upper left corner of the rendering target and process the next tile in sequence in the right direction. When a row is processed, you can move to the leftmost tile in the next row to continue processing. Through the above-mentioned iterative allocation step, it is possible to traverse the tiles in the rendering target. For the tiles at each position in the rendering target, when the initial core to which it is allocated is full, that is, the number of tiles allocated to the core has reached the first threshold, it can be allocated to another core according to the signature value of the tile. Otherwise, it can be directly allocated to the initial core. Optionally, the other core can be an underfilled core, that is, the number of tiles allocated to the core has not yet reached the first threshold of the core, that is, the number of available computing units of the core or other set values ​​has not been reached. Optionally, if the core to which a tile has been allocated through the above redistribution process is also full, the above redistribution process can be continued until the tile is allocated to another core that is not full. This can better balance the load between different cores and further reduce the probability of high-complexity tiles being concentrated on a small number of cores, thereby helping to reduce overall energy consumption and promote improved rendering efficiency.

[0067] In some embodiments, the iterative allocation step may further include: in response to a tile count corresponding to an available core reaching a first threshold, disabling the available core in the current round; and in response to the number of tiles processed in the current round reaching a second threshold, entering the next round and resetting the tile counts for each available core. Optionally, the second threshold may be set to the sum of the first thresholds for each available core, or may be set to another value based on specific needs. Optionally, within each round, the number of tiles processed may be recorded, for example, by a counter or similar software or hardware module. When the recorded number reaches the second threshold, the next round may be entered and the counter or similar module may be reset. Alternatively, only the number of tiles allocated to each core may be recorded. When the tile counts for all cores reach the corresponding first threshold, the number of tiles processed in the current round may be deemed to have reached the second threshold, and the next round may be entered. Optionally, the counter or similar module used to record the number of tiles allocated to each core may be reset upon entering the next round. Optionally, a counter or similar software or hardware module may be used to record the round value. For example, each time the next round begins, the counter or similar module may be incremented by 1. Through the above embodiment, the maximum number of tiles allocated to each available core in each round can be limited, and the allocation operation of all tiles can be completed in order through multiple rounds, wherein at least some tiles are allocated to new available cores.

[0068] Optionally, the various embodiments described above for reallocating rendering target tiles may be implemented after, or in parallel with, the allocation based on core allocation rules or allocation tables. For example, when processing a tile, the available core (initial core) to which it is allocated may be determined based on the core allocation rules or allocation tables described above. A signature value may then be determined based on information such as the tile's coordinates and initial core. Subsequently, a determination may be made based on the rules described above to determine whether to allocate the tile to a new core, thereby determining the available core to which the tile is ultimately allocated.

[0069] For ease of understanding, Figure 7 schematically illustrates an example flow chart of a tile allocation process 700 based on some of the aforementioned embodiments. The tile allocation process 700 can be initiated adaptively based on user control or certain conditions. As shown in Figure 7, after the tile allocation process 700 begins, in step 701, initialization operations can be performed. For example, the state machine of each available core can be initialized based on parameters such as the number of available compute units of each available core and the size of the render target. For example, one or more of the counters for recording the number of tiles allocated to each available core, the counter for recording rounds, and the coordinates of the current tile can be initialized. Furthermore, the maximum number of tiles that can be processed by each available core, i.e., the first threshold, can be determined. As previously described, the maximum number of tiles that can be processed by each available core can be determined as the number of available compute units of each available core, or it can be set to another desired value. In step 702, the tile can be processed based on the tile coordinates, for example, by obtaining or generating tile information, such as primitive information related to the tile. In step 703, an initial core for the current tile can be obtained. This initial core can be determined according to the aforementioned embodiments. In step 704, a signature value may be calculated based on information such as the coordinates of the current tile and the initial core. In step 705, it may be determined whether the initial core is full, that is, whether the number of tiles allocated to the initial core in this round has reached its maximum tile processing number. This may be determined, for example, by comparing the number of tiles allocated to the initial core in this round with its maximum tile processing number or by determining, based on a relevant state machine, whether the initial core has been disabled in this round. If so, the process proceeds to steps 706 and 707; if not, the process proceeds to step 708. In steps 706 and 707, a new core may be determined for the current tile based on the signature value and assigned to the new core; in step 708, the current tile may be assigned to the initial core. In step 709, various relevant information may be updated, such as a counter for recording the number of tiles allocated to the core, the signature value of the current tile, the coordinates of the current tile (e.g., updated to the coordinates of the next tile along a specified direction), etc. In step 710, it can be determined whether the new core is full. If so, proceed to step 711, if not, proceed to step 712. In step 711, the state machine associated with the new core can be updated, for example, it can be updated to a disabled state to indicate that the core is disabled in this round. In step 712, it can be determined whether the number of tiles processed in the current round has reached a threshold. If so, proceed to step 713, if not, proceed to step 714. In step 713, a counter can be reset, such as a counter for recording the number of tiles allocated to each core. In step 714, it can be determined whether all tiles of the rendering target have been processed, for example, whether the last tile has been processed. If so, the tile allocation process 700 is ended, if not, return to step 702 to continue processing the next tile.

[0070] The present disclosure also provides a tile allocation device, which can be integrated into a graphics processing device, such as a GPU. For example, Figure 8 shows a schematic block diagram of a tile allocation device 800 according to some embodiments of the present disclosure. Optionally, the tile allocation device 800 can be set before the rasterization module 140 shown in Figure 1, so as to read the tiles and related primitive information of the rendering object (for example, reading the primitive information through the corresponding primitive block) to complete the allocation of tiles among multiple cores, thereby performing rasterization and subsequent operations more efficiently. As shown in Figure 8, the tile allocation device 800 may include an input terminal 810, a preprocessing module 820 and a tile allocation module 830.

[0071] Specifically, the input terminal 810 can be configured to obtain multiple tiles of a rendering object, where the rendering object includes multiple primitives, and each tile in the multiple tiles is covered by at least one primitive of the rendering object. The pre-processing module 820 can be configured to determine, based on the hardware configuration of the graphics processing device, at least one available core and the number of available computing units included in each of the at least one available cores. The tile allocation module 830 can be configured to allocate the multiple tiles among the at least one available core based on the number of available computing units included in each of the available cores, so that the graphics processing device can call the corresponding available core to perform rendering operations on the corresponding tiles based on the allocation of the multiple tiles among the at least one available core. The tile allocation device 800 can be implemented in software, hardware, or a combination of software and hardware. Multiple different modules can be implemented in the same software or hardware structure, or a single module can be implemented by multiple different software or hardware structures. Exemplarily, the tile allocation device 800 can be implemented in forms such as logic circuits, integrated circuits, programmable gate circuits, programmable logic devices, etc. Furthermore, the tile allocation device 800 can be used to implement at least some of the steps of the rendering method 200 described above. More specifically, the above-mentioned tile allocation module 830 can be configured to execute one or more combinations of the various execution modes of step 230 described in the above embodiments, so as to allocate tiles to corresponding available cores for processing. Exemplarily, one or more of the various execution modes of step 230 can be deployed as algorithm modules in the tile allocation module 830 so as to be called when needed. Optionally, such an algorithm module deployed in the tile allocation module 830 can be modifiable so as to adjust the tile allocation mode or add the desired tile allocation mode according to actual needs. It should be understood that the tile allocation device 800 can have the same features and advantages as described with respect to the aforementioned method. The relevant details have been described in detail in the above text and will not be repeated here for the sake of brevity.

[0072] In some embodiments, the tile allocation device 800 may further include a primitive allocation module, which may be configured to allocate primitives covering the corresponding tiles to each available core based on the allocation of multiple tiles among at least one available core. As previously mentioned, each tile may be covered by at least one primitive, and the primitive allocation module may distribute the primitives covering the tile to the corresponding core based on the core to which the tile is allocated. For example, information such as tile coordinates, primitive sets and corresponding address data may be packaged and delivered to a downstream computing module. Optionally, the primitive allocation module may manage the scheduling order and allocation strategy of the primitives to further optimize the efficiency of graphics rendering. Optionally, the primitive allocation module may allocate primitives to corresponding cores and / or computing units based on the processing methods in the relevant technology.

[0073] In some embodiments, the tile allocation apparatus 800 may further include a post-processing module that can be configured to maintain state information regarding the rendering of multiple tiles by corresponding available cores. For example, the post-processing module can maintain and manage state information regarding primitive processing. This allows for unified management of subsequent rendering operations, helping to improve overall processing efficiency.

[0074] For example, Figure 9 illustrates an example architecture of a tile allocation device according to some embodiments of the present disclosure. As shown, the tile allocation device 910 may include a pre-processing module 911, a tile allocation module 912, a primitive allocation module 913, and a post-processing module 914. As mentioned above, the tile allocation device 910 may be provided before the rasterization module, and thus may also be referred to as a raster parameter processing (RPP) module or other module or device.

[0075] Exemplarily, the pre-processing module 911 can obtain hardware status information, registers, etc. from the memory 940 with the help of the input interface, and obtain the control stream 920 of the front end of the graphics rendering pipeline from the previous module (such as the tile module 130 shown in Figure 1) or in other ways. Exemplarily, the hardware status information may include fragment state words, event status and other information, and the registers may include various parameters, configurations and other information required for hardware processing. Exemplarily, the control stream 920 may include information such as the number of primitive blocks in the tile, the address of the corresponding primitive block, the size of the primitive block, the number of primitives contained, etc. Optionally, depending on the specific application, the address of the primitive block can be calculated using information such as the memory address of the rendering target, the relative coordinates of the tile, or obtained in other ways.

[0076] Exemplarily, the tile allocation module 912 can select an allocation algorithm and allocate tiles according to the selected algorithm. The allocation algorithm can be, for example, the tile allocation scheme in the various embodiments described above with reference to Figures 2A to 7, such as allocation based on core allocation rules, allocation based on allocation tables, allocation based on iterative allocation steps, etc. Optionally, a certain allocation algorithm can be selected for implementation or two or more allocation algorithms can be implemented in combination according to the different scenes to which the rendering target belongs, or the allocation algorithm can be specified by the user. For example, a certain allocation algorithm can be specified by configuring registers, writing APIs (Application Program Interfaces), etc., and the parameters of the algorithm execution can be controlled, which can be achieved, for example, with the help of software control 930. By selecting the implemented allocation algorithm according to different scenes, it is helpful to achieve good adaptation to different scenes and improve the rendering performance in different scenes. For the specific implementation details of the above-mentioned allocation scheme, please refer to the various embodiments described above, which will not be repeated here.

[0077] Exemplarily, the primitive allocation module 913 may allocate input primitives to available cores for parallel processing, such as rasterization 950 or other subsequent operations, wherein the allocation may be performed based on the allocation result provided by the tile allocation module 912. Exemplarily, if a tile has been allocated to an available core, the primitive allocation module 913 may distribute the primitives associated with the tile to the available core, and optionally schedule the execution order of the primitives, the computing units used to process the primitives, and the like. Optionally, the primitive allocation module 913 may perform the following functions: allocate primitives to available cores based on their types and characteristics to further achieve parallel processing and improve rendering performance; determine which tasks should be executed on specific processing units when different cores of a graphics processing device such as a GPU can process multiple tasks simultaneously to achieve efficient allocation and utilization of tasks; and so on.

[0078] For example, the post-processing module 914 can maintain and manage state information during primitive processing. For example, after assigning a tile to a subsequent module, it can update rendering status information, receive special events, and report exceptions. For example, it can maintain the currently processed primitive index, primitive processing status, and error handling.

[0079] The present disclosure also provides a graphics processing device. For example, FIG10 shows a schematic block diagram of a graphics processing device 1000 according to some embodiments of the present disclosure. As shown in FIG10 , the graphics processing device 1000 may include a tile partitioning device 1010 , a tile allocation device 1020 , and a tile rendering device 1030 .

[0080] Specifically, the tile division device 1010 can be configured to: obtain a rendering object and divide the rendering object into multiple tiles, wherein the rendering object includes multiple primitives and each tile is covered by at least one primitive of the rendering object; the tile allocation device 1020 can have the same structure and function as the tile allocation device 800 described above; the tile rendering device 1030 can be configured to: call the corresponding available core to perform rendering operations on the corresponding tiles according to the allocation of multiple tiles among at least one available core.

[0081] The graphics processing device 1000 can be implemented in the form of a circuit, a chip, or the like. For example, the graphics processing device 1000 can be a GPU or other similar device. Furthermore, the graphics processing device 1000 can be used to implement the steps of the rendering method 200 described above. The relevant details have been described in detail above and will not be repeated here for the sake of brevity. The graphics processing device 1000 can have the same features and advantages as those described with respect to the aforementioned method.

[0082] The present disclosure also provides a computing device. For example, FIG11 shows an exemplary block diagram of a computing device 1100. As shown in the figure, the computing device 1100 may include a graphics processing device 1110, which may have the same structure as the graphics processing device 1000 described above. The graphics processing device 1110 may be used to perform operations related to graphics processing and other related operations in the computing device 1100. Optionally, the computing device 1100 may also include various structures such as memory, a central processing unit (CPU), and an I / O (input / output) interface.

[0083] Variations on the disclosed embodiments will be understood and effected by those skilled in the art in practicing the claimed subject matter by studying the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A rendering method for a graphics processing device, characterized in that: The rendering method includes: Obtain a plurality of tiles of a rendering object, wherein the rendering object includes a plurality of primitives, and each tile of the plurality of tiles is covered by at least one primitive of the rendering object; determining at least one available core and a number of available computing units included in each of the at least one available core based on a hardware configuration of the graphics processing device; The multiple tiles are allocated among the at least one available core according to the number of available computing units included in each available core, so that the graphics processing device calls the corresponding available core to perform rendering operations on the corresponding tiles according to the allocation of the multiple tiles among the at least one available core.

2. The rendering method according to claim 1, wherein: Allocating the plurality of tiles among the at least one available core according to the number of available computing units included in each available core comprises: Based on the coordinates of each tile in the plurality of tiles, each tile in the plurality of tiles is allocated to a corresponding available core according to a core allocation rule, The core allocation rule is a rule for allocating a specified number of tiles to each available core in a specified order, wherein the number of tiles allocated to each available core is determined according to the number of available computing units of each available core.

3. The rendering method according to claim 2, wherein: The allocating each of the plurality of tiles to a corresponding available core based on the coordinates of each of the plurality of tiles and according to a core allocation rule comprises: For each tile of the plurality of tiles, determining an allocation round for the tile according to coordinates of the tile and a specified number in the core allocation rule; Each tile in the plurality of tiles is allocated to a corresponding available core according to a position of the tile in a corresponding allocation round and a specified order in the core allocation rule.

4. The rendering method according to claim 2, wherein: The allocating each of the plurality of tiles to a corresponding available core based on the coordinates of each of the plurality of tiles and according to a core allocation rule comprises: Dividing the plurality of tiles into a plurality of tile groups; For each tile group of the plurality of tile groups, determining a core allocation rule corresponding to the tile group; For each tile group, based on the coordinates of each tile in the tile group and according to the core allocation rule corresponding to the tile group, each tile in the tile group is allocated to a corresponding available core.

5. The rendering method according to claim 4, characterized in that: Different tile groups correspond to different core allocation rules.

6. The rendering method according to claim 5, characterized in that: The core allocation rules corresponding to different tile groups have the same core ordering and different starting cores.

7. The rendering method according to claim 1, wherein: Allocating the plurality of tiles among the at least one available core according to the number of available computing units included in each available core comprises: In response to the rendering object belonging to a preset scene, obtaining an allocation table corresponding to the preset scene; The plurality of tiles are allocated among the at least one available core according to the allocation table.

8. The rendering method according to any one of claims 2 to 7, characterized in that: Allocating the plurality of tiles among the at least one available core according to the number of available computing units included in each available core further comprises: For each tile of the plurality of tiles, determining a signature value for the tile based at least on coordinates of the tile and an available core to which the tile is assigned; Based on the signature values ​​of the tiles, available cores to which at least some of the tiles are allocated are updated.

9. The rendering method according to claim 8, characterized in that: The updating, based on the signature value of the tile, of the available cores to which at least some of the plurality of tiles are allocated comprises: Initializing a tile identifier of a current tile and a tile count of each available core, wherein the current tile is a tile currently being processed, and the tile count indicates the number of tiles allocated to the corresponding available core; Performing an iterative allocation step, the iterative allocation step comprising: In response to a tile count corresponding to the available core to which the current tile is allocated reaching a first threshold, allocating the current tile to another available core according to the signature value of the current tile, so as to update the available core to which the current tile is allocated, and incrementing the tile count of the another available core by 1; In response to the tile count corresponding to the available core to which the current tile is allocated not reaching the first threshold, incrementing the tile count of the available core by 1; In response to the current tile being the last tile, stopping iteration; In response to the current tile being not the last tile, the tile identifier of the current tile is updated to the tile identifier of the next tile along a specified direction.

10. The rendering method according to claim 9, characterized in that: The iterative allocation step further comprises: In response to the tile count corresponding to an available core reaching the first threshold, disabling the available core in a current round; In response to the number of tiles processed in the current round reaching a second threshold, entering the next round, and resetting the tile count of each available core.

11. A tile allocation device, characterized in that: The tile allocation device is integrated into a graphics processing device and includes: An input end is configured to: obtain a plurality of tiles of a rendering object, the rendering object comprising a plurality of primitives, each tile of the plurality of tiles being covered by at least one primitive of the rendering object; a pre-processing module configured to: determine at least one available core and a number of available computing units included in each of the at least one available core based on a hardware configuration of the graphics processing device; The tile allocation module is configured to allocate the multiple tiles among the at least one available core according to the number of available computing units included in each available core, so that the graphics processing device calls the corresponding available core to perform rendering operations on the corresponding tiles according to the allocation of the multiple tiles among the at least one available core.

12. The tile allocation device according to claim 11, characterized in that: The tile allocation device further comprises: The primitive allocation module is configured to allocate primitives covering corresponding tiles to each available core according to the allocation of the multiple tiles among the at least one available core.

13. The tile allocation device according to claim 11 or 12, characterized in that: The tile allocation device further comprises: The post-processing module is configured to maintain status information of the plurality of tiles during a rendering process by corresponding available cores.

14. A graphics processing device, characterized in that: The graphics processing device comprises: A block division device is configured to: obtain a rendering object, and divide the rendering object into a plurality of blocks, wherein the rendering object includes a plurality of primitives, and each block is covered by at least one primitive of the rendering object; The tile allocation device according to any one of claims 11 to 13; The tile rendering device is configured to: call a corresponding available core to perform a rendering operation on a corresponding tile according to the distribution of the plurality of tiles among at least one available core.

15. A computing device, characterized in that The computing device includes the graphics processing device of claim 14 .

Images