Tile rendering control method, controller and apparatus, graphics processor and device

Abstract

Embodiments of the present disclosure provide a control method, a controller and an apparatus of tile rendering, a graphics processor and a device, which are applied to the technical field of computer to at least solve the problems of high hardware resource consumption and low GPU utilization rate in the process of tile rendering. The control method comprises: dividing a tile into at least one first sub-tile; wherein the tile is obtained by dividing a to-be-rendered picture, and the to-be-rendered picture comprises at least two to-be-rendered layers; determining at least one second sub-tile from the at least one first sub-tile based on a first primitive list of the tile; wherein the first primitive list of the tile comprises at least one primitive in at least one to-be-rendered layer; and rendering the at least one second sub-tile by using a target rendering core corresponding to the tile.

Description

Technical Field

[0001] This disclosure relates to, but is not limited to, the field of computer technology, and in particular to a control method, controller and apparatus, graphics processor and device for tile rendering. Background Technology

[0002] In the DirectX (DX) standard, it is possible to bind a render target (RT) to a 2D array of resources (such as scenes, textures, etc.) to achieve multi-layer rendering, that is, to render multiple rendering scenes or multiple texture resources to different layers respectively.

[0003] In related technologies, in the Tile-based Rendering (TBR) architecture, rendering is typically done layer by layer. First, since each layer requires specific hardware (e.g., fireware) to perform register initialization, this not only prolongs the initialization time but also increases hardware resource consumption. Second, because the subsequent layer must wait for the previous layer to finish rendering, the two layers are not continuous in the hardware, resulting in more idle time for the GPU (Graphics Processing Unit) (also known as pipeline interrupts), reducing GPU utilization. Finally, since each layer needs to perform the same operations such as tile partitioning and data reading (e.g., the metadata that the tile needs to render), it increases hardware resource consumption. Summary of the Invention

[0004] This disclosure provides a control method, controller and apparatus for tile rendering, graphics processor, electronic device, storage medium and computer program product.

[0005] The technical solution of this disclosure embodiment is implemented as follows:

[0006] This disclosure provides a method for controlling tile rendering, the method comprising:

[0007] The tile is divided into at least one first sub-tile; wherein the tile is obtained by dividing the screen to be rendered, and the screen to be rendered includes at least two layers to be rendered;

[0008] Based on the first primitive list of the block, at least one second sub-block is determined from the at least one first sub-block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered;

[0009] The at least one second sub-tile is rendered using the target rendering core corresponding to the tile.

[0010] This disclosure provides a graphics processor including at least two rendering cores. The graphics processor performs tile rendering based on a tile rendering (TBR) architecture, wherein:

[0011] The partitioning module in the backend module of the TBR architecture is used to divide a tile into at least one first sub-tile; wherein the tile is obtained by partitioning the image to be rendered, and the image to be rendered includes at least two layers to be rendered.

[0012] The processing module in the backend module of the TBR architecture is used to determine at least one second sub-block from the at least one first sub-block based on the first primitive list of the block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered;

[0013] The backend module of the TBR architecture is used to render the at least one second sub-tile using the target rendering core corresponding to the tile.

[0014] This disclosure provides a control device for tile rendering, the device comprising:

[0015] The first determining module is used to divide a tile into at least one first sub-tile; wherein the tile is obtained by dividing the screen to be rendered, and the screen to be rendered includes at least two layers to be rendered;

[0016] The second determining module is configured to determine at least one second sub-block from the at least one first sub-block based on the first primitive list of the block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered;

[0017] A rendering module is used to render the at least one second sub-tile using the target rendering core corresponding to the tile.

[0018] This disclosure provides an electronic device including a processor and a memory, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the above-described method.

[0019] This disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0020] This disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements the above-described method.

[0021] In this embodiment of the disclosure, a map tile is divided into at least one first sub-map tile; wherein the map tile is obtained by dividing the image to be rendered, and the image to be rendered includes at least two layers to be rendered; based on the first primitive list of the map tile, at least one second sub-map tile is determined from the at least one first sub-map tile; wherein the first primitive list of the map tile includes at least one primitive from at least one layer to be rendered; and the at least one second sub-map tile is rendered using the target rendering core corresponding to the map tile. In this way, by uniformly dividing multiple layers to be rendered into tiles, the primitive list of the same tile contains primitives from different layers to be rendered, thus merging multiple layers to be rendered. First, compared to initializing each layer individually, initializing multiple layers to be rendered in a single initialization not only shortens the initialization time but also reduces hardware resource consumption. Second, compared to the subsequent layer rendering having to wait for the previous layer to finish, processing multiple layers to be rendered simultaneously ensures continuity between them in the hardware, thereby reducing GPU idle time and improving GPU utilization while reducing the possibility of hardware performance degradation due to pipeline interruptions. Finally, compared to performing the same tile division and data reading operations on each layer separately, only the merged layers to be rendered need to undergo tile division and data reading operations, further reducing hardware resource consumption.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure.

[0024] Figure 1A This is a schematic diagram of a multi-layer rendering technique in related technologies;

[0025] Figure 1B This is a schematic diagram of a typical TBR rendering pipeline.

[0026] Figure 1C This is a schematic diagram of data from multiple layers to be rendered in a related technology.

[0027] Figure 1D This is a schematic diagram of a multi-layer rendering technique in related technologies;

[0028] Figure 1E A schematic diagram illustrating the implementation flow of a tile rendering control method provided in this embodiment of the present disclosure;

[0029] Figure 1FThis is a schematic diagram of a screen to be rendered, provided as an embodiment of the present disclosure;

[0030] Figure 1G A schematic diagram of determining a second sub-block provided in an embodiment of this disclosure;

[0031] Figure 1H A schematic diagram of a first primitive list provided in an embodiment of this disclosure;

[0032] Figure 2 A schematic diagram of the implementation flow of a tile rendering control method provided in this embodiment of the present disclosure. Figure 2 ;

[0033] Figure 3 A schematic diagram of the implementation flow of a tile rendering control method provided in this embodiment of the present disclosure. Figure 3 ;

[0034] Figure 4A A schematic diagram of the composition structure of a graphics processor provided in an embodiment of this disclosure;

[0035] Figure 4B This is a schematic diagram illustrating the storage location of multiple layers to be rendered in memory, provided in an embodiment of the present disclosure.

[0036] Figure 4C A schematic diagram of multi-layer rendering provided for an embodiment of this disclosure;

[0037] Figure 4D A schematic diagram of a typical TBR rendering pipeline provided in an embodiment of this disclosure;

[0038] Figure 5 This is a schematic diagram of the composition structure of a control device for tile rendering provided in an embodiment of the present disclosure;

[0039] Figure 6 This is a schematic diagram of a hardware entity of an electronic device according to an embodiment of this disclosure. Detailed Implementation

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

[0041] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0042] In the following description, the terms “first, second, third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first, second, third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this disclosure described herein can be implemented in an order other than that illustrated or described herein.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used herein is for the purpose of describing embodiments of this disclosure only and is not intended to be limiting of this disclosure.

[0044] In DirectX, rendering targets (RTs) can be bound to multiple scenes or textures within a 2D array. A geometry shader (GS) outputs an index value (Render Target ArrayIndex, rta_idx) for each primitive in these scenes or textures. The output merging stage then renders each primitive to different layers based on its rta_idx, thus achieving multi-layer rendering. Figure 1A This is a schematic diagram of a multi-layer rendering technique in related technologies, such as... Figure 1A As shown, the graphics processor receives multiple primitives 101 after GS processing, and parses each primitive 101 to obtain the rta_idx of each primitive 101. Based on the rta_idx of each primitive 101, it renders it to different layers 102 of the rendering target.

[0045] The TBR architecture subdivides computer graphics images into regular grids in optical space and renders them as either grids or tiles. The advantage of this design is that it reduces memory and bandwidth consumption compared to Immediate Mode Rendering (IMR), which renders the entire frame immediately. This makes TBR widely used in low-power hardware devices.

[0046] Figure 1B This is a typical TBR rendering pipeline diagram, such as Figure 1B As shown, this TBR rendering pipeline (i.e., the TBR architecture) is divided into a front-end module 110 (also known as the geometry stage) and a back-end module 120 (also known as the 3D stage), wherein:

[0047] The front-end module 110 includes a vertex processing module, a graphics processing module, and a tile module. The vertex processing module is used to perform vertex and primitive transformations on the graphics data 150. The graphics processing module is used to perform primitive culling, clipping, and other processing. The tile module is used to complete the screen segmentation, record the graphics data covered by the tiles, and write the generated information such as the primitive list and vertex data into the system memory 130. The primitive list is a fixed-length array of length tile. Each element in the array is a linked list that stores pointers to all triangles that intersect with the current tile. The pointers point to the vertex data. The vertex data stores vertex and vertex attribute data.

[0048] The backend module 120 includes a rasterization module, a hidden surface removal (HSR) module, a pixel shading module, and an output merging module. The rasterization module is used to convert primitives into a two-dimensional image. Each point in the two-dimensional image contains color, depth, and texture data. This point and its related information are called a fragment. The HSR module is used to remove occluded triangles. The pixel texture shading module is used to shading pixels. The output merging module is used to merge multiple patches and output them to the RT.

[0049] For each tile, since its data volume is small, the required depth data, texture data, and color data can be loaded into the GPU's on-chip static random-access memory (SRAM), i.e., on-chip memory 140. For example, the hidden surface removal module can store depth data in the depth buffer in on-chip memory 140, the pixel shading module can store texture data in the texture buffer in on-chip memory 140, and the output merging module can store color data in the color buffer in on-chip memory 140.

[0050] In the rendering process, the rendered object (image) is divided into multiple tiles, and the on-chip memory 140 can hold all the data of this tile. After at least one drawing instruction reaches the GPU, the front-end module 110 processes each drawing instruction sequentially and stores the corresponding tile information and vertex information in the system memory 130 until the data stored in the system memory 130 reaches a preset threshold or at least one drawing instruction has been processed. The back-end module 120 reads the corresponding vertex information from the system memory 130 in units of tiles and performs subsequent processing. In this way, by changing the back-end module 120's access to the system memory 130 to the back-end module 120's access to the on-chip memory 140, rendering efficiency can be improved.

[0051] In related technologies, within the TBR architecture, the front-end module typically outputs data from each layer to system memory for use by the back-end module. The data for each layer includes tile partitioning information and a polygon list for each tile within that layer. Polygons refer to the basic geometric units that constitute the graphics, such as points, lines, and triangles. Figure 1C This is a schematic diagram of data from multiple layers to be rendered in a related technology, such as... Figure 1C As shown, the image to be rendered includes layers 1 (i.e., layer 0) to 3 (i.e., layer 2). Each layer is divided into 9 tiles: layer 0 includes tiles 00 to 08, layer 1 includes tiles 10 to 18, and layer 2 includes tiles 20 to 28. Each tile contains a list of primitives; for example, tile 00 includes primitive list 00, tile 10 includes primitive list 10, and tile 20 includes primitive list 20. Simultaneously, the backend module is started by the specified hardware (Fireware) to render the data for each layer separately. Figure 1D This is a schematic diagram of a multi-layer rendering technique in related technologies, such as... Figure 1D As shown, where:

[0052] The front-end module 110 outputs the image data of each layer to the GPU's memory 152;

[0053] After receiving a signal 154 indicating that all layers have been processed, the designated hardware 153 first kicks the first layer (i.e., layer 0 to be rendered) to the backend module 120 for rendering. After the first layer is rendered, the second layer (i.e., layer 1 to be rendered) is kicked down to the backend module 120 for rendering, until the tenth layer (i.e., layer 9 to be rendered) is kicked down to the backend module 120 for rendering.

[0054] The backend module 120 receives rendering instructions, retrieves data for one layer from the GPU's memory 152, and writes the data for that layer to the corresponding location in the RT to complete the rendering of that layer.

[0055] First, because rendering is done layer by layer, and each layer requires hardware to perform register initialization and other preparatory work, this not only prolongs the initialization time but also increases hardware resource consumption. Second, since the rendering of the next layer must wait for the rendering of the previous layer to finish, the two layers are not continuous in the hardware, resulting in more idle time for the GPU and reducing GPU utilization. Finally, because each layer needs to perform the same operations such as tiling and data reading (e.g., the graph data that the tile needs to render), hardware resource consumption is increased.

[0056] This disclosure provides a method for controlling tile rendering. By uniformly dividing multiple layers to be rendered into tiles, the primitive list of the same tile contains primitives from different layers to be rendered, thus merging multiple layers to be rendered. First, compared to initializing each layer individually, initializing multiple layers to be rendered in a single initialization not only shortens the initialization time but also reduces hardware resource consumption. Second, compared to rendering the next layer only after the previous layer has finished, processing multiple target layers to be rendered simultaneously ensures continuity between them in the hardware, thereby reducing GPU idle time and improving GPU utilization while reducing the possibility of hardware performance degradation due to pipeline interruptions. Finally, compared to performing the same tile division and data reading operations on each layer separately, only the merged layers to be rendered need to undergo tile division and data reading operations, further reducing hardware resource consumption.

[0057] The method provided in this disclosure can be executed by the graphics processor of an electronic device. The electronic device can be various types of terminals such as laptops, tablets, desktop computers, set-top boxes, and mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), or it can be implemented as a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0058] The technical solutions in the embodiments of this disclosure will now be clearly and completely described with reference to the accompanying drawings.

[0059] Figure 1E This is a schematic diagram illustrating the implementation flow of a tile rendering control method provided in an embodiment of this disclosure, as shown in Figure 1. Figure 1E As shown, the method includes steps S11 to S13, wherein:

[0060] Step S11: Divide the tile into at least one first sub-tile; wherein the tile is obtained by dividing the screen to be rendered, and the screen to be rendered includes at least two layers to be rendered.

[0061] Here, since each layer to be rendered has the same size, the image to be rendered is uniformly divided using the first partitioning strategy, resulting in at least one tile. The first partitioning strategy may include, but is not limited to, partitioning method, partition length, and number of partitions. The partitioning method may include, but is not limited to, uniform partitioning, random partitioning, and non-uniform partitioning. For example, the image to be rendered can be uniformly divided into 8 tiles. Alternatively, the image to be rendered can be divided according to any suitable preset size, such as 4x4, to obtain multiple tiles.

[0062] Because the tile size is relatively large and the tile may be covered by primitives from multiple rendering layers, the tile can be further divided according to the second partitioning strategy to obtain at least one first sub-tile. The second partitioning strategy may include, but is not limited to, partitioning method, partitioning length, and partitioning size. The partitioning size can be dynamically configured, representing the size of the first sub-tile, i.e., the number of pixels contained in the first sub-tile. In some implementations, the partitioning size can be determined based on the granularity of the cache line and the data format of the cache module. The granularity of the cache line refers to the size of the cache line, which can be any suitable granularity, such as 64 bytes or 128 bytes (i.e., 2Kbits). The data format may include, but is not limited to, FP32 (single-precision floating-point number), FP16 (half-precision floating-point number), and INT8 (8-bit integer). For example, if the cache line granularity is 2Kbits, and a pixel has 32 bits, then the size of the first sub-tile could be 8*8 (2*2...). 10 / 32), meaning that a single cache line can store the data for the first sub-tile. Alternatively, the size of the first sub-tile can be larger, allowing multiple cache lines to store the data for one first sub-tile.

[0063] Step S12: Based on the first primitive list of the block, determine at least one second sub-block from the at least one first sub-block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered.

[0064] Here, the first primitive list includes at least one primitive. Different primitives may originate from different layers to be rendered. For example, if the image to be rendered includes 10 layers to be rendered, and the first primitive list includes 100 primitives, then these 100 primitives may come from these 10 layers to be rendered, or they may be some of the layers to be rendered.

[0065] Figure 1F This is a schematic diagram of a screen to be rendered provided in an embodiment of the present disclosure, such as... Figure 1F As shown, the image to be rendered 160 includes at least three layers to be rendered. The image to be rendered 160 is divided into 9 tiles, namely: tile 0 to tile 8. For tile 0, the first primitive list of tile 0 may contain primitive data in RT0 (first layer to be rendered), RT1 (second layer to be rendered), and RT2 (third layer to be rendered).

[0066] The second sub-block is a valid sub-block. During implementation, if a first sub-block intersects with a graphic element, then the first sub-block is considered a valid sub-block, i.e., the second sub-block.

[0067] In some embodiments, step S12 includes step S121, wherein:

[0068] Step S121: For each element in the first element list of the map block, determine at least one second sub-map block based on the position information of the element and each first sub-map block.

[0069] Here, each primitive in the first primitive list can be traversed, and its position information can be compared with the range of each first sub-plot to determine which first sub-plots it intersects with. Each intersecting first sub-plot is then treated as a second sub-plot. When the first primitive list contains primitive data of multiple rendering layers for a single plot, any first sub-plot that intersects with the primitive data of one or more rendering layers can be treated as a second sub-plot.

[0070] In some implementations, the step S121 of "determining at least one second sub-block based on the location information of the primitives and each of the first sub-blocks" includes step S1211, wherein:

[0071] Step S1211: For each first sub-block, if the position information of the graphic element belongs to the range of the first sub-block, the first sub-block is regarded as a second sub-block.

[0072] Here, if the primitive intersects with a first sub-block, the first sub-block is treated as a second sub-block; otherwise, if the first sub-block does not intersect with the primitive, the first sub-block is treated as an invalid sub-block, that is, the first sub-block does not need to be rendered, and therefore the backend module of the rendering pipeline does not need to process it.

[0073] "Intersection" can also refer to the intersection range between the position of a graphic element and the position of the first sub-block exceeding a preset threshold. The preset threshold can be 0. When the preset threshold is 0, as long as the position of the graphic element overlaps with the position of the first sub-block, it is considered to be intersecting.

[0074] Figure 1G This is a schematic diagram of determining a second sub-block provided in an embodiment of the present disclosure, such as... Figure 1G As shown, the image to be rendered 170 is divided into 16 blocks, namely: T0~T15. Among them, T5 is further divided into 16 first sub-blocks, namely: T500~T515. Since some of the primitives 171 in the image to be rendered 170 cover T5, according to the range of T500~T515 and the position information of primitive 171, T502, T503, and T505~T515 are respectively regarded as second sub-blocks, and T500, T501, and T504 are respectively regarded as invalid first sub-blocks.

[0075] Step S13: Render the at least one second sub-tile using the target rendering core corresponding to the tile.

[0076] Here, the GPU includes a preset number of rendering cores, such as 4 or 8. Different tiles can be rendered by different rendering cores. In implementation, each rendering core can handle any suitable preset number of tiles, such as 4, 6, or 8. In some implementations, different rendering cores can handle the same or different numbers of tiles. For example, rendering cores Core0 to Core2 can each handle 4 tiles, or rendering cores Core0 and Core1 can handle 8 tiles, and rendering core Core2 can handle 4 tiles.

[0077] In principle, the rendering core that can process the most tiles or is relatively less busy (e.g., has more tiles to be rendered) should be selected as the target rendering core to ensure load balancing among the rendering cores.

[0078] In some implementations, each rendering core can be sorted according to its tile indication information to obtain its order information, and the target rendering core corresponding to a tile can be determined based on this order information. Each tile indication information indicates the number of tiles that the corresponding rendering core can receive for rendering. For example, for rendering core Core1, if there are 2 tiles to be rendered in Core1, and Core1 can process a maximum of 4 tiles, then the tile indication information for Core1 is 2. The order information can be determined, but is not limited to, by using the tile indication information to indicate the number of tiles from most to least (descending order), from least to most (ascending order), or by a tile threshold. The tile threshold represents the maximum number of tiles that a rendering core can process.

[0079] In some implementations, the sequence information can be determined based on the block indication information.

[0080] For example, a GPU includes rendering cores Core 0 through Core 2, each capable of processing a maximum of 4 tiles. If the tile indication information for rendering core Core 0 is 0 (meaning it has received 4 tiles to be rendered, and can receive 0 more tiles to be rendered), the tile indication information for rendering core Core 1 is 2, and the tile indication information for rendering core Core 2 is 4, then based on the tile indication information of each rendering core:

[0081] The rendering cores are sorted in descending order as follows: Core 2, Core 1, Core 0. The order information of Core 0 to Core 2 is 3, 2, 1 respectively. At this time, the Core with the smallest order can be used as the target rendering core.

[0082] If we sort the rendering cores from fewest to most as follows: Core 0, Core 1, Core 2, then the order information of Core 0 to Core 2 is 1, 2, 3 respectively. In this case, the Core with the highest order can be selected as the target rendering core.

[0083] That is, you can choose the rendering core with the most available tiles to be rendered, which is the relatively idle rendering core, as the target rendering core.

[0084] In some implementations, the order information can be determined according to a tile threshold. For example, if a GPU includes rendering cores Core 0 to Core 2, and Core 0 and Core 2 can process 8 tiles, while Core 1 can process 4 tiles, then the order information for Core 0 to Core 2 is 1, 3, and 2, respectively.

[0085] In some implementations, the order information can be obtained simply by moving the rendering cores that meet the conditions (e.g., full load, busy, etc.) to the end, without having to compare each rendering core with the conditions.

[0086] For example, a GPU includes rendering cores Core 0 to Core 2, each of which can process up to 4 tiles. Each rendering core is sorted according to a tile threshold plus a condition. Although the tile thresholds of Core 0 to Core 2 are the same, the sorting can be: Core 0, Core 1, Core 2. However, since Core 0 is fully loaded, it needs to be moved to the end. Therefore, the sorting can be updated to: Core 1, Core 2, Core 0. The order information of Core 0 to Core 2 is 3, 1, 2 respectively.

[0087] In some implementations, the order information of different rendering cores can be the same or different. For example, if the tile indicator information of rendering core 1 and rendering core 2 are the same, then the order information of rendering core 1 and rendering core 2 can be the same. Alternatively, if the tile indicator information of rendering core 1 and rendering core 2 are the same, the order information of rendering core 1 and rendering core 2 can be further distinguished based on naming, status information, etc. The status information may include, but is not limited to, busy status, idle status, etc.

[0088] The method for determining the target rendering core can include, but is not limited to, random, custom, first, or sequential. For example, the rendering core with the first order can be used as the target rendering core. Another example is to randomly select a rendering core from multiple rendering cores with the same order as the target rendering core.

[0089] In some implementations, each rendering core can be sorted according to its tile indicator information and its naming information to obtain the order information of each rendering core. For example, if the tile indicator information of rendering core Core 1 and rendering core Core 2 are the same, then the order information of rendering core Core 1 can be determined as 1, and the order information of rendering core Core 2 as 2, based on their naming information.

[0090] In some implementations, each rendering core can be sorted according to its tile indicator information and its status information to obtain its order information. For example, if a GPU includes rendering cores Core 0 to Core 2, and each rendering core is sorted according to its tile indicator information, the first order information for rendering cores Core 0 to Core 2 is 3, 1, and 2 respectively. Since rendering core Core 1 is in a busy state, the first order information is updated according to the status information of each rendering core, resulting in the order information for rendering cores Core 0 to Core 2 being 3, 2, and 1 respectively.

[0091] In some implementations, if the image to be rendered is divided into multiple tiles, then all rendering cores may be target rendering cores, and the multiple tiles of the image to be rendered may be assigned to all rendering cores. For example, if the GPU includes four rendering cores, Core0 to Core3, and each rendering core can process four tiles, then when the image to be rendered is divided into eight tiles, these eight tiles can be assigned to at least two rendering cores. For example, Core0 and Core1 may each be assigned four tiles, or Core0 may be assigned one tile, Core1 may be assigned four tiles, and Core2 may be assigned three tiles. When the image to be rendered is divided into at least ten tiles, these at least ten tiles can be assigned to each rendering core, that is, Core0 may be assigned one tile, Core1 to Core2 may be assigned four tiles, and Core3 may be assigned one tile.

[0092] In practice, the rendering process of each second sub-plot by the rendering core corresponding to the plot may include: performing rasterization, pixel shading and output merging on each second sub-plot in sequence, thereby completing the rendering of each second sub-plot.

[0093] In this embodiment, by uniformly dividing multiple layers to be rendered into tiles, the primitive list of the same tile contains primitives from different layers to be rendered, thus merging multiple layers to be rendered. First, compared to performing initialization work for each layer, initializing multiple layers to be rendered in a single initialization process not only shortens the initialization time but also reduces hardware resource consumption. Second, compared to the subsequent layer rendering having to wait for the previous layer to finish, processing multiple target layers to be rendered simultaneously ensures continuity between them in the hardware, thereby reducing GPU idle time and improving GPU utilization while reducing the possibility of hardware performance degradation due to pipeline interruptions. Finally, compared to performing the same tile division and data reading operations for each layer separately, only the merged layers to be rendered need to undergo tile division and data reading operations, further reducing hardware resource consumption.

[0094] In some embodiments, the method further includes step S14, wherein:

[0095] Step S14: Based on the description information of the block, determine the first primitive list of the block from the second primitive list.

[0096] Here, the second primitive list includes at least one primitive from at least two layers of the image to be rendered. In implementation, all primitives from all layers of the image to be rendered are placed into this second primitive list.

[0097] The description information of a tile is used to describe the tile's load information, that is, which primitives in each layer to be rendered intersect with the tile. In implementation, by parsing the description information of the tile, the first primitive list of the tile can be obtained from the second primitive list, that is, primitives that intersect with the tile can be selected from the second primitive list.

[0098] In some implementations, for each primitive in each layer to be rendered, based on the primitive's position information, it is determined which blocks the primitive intersects with, so as to obtain the load information of each block.

[0099] In this embodiment, the first primitive list of the block is determined from the second primitive list based on the block's description information. This shortens the time required to determine the first primitive list of the block. Furthermore, since the block's description information includes intersection results with primitives in multiple rendering layers, compared to parsing the description information of each block in each rendering layer separately, only one parsing is needed to obtain the intersection results, thus reducing hardware resource consumption.

[0100] In some embodiments, the second primitive list includes primitive structures and layer identifier structures; the method further includes steps S15 to S16, wherein:

[0101] Step S15: Place at least one primitive from the at least two layers to be rendered into the primitive structure in sequence.

[0102] Here, the primitive structure is used to store the individual primitives. In implementation, each primitive can be placed into the primitive structure in the order of output from the VS (Vertex Shader) / GS.

[0103] Step S16: According to the order of the at least one graphic element in the graphic element structure, put the layer identifiers corresponding to the at least one graphic element into the layer identifier structure in sequence.

[0104] Here, the layer identifier structure is used to store the rendering layer to which each primitive belongs. Different rendering layers have different layer identifiers. In implementation, to facilitate subsequent calculation of the storage location of each primitive, the layer identifier of the rendering layer to which the primitive belongs needs to be placed in this layer identifier structure. During the rendering process, since each rendering layer has the same size, the backend module can determine the starting address of the rendering layer to which the second sub-tile belongs in the GPU's memory based on the base address of the RTA (Render Target Array), the size of each rendering layer, and the layer identifier of the rendering layer to which the second sub-tile belongs. Then, based on the information carried by the second sub-tile, the target address of the rendering data (including color, depth, texture, etc.) of the second sub-tile in the GPU's memory is determined. The information carried by the second sub-tile may include, but is not limited to, the layer identifier of the rendering layer to which the second sub-tile belongs, and the position information of the second sub-tile in the rendering layer. In implementation, the information carried by the second sub-tile can be implemented in the form of structures, key-value pairs, tables, etc.

[0105] Figure 1H This is a schematic diagram of a first primitive list provided in an embodiment of the present disclosure, such as... Figure 1HAs shown, the first primitive list 180 includes a primitive structure 181, a layer identifier structure 182, and other structures 183. The primitive structure 181 stores each primitive in each layer to be rendered (e.g., position, color, depth, etc.). The layer identifier structure 182 stores the layer identifier to which each primitive belongs. The other structures 183 store other data, such as depth test data, stencil test data, rasterization enable data, etc. In implementation, the order of primitives in the primitive structure 181 is consistent with the order of the layer identifiers to which the primitives belong in the layer identifier structure 182. That is, if primitive P0, primitive P1, primitive P2, etc., are stored sequentially in the primitive structure 181, then the layer identifier idx (Index) of primitive P0, the layer identifier idx of primitive P1, the layer identifier idx of primitive P2, etc., are stored sequentially in the layer identifier structure 182.

[0106] In this embodiment, at least one primitive from the at least two layers to be rendered is sequentially placed into the primitive structure; and layer identifiers corresponding to the at least one primitive are sequentially placed into the layer identifier structure according to their order in the primitive structure. In this way, all primitives of all layers to be rendered are sequentially placed into the first primitive list. Compared to related technologies that require a dedicated primitive list for each layer to store its primitive data, this disclosure reduces the possibility of wasted memory resources because it does not require a separate primitive list for each layer to be rendered.

[0107] Figure 2 A schematic diagram of the implementation flow of a tile rendering control method provided in this embodiment of the present disclosure. Figure 2 ,like Figure 2 As shown, the method includes steps S21 to S24, wherein:

[0108] Step S21: Determine the partition size based on the granularity of the cache lines of the cache module; wherein the cache module is located in the target rendering core.

[0109] Here, the granularity of a cache line refers to its size. Since the primitives in the first primitive list of a tile come from different layers to be rendered, during rendering, the corresponding primitive data needs to be retrieved from different memory addresses. When there are many layers in the image to be rendered, the address range and space requirements of different layers also increase. In traditional TBR, each tile can only be bound to one in-slice depth buffer (DB) and color buffer (CB). The DB and CB can only be released after the tile is rendered. Since the DB and CB can only be mapped to a fixed memory location, it is difficult to switch between address regions in different layers. Therefore, to improve the efficiency of depth / color data replacement, a cache module is integrated on each rendering core to store the tile's depth / color / template data. In some implementations, this cache module can allocate cache lines at the size of sub-tiles. The data of a sub-tile can be stored in one or at least two cache lines.

[0110] The partition size can be any suitable size, such as 4*4, 2*4, 2*8, 8*8, etc. This partition size represents the size of the first sub-tile, that is, the number of pixels contained in the first sub-tile. In implementation, the partition size is dynamically configured. In some embodiments, the partition size can be determined based on the granularity of the cache line, data format, etc. The data format can include, but is not limited to, FP32, FP16, INT8, etc. For example, different cache line granularities can correspond to the same or different partition sizes. Another example is that the partition size is determined in real-time based on the cache line granularity and data format. For instance, if the cache line granularity is 1Kbits, and a pixel has 32 bits, then the partition size could be 4*8, i.e., 2Kbits, 2*4, 2*8, 8*8, etc. 10 / 32, the number of cache line bits divided by the number of bits per pixel. In this case, one cache line stores one first sub-tile. If a first sub-tile is stored in two cache lines, the size of the first sub-tile can be 8x8.

[0111] Step S22: Divide the image block according to the division size to obtain at least one first sub-image block; wherein the image block is obtained by dividing the image to be rendered, and the image to be rendered includes at least two layers to be rendered.

[0112] Here, the process of dividing the image to be rendered can be found in the specific implementation of step S11 above. In practice, the image block is divided according to the determined division size to obtain multiple first sub-image blocks. For example, in... Figure 1GIn this process, block 5 is divided into 16 first sub-blocks according to the determined division dimensions. In some implementations, since each block is the same size, the division dimensions of each block are also the same.

[0113] Step S23: Based on the first primitive list of the block, determine at least one second sub-block from the at least one first sub-block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered.

[0114] Step S24: Render the at least one second sub-tile using the target rendering core corresponding to the tile.

[0115] Here, steps S23 to S24 correspond to steps S12 to S13, respectively. In implementation, the specific implementation methods of steps S12 to S13 can be referred to.

[0116] In this embodiment of the disclosure, a caching module is used to temporarily store the data of each valid sub-tile, so as to continuously process primitives of different rendering layers and reduce the possibility of hardware performance degradation caused by pipeline interruption.

[0117] Figure 3 A schematic diagram of the implementation flow of a tile rendering control method provided in this embodiment of the present disclosure. Figure 3 ,like Figure 3 As shown, the method includes steps S31 to S34, wherein:

[0118] Step S31: Divide the tile into at least one first sub-tile; wherein the tile is obtained by dividing the screen to be rendered, and the screen to be rendered includes at least two layers to be rendered.

[0119] Step S32: Based on the first primitive list of the block, determine at least one second sub-block from the at least one first sub-block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered.

[0120] Here, steps S31 to S32 correspond to steps S11 to S12, respectively. In implementation, the specific implementation methods of steps S11 to S12 can be referred to.

[0121] Step S33: Determine the target cache line corresponding to the second sub-tile from at least one cache line in the cache module, and store the primitive information corresponding to the second sub-tile in the target cache line; wherein, the cache module is located in the target rendering core corresponding to the tile.

[0122] Here, the caching module includes multiple cache lines. The number of target cache lines corresponding to the second sub-tile can be at least one. In implementation, cache lines can be allocated based on their respective states, which may include, but are not limited to, occupied and unoccupied states. An occupied state indicates that the current cache line already stores primitive information corresponding to other second sub-tiles. An unoccupied state indicates that the current cache line can be used to store primitive information corresponding to second sub-tiles. Primitive information may include, but is not limited to, color and depth. In implementation, the primitive information corresponding to the second sub-tile can be retrieved from the memory storing the first primitive list and stored in the target cache line corresponding to that second sub-tile. It is understood that when there are at least two second sub-tiles, it is necessary to determine the corresponding target cache line for each second sub-tile.

[0123] In some implementations, step S33, "determining the target cache line corresponding to the second sub-plot from at least one cache line in the cache module," includes steps S331 to S332, wherein:

[0124] Step S331: Iterate through at least one cache line in the cache module in sequence, determine the traversal result of the second sub-plot based on the state of the currently traversed cache line, and stop traversing if the traversal result of the second sub-plot is the first result.

[0125] Here, the traversal results can include, but are not limited to, a first result, a second result, etc. The first result indicates that the currently traversed cache line is in an unoccupied state. The second result indicates that all cache lines are in an occupied state. In implementation, at least one cache line can be traversed sequentially according to a preset traversal method. The traversal method can include, but is not limited to, direction, starting point, and interval. The traversal direction can include, but is not limited to, from front to back, from back to front, etc. The starting point of the traversal can be the first, the last, or other specified point. The interval can be any suitable interval, such as 0, 1, or more. For example, it indicates sequential continuous traversal (i.e., an interval of 0). Another example is traversing at intervals of 1 each time.

[0126] For example, if the cache module includes 1000 cache lines, it can traverse continuously from the first cache line or skip one cache line from the last cache line. As another example, if the target cache line corresponding to the previous second sub-tile is the 100th cache line, then for the current second sub-tile, it can traverse continuously forward or backward from the 100th or 101st cache line.

[0127] When there is only one target cache line, during the traversal, if a cache line is in an unoccupied state, the first result is used as the traversal result and the traversal stops; otherwise, the second result is used as the traversal result and the traversal continues.

[0128] If the target number of cache lines is at least two, it is necessary to traverse at least two cache lines that are in an unoccupied state. If so, the first result is used as the traversal result and the traversal stops. If the number of cache lines in an unoccupied state is less than the target number of cache lines, a preset cache line can be used as the target cache line until the number of cache lines in an unoccupied state is the same as the target number of cache lines.

[0129] Step S332: Based on the traversal result of the second sub-plot, determine the target cache line corresponding to the second sub-plot.

[0130] Here, if a cache line is in an unoccupied state, it is used as a target cache line; if all cache lines are in an occupied state, a preset cache line is used as a target cache line. The preset cache line can include, but is not limited to, the oldest cache line, a specified cache line (e.g., the first, last, or other positions), etc. The oldest cache line refers to the cache line with the earliest allocation time, that is, the cache line that was used first.

[0131] In some embodiments, step S332 includes step S3321 and / or step S3322, wherein:

[0132] Step S3321: If the traversal result of the second sub-plot is the first result, the cache line of the current traversal is taken as the target cache line corresponding to the second sub-plot.

[0133] Here, if the currently traversed cache line is not occupied, it is used as a target cache line. For example, if the second sub-tile requires one target cache line and the traversal result of the 100th cache line is the first result, then the 100th cache line is used as the target cache line. As another example, if the second sub-tile requires two target cache lines and the traversal results of the 100th and 101st cache lines are both the first result, then both the 100th and 101st cache lines are used as a target cache line.

[0134] Step S3322: If the traversal result of the second sub-plot is the second result, the preset cache line is used as the target cache line corresponding to the second sub-plot.

[0135] Here, if all cache lines are occupied, a preset cache line is used as a target cache line. For example, the oldest cache line is used as the target cache line. In implementation, the data in the cache line is first cleared, and then the primitive information corresponding to the second sub-tile is stored in the target cache line.

[0136] Step S34: Using the target rendering core corresponding to the tile, render the second sub-tile based on the target cache line corresponding to the second sub-tile.

[0137] Here, the primitive information of the second sub-tile can be obtained from the target cache line first, and then the second sub-tile can be rendered using the target rendering core. For the specific rendering process, please refer to the specific implementation of step S13 above.

[0138] In this embodiment of the disclosure, by allocating a cache line for the second sub-tile and using the cache line to store the primitive information corresponding to the second sub-tile, on the one hand, the possibility of parallel limitations caused by insufficient resources is reduced; on the other hand, since the primitive information may contain primitives of different layers to be rendered, the data of multiple layers to be rendered can be processed continuously, reducing the possibility of hardware performance degradation caused by pipeline interruption.

[0139] In some embodiments, the method further includes step S35, wherein:

[0140] Step S35: In response to receiving the rendering completion signal of the target second sub-plot, clear the target cache line corresponding to the target second sub-plot and switch the state of the target cache line corresponding to the target second sub-plot to the unoccupied state.

[0141] Here, the target second sub-tile can be any second sub-tile. The rendering complete signal indicates that the second sub-tile has been rendered and there is no need to read the target cache line anymore; at this point, the target cache line can be released. In implementation, since the data of the second sub-tile is read sequentially in batches (e.g., 64 pixels) during the output merging stage, a rendering complete signal is generated based on the batch end marker after the last batch has been read.

[0142] In this embodiment, in response to receiving a rendering completion signal for the target second sub-tile, the target cache line corresponding to the target second sub-tile is cleared, and the state of the target cache line corresponding to the target second sub-tile is switched to an unoccupied state. This timely release of the cache line allows other valid sub-tiles to request cache lines, thereby improving rendering efficiency.

[0143] Based on the above embodiments, this disclosure provides a graphics processor. Figure 4A This is a schematic diagram of the composition structure of a graphics processor provided in an embodiment of the present disclosure, such as... Figure 4A As shown, the graphics processor 40 includes at least two rendering cores 41, and the graphics processor performs tile rendering based on a tile rendering (TBR) architecture, wherein:

[0144] The partitioning module in the backend module of the TBR architecture is used to divide a tile into at least one first sub-tile; wherein the tile is obtained by partitioning the image to be rendered, and the image to be rendered includes at least two layers to be rendered.

[0145] The processing module in the backend module of the TBR architecture is used to determine at least one second sub-block from the at least one first sub-block based on the first primitive list of the block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered;

[0146] The backend module of the TBR architecture is used to render the at least one second sub-tile using the target rendering core corresponding to the tile.

[0147] Here, the number of rendering cores of the graphics processor can be any suitable number, such as 4, 8, etc.

[0148] The TBR architecture includes a front-end module and a back-end module, which communicate with each other to achieve parallel processing of multiple layers to be rendered. In this embodiment, the front-end module includes at least... Figure 1B The front-end module 110 shown, the back-end module includes at least Figure 1B The backend module 120 is shown.

[0149] The backend module provided in the embodiments of this disclosure, in Figure 1B Based on the backend module 120 shown, a partitioning module has been added. This partitioning module can be any suitable software or hardware module capable of implementing this function. The partitioning process of the partitioning module 41 for dividing the blocks can be found in the specific implementation of step S11 above. In practice, since the size of each block is the same, the partitioning process for each block is also similar.

[0150] The backend module provided in the embodiments of this disclosure, in Figure 1B Based on the backend module 120 shown, a processing module has been added. This processing module can be any suitable software or hardware module capable of implementing this function. The process by which the processing module determines at least one second sub-block can be found in the specific implementation of step S12 above. In implementation, the second sub-block is a valid sub-block that needs to be rendered by the backend module.

[0151] It is understood that the partitioning module and processing module can be located within the rasterization module (i.e., the fragment stage), or they can be independent of the rasterization module. That is, the partitioning module and processing module are used to process the tiles before they are sent to the rasterization module. The process of the backend module rendering each second sub-tile can be found in the specific implementation of step S13 above.

[0152] In some implementations, the parameter reading module in the backend module of the TBR architecture is used to determine the first primitive list of the block from the second primitive list based on the block's description information.

[0153] Here, the second primitive list includes at least one primitive from at least two layers of the image to be rendered. The description information of the block describes the load information of the block, that is, which primitives in each layer to be rendered the block intersects with. In implementation, by parsing the description information of the block, the first primitive list of the block can be obtained from the second primitive list.

[0154] In some implementations, the second primitive list includes a primitive structure and a layer identifier structure; the front-end module of the TBR architecture is used to: sequentially place at least one primitive from the at least two layers to be rendered into the primitive structure, and sequentially place the layer identifier corresponding to the at least one primitive into the layer identifier structure according to the order of the at least one primitive in the primitive structure.

[0155] Here, the front-end module includes at least the aforementioned Figure 1B The front-end module 110 is shown. The process of placing the graphic elements and layer identifiers can be found in the specific implementation of steps S15 to S16 above.

[0156] Since the polygon list (corresponding to the aforementioned first primitive list) contains graphics from different layers, a rendering block needs to access different address regions when processing different primitives. When there are many layers, the span and space requirements of these different layer address regions also increase. If, according to the traditional TBR design, each rendering block is only bound to one on-chip depth buffer and released until the rendering is finished, the depth buffer can only be mapped to a fixed memory region, making it difficult to switch between address regions of different layers.

[0157] To address this challenge, a cache is integrated into each rasterization core to temporarily store depth / stencil / color data. This cache allocates cachelines at the tile level (corresponding to the aforementioned second sub-tile) (one or more cachelines store the data for one tile). During allocation, a hit-miss test is performed based on the unique virtual address corresponding to the tile region as a tag.

[0158] During the rasterization phase, each tile generated from the rendering chunks sends an allocation request to the cache. Upon receiving the allocation request, the cache selects an available cacheline and loads the corresponding data from memory. The cacheline is read / written during the depth / stencil test and output merge phases, and is released after all data in the entire cacheline has been used. If all cachelines are occupied and a new tile cannot be allocated to a cacheline, the oldest cacheline data is evicted and allocated to the new tile.

[0159] In some embodiments, the target rendering core includes a caching module; the processing module is further configured to: send the allocation request corresponding to the second sub-tile to the caching module; the caching module is configured to, based on the allocation request corresponding to the second sub-tile, determine the target cache line corresponding to the second sub-tile from at least one cache line, and send the identification information of the target cache line corresponding to the second sub-tile to the processing module; the processing module is further configured to: store the primitive information corresponding to the second sub-tile into the target cache line corresponding to the second sub-tile based on the identification information of the target cache line corresponding to the second sub-tile.

[0160] Here, each valid sub-tile needs to send an allocation request to the cache module so that the primitive information corresponding to the valid sub-tile can be moved from memory to the cache module. The identifier information of the cache line can be any suitable identifier, such as number, storage address, etc.

[0161] The number of target cache lines can be at least one. In implementation, the number of target cache lines is determined based on factors such as the size of the second sub-tile and the data (e.g., color, depth, etc.) format. In some implementations, the identification information of each target cache line can be managed using a queue. That is, when the identification information of the target cache line corresponding to a certain second sub-tile is obtained, the identification information is pushed into the queue. After the second sub-tile is rasterized, the identification information is retrieved from the queue and entered into subsequent processing (e.g., depth testing, output merging stage).

[0162] In some implementations, the backend module of the TBR architecture is further configured to obtain the primitive information corresponding to the second sub-plot from the target cache line corresponding to the second sub-plot, and render the second sub-plot based on the primitive information corresponding to the second sub-plot using the target rendering core corresponding to the plot.

[0163] Here, the rendering process of the second sub-block can be found in the specific implementation of step S34 above.

[0164] Because numerous primitives from different layers run in parallel within the pipeline, the hardware's address calculation capabilities need to be enhanced. When data for a second sub-tile needs to be read from memory, its memory address must be calculated based on the rendering layer to which it belongs. During the rendering process, since each rendering layer has the same size, the backend module can determine the starting address of the rendering layer to which the second sub-tile belongs in memory based on the base address of the RTA (Render Target Array), the size of each rendering layer, and the layer identifier of the rendering layer to which the second sub-tile belongs. Then, based on the information carried by the second sub-tile, the memory address of its rendering data (including color, depth, texture, etc.) is determined. Finally, the memory address of the second sub-tile itself is determined based on the information carried by the second sub-tile. The information carried by the second sub-tile may include, but is not limited to, the layer identifier of the rendering layer to which it belongs, the position information of the second sub-tile within the rendering layer, the pixel mask of the second sub-tile, and the identifier information of the target cache line corresponding to the second sub-tile. In implementation, the information carried by the second sub-tile can be implemented using structures, key-value pairs, tables, etc. For example, the information carried by the second sub-tile can be defined using the following structure, Tile_Info:

[0165] typedef struct Tile_Info

[0166] {

[0167] uint16_ttile_x;

[0168] uint16_ttile_y;

[0169] uint16_trta_idx;

[0170] uint64_t mask;

[0171] }

[0172] Among them, tile_x and tile_y are used to represent the position information of the second sub-tile in the layer to be rendered, rta_idx is used to represent the layer identifier of the layer to be rendered to which the second sub-tile belongs, and mask is used to represent the pixel mask of the second sub-tile.

[0173] The pixel mask for the second sub-tile can be determined based on whether each pixel intersects with a primitive. For example, if the second sub-tile includes 16 pixels, the pixel mask consists of 16 bits, with each bit representing the intersection result between the corresponding pixel and the primitive. In implementation, if the pixel intersects with the primitive, the mask value for that bit can be 1; otherwise, if the pixel does not intersect with the primitive, the mask value for that bit can be 0. Similarly, other values ​​can also be used to represent the intersection result between pixels and primitives.

[0174] In some implementations, the information of the second sub-block may or may not carry the identification information of the corresponding target cache line.

[0175] When the second sub-plot carries the identification information of the target cache line, after the second sub-plot is rasterized, the primitive information corresponding to the second sub-plot can be directly obtained from the cache module based on the identification information of the target cache line carried by the second sub-plot.

[0176] If the second sub-tile does not carry the identification information of the target cache line, since the identification information of the target cache line will be pushed into the queue after the target cache line is allocated, the identification information of the target cache line corresponding to the second sub-tile can be retrieved from the queue after the second sub-tile is rasterized. Based on the identification information of the target cache line carried by the second sub-tile, the primitive information corresponding to the second sub-tile can be obtained from the cache module.

[0177] Figure 4B This is a schematic diagram illustrating the storage location of multiple layers to be rendered in memory, as provided in an embodiment of this disclosure. Figure 4BAs shown, since each layer to be rendered has the same size, each layer to be rendered is stored sequentially according to its layer identifier. Specifically: the starting address of storage space 411 for the first layer to be rendered (i.e., layer 0) is the base address of the RTA; the starting address of storage space 412 for the second layer to be rendered (i.e., layer 1) is "base address + layer size * 1"; the starting address of storage space 413 for the third layer to be rendered (i.e., layer 2) is "base address + layer size * 2"; and the starting address of storage space 414 for the fourth layer to be rendered (i.e., layer 3) is "base address + layer size * 3".

[0178] During the output merging stage, based on the information carried by the second sub-block 415, the primitive information corresponding to the second sub-block 415 is obtained from the storage space 413 corresponding to layer 3; based on the information carried by the second sub-block 416, the primitive information corresponding to the second sub-block 416 is obtained from the storage space 411 corresponding to layer 0; based on the information carried by the second sub-block 417, the primitive information corresponding to the second sub-block 417 is obtained from the storage space 413 corresponding to layer 2.

[0179] In some embodiments, the processing module is further configured to: in response to receiving a rendering completion signal for the target second sub-plot, send a release request corresponding to the target second sub-plot to the cache module; the cache module is further configured to: based on the identification information in the release request, clear the target cache line corresponding to the identification information in the release request, and switch the state of the target cache line corresponding to the target second sub-plot to an unoccupied state.

[0180] Here, the target second sub-tile can be any second sub-tile. The rendering completion signal indicates that the second sub-tile has been rendered and there is no longer a need to read the target cache line. At this point, the target cache line can be released. The release request can include at least the identification information of the target cache line corresponding to the target second sub-tile. In implementation, if there are multiple target cache lines, the release request should include the identification information of multiple target cache lines.

[0181] In some implementations, the front-end module of the TBR architecture is used to: divide the image to be rendered according to a preset partitioning strategy to obtain at least one tile.

[0182] Here, the partitioning strategy may include, but is not limited to, partitioning method, partitioning length, and number of partitions. The partitioning process for the image to be rendered can be found in the specific implementation of step S11 above.

[0183] Figure 4C A schematic diagram of multi-layer rendering provided for an embodiment of this disclosure, such as... Figure 4C As shown, where:

[0184] The front-end module 421 of the TBR architecture outputs the graph data of each layer to the GPU memory 422;

[0185] After receiving a signal 424 indicating that all layers have been processed, the designated hardware 423 kicks all layers to be rendered (i.e., layers 0 to 9, layer 0 to layer 9) down to the back-end module 425 of the TBR architecture at once.

[0186] The backend module 425 of the TBR architecture divides the tiles into at least one first sub-tile; based on the tile description information, it determines the first primitive list of the tiles from the second primitive list; based on the first primitive list, it determines at least one second sub-tile from the at least one first sub-tile; it moves the primitive data corresponding to each second sub-tile from memory 422 to the corresponding cache line; upon receiving a rendering instruction, it retrieves data from the cache line corresponding to each second sub-tile and writes the data to the corresponding position of RT to complete the rendering of all layers to be rendered. In this way, all layers to be rendered are loaded at once, and the processing of all layers to be rendered can be completed with a single load. First, it merges multiple renders into a single render, reducing firmware preparation time from multiple steps to a single step, significantly reducing software processing time. Second, multi-layer data is processed in parallel within the fragment stage (i.e., the backend module) pipeline. The graphics data to be rendered for each layer is no longer divided by layer but enters the fragment stage as a whole for processing, avoiding performance degradation caused by pipeline interruptions. Finally, it simplifies the pipeline execution logic. For layer-by-layer rendering, the hardware needs to perform many identical operations on each layer (e.g., screen splitting, parameter reading, etc.). After compression into a single render, these operations only need to be performed once, improving hardware execution efficiency to some extent.

[0187] Figure 4D This is a schematic diagram of a TBR rendering pipeline provided in an embodiment of the present disclosure, such as... Figure 4D As shown, the rendering pipeline based on this embodiment is divided into a front-end module 421 (also known as the geometry stage) based on a TBR architecture and a back-end module 425 (also known as the 3D stage) based on a TBR architecture, wherein:

[0188] The front-end module 421 based on the TBR architecture includes a vertex processing module, a graphics processing module, and a modular module, wherein the vertex processing module, the graphics processing module, and the modular module are... Figure 1B The vertex processing module and graphics processing module are similar in this context. The block-segmentation module provided in this embodiment is similar to... Figure 1BSimilar to the block module, however, the block module provided in this embodiment is also used to perform the operations of steps S15 and S16 above.

[0189] For example, in the geometry phase, the block module no longer packs primitives into a dedicated polygon list for each layer based on their layer identifier (rta_idx). Instead, it packs them sequentially into a polygon list (i.e., the second primitive list) according to the output order of VS / GS. This means that the output polygon list may contain graphic data from multiple layers. In addition to the graphic data from multiple layers, the layer identifier (rta_idx) of each graphic should also be packed into this polygon list to indicate where the graphic will ultimately be written out.

[0190] The backend module 425 based on the TBR architecture includes a rasterization module, a hidden surface removal module, a pixel coloring module, and an output merging module. Among these, the hidden surface removal module, pixel coloring module, and output merging module are... Figure 1B The hidden surface removal module, pixel coloring module, and output merging module are similar in this embodiment. The rasterization module provided in this disclosure, in addition to performing... Figure 1B In addition to the operations performed by the rasterization module, the system also includes a parameter reading module, a partitioning module, and a processing module. The parameter acquisition module is used to determine the first primitive list of a block from the second primitive list based on the block's description information.

[0191] For example, since the screen rendering block (big tile, corresponding to the aforementioned tile) is relatively large, it is not suitable for direct caching and subsequent rasterization. Therefore, a first-level rendering block (big tile) splitting logic is added. The partitioning module splits the rendering block (big tile) into smaller tiles (corresponding to the aforementioned first sub-tile). The size of the split tile (how many pixels it contains) is configurable and should be adapted to the cache line size. This size can be 4*4, 2*8, 2*16, 2*4, 8*8, etc. The tile size is the product of the number of bits in the pixel, matches the cache line size, and is related to the depth format. For example, for a depth of fp32, that is, one pixel has 32 bits, then 8*8*32bit=2k. In this case, an 8*8 size can be used to facilitate the subsequent depth / color data compression logic. The splitting should be based on the bounding box of the graphic (the rectangle surrounding the triangle) to generate tiles.

[0192] The processing module uses the parameters of the graphic to determine whether the tile intersects with the graphic. If there is an intersection, it is sent to the next stage of processing; otherwise, it is discarded. Specifically, the processing module performs intersection checks on each element in the first element list of the tile with each first sub-tile to obtain valid sub-tiles (corresponding to at least one of the aforementioned second sub-tiles); and sends the allocation request for the valid sub-tiles to the caching module. Tiles that are deemed valid after splitting and intersection (corresponding to the aforementioned second sub-tiles) enter the cache allocation stage.

[0193] The caching module allocates cache lines for valid sub-tiles based on their allocation requests and returns the identifier information of the corresponding cache lines to the processing module. This stage allocates cache lines for a tile based on factors such as its size, depth, color, and format (i.e., one tile corresponds to one or more cache lines). The allocated cache line index is written to the FIFO and also cached and written back to the rasterization stage.

[0194] The processing module retrieves the primitive information corresponding to the valid sub-tile from memory and stores the primitive information into the corresponding cache line according to the identifier information of the cache line. Since numerous primitives from different layers are processed in parallel in the pipeline, the hardware's address calculation capabilities need to be improved. When a tile (corresponding to the aforementioned second sub-tile) requests a cache line, its virtual address needs to be calculated based on `rta_idx` (layer identifier). Taking pixel color reading and writing as an example, since each layer has a consistent format, each layer occupies the same amount of space, and the size of each layer can also be calculated. Given the base address of the 2DArray, the starting address of the layer to which the tile belongs can be calculated based on the `rta_idx` carried by the tile. Then, based on the pixel's coordinates, the address of the pixel within that layer (i.e., the pixel's offset within the layer) is calculated. Finally, the value of each pixel is written into memory.

[0195] After the tile completes rasterization, the cacheline index is retrieved from the cacheline index fifo (cacheline identifier queue), and then the depth test and output merging stages begin.

[0196] The processing flow of RTA provided in this embodiment of the disclosure is as follows:

[0197] Receive the render start signal and begin rendering the frame;

[0198] The screen is divided and distributed according to the size of the rendering tile (big tile, corresponding to the aforementioned tile), and the polygon list of the rendering tile is read (the primitives to be rendered are obtained from the polygon list according to the rendering tile descriptor).

[0199] When processing each primitive in the polygon list (corresponding to the aforementioned first primitive list), the rendering block further splits the rendering block by the size of a tile (corresponding to the aforementioned second sub-tile), and performs cacheline allocation on the split tiles;

[0200] Valid tiles are fed into the rasterization stage, where a depth / stencil test is performed, and the tiles are then distributed to the subsequent pixel shader stage for processing.

[0201] After receiving the tile, the OM (output merge) stage calculates the memory address based on the rta_idx it carries and writes out the color data.

[0202] In this embodiment, firstly, compared to performing initialization work once for each layer, initializing multiple layers to be rendered in a single initialization process not only shortens the initialization time but also reduces hardware resource consumption. Secondly, compared to the subsequent layer rendering having to wait for the previous layer to finish, processing multiple target layers to be rendered simultaneously ensures continuity between them in the hardware, thereby reducing GPU idle time and improving GPU utilization while reducing the possibility of hardware performance degradation due to pipeline interruptions. Thirdly, by allocating cache lines to store primitive information corresponding to the second sub-tile, the possibility of parallel limitations due to insufficient resources is reduced. Furthermore, since the primitive information may contain primitives from different layers to be rendered, continuous processing of data from multiple layers to be rendered is achieved, further reducing the possibility of hardware performance degradation due to pipeline interruptions. Finally, compared to performing the same tile partitioning and data reading operations on each layer separately, only the merged layers to be rendered need to undergo tile partitioning and data reading operations, reducing hardware resource consumption.

[0203] Based on the above embodiments, this disclosure provides a control device for tile rendering. Figure 5 This is a schematic diagram of the composition structure of a control device for tile rendering provided in an embodiment of the present disclosure, such as... Figure 5As shown, the control device 50 for tile rendering includes a first determining module 51, a second determining module 52, and a rendering module 53, wherein:

[0204] The first determining module 51 is used to divide the map into at least one first sub-map; wherein the map is obtained by dividing the screen to be rendered, and the screen to be rendered includes at least two layers to be rendered;

[0205] The second determining module 52 is configured to determine at least one second sub-block from the at least one first sub-block based on the first primitive list of the block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered;

[0206] The rendering module 53 is used to render the at least one second sub-tile using the target rendering core corresponding to the tile.

[0207] In some implementations, the second determining module 52 is further configured to: for each element in the first element list of the map block, determine at least one second sub-map block based on the position information of the element and each first sub-map block.

[0208] In some embodiments, the second determining module 52 is further configured to: for each first sub-block, if the position information of the element belongs to the range of the first sub-block, treat the first sub-block as a second sub-block.

[0209] In some implementations, the first determining module 51 is further configured to: determine the partition size based on the granularity of the cache lines of the cache module; wherein the cache module is located in the target rendering core; and partition the tile according to the partition size to obtain the at least one first sub-tile.

[0210] In some embodiments, the apparatus further includes a third determining module, which is configured to: determine a target cache line corresponding to the second sub-tile from at least one cache line in the cache module, and store the primitive information corresponding to the second sub-tile into the target cache line.

[0211] In some implementations, the third determining module is further configured to: sequentially traverse at least one cache line in the cache module, determine the traversal result of the second sub-plot based on the state of the currently traversed cache line, and stop traversing if the traversal result of the second sub-plot is a first result; wherein the first result indicates that the state of the currently traversed cache line is an unoccupied state; and determine the target cache line corresponding to the second sub-plot based on the traversal result of the second sub-plot.

[0212] In some embodiments, the third determining module is further configured to: when the traversal result of the second sub-plot is the first result, take the currently traversed cache line as the target cache line corresponding to the second sub-plot; and / or, when the traversal result of the second sub-plot is the second result, take a preset cache line as the target cache line corresponding to the second sub-plot; wherein the second result indicates that the state of each cache line in the cache module is an occupied state.

[0213] In some embodiments, the apparatus further includes a clearing module, which is configured to: in response to receiving a rendering completion signal for a target second sub-plot, clear the target cache line corresponding to the target second sub-plot and switch the state of the target cache line corresponding to the target second sub-plot to an unoccupied state.

[0214] In some embodiments, the apparatus further includes a fourth determining module, the fourth determining module being configured to: determine a first primitive list of the block from a second primitive list based on the block's description information; wherein the second primitive list includes at least one primitive from the at least two layers to be rendered of the image to be rendered.

[0215] In some embodiments, the second primitive list includes a primitive structure and a layer identifier structure; the device further includes an insertion module, which is configured to: sequentially insert at least one primitive from the at least two layers to be rendered into the primitive structure; and sequentially insert the layer identifiers corresponding to the at least one primitive into the layer identifier structure according to the order of the at least one primitive in the primitive structure.

[0216] The description of the above apparatus embodiments is similar to that of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the apparatus embodiments of this disclosure, please refer to the description of the method embodiments of this disclosure for understanding.

[0217] It should be noted that, in the embodiments of this disclosure, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this disclosure, or the parts that contribute to related technologies, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this disclosure are not limited to any specific hardware and software combination.

[0218] This disclosure provides an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the above-described method.

[0219] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method. The computer-readable storage medium can be transient or non-transient.

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

[0221] It should be noted that, Figure 6 This is a schematic diagram of the hardware entity of an electronic device provided in an embodiment of the present disclosure, such as... Figure 6 As shown, the hardware entity of the electronic device 600 includes: a processor 601, a communication interface 602, and a memory 603, wherein:

[0222] The processor 601 typically controls the overall operation of the electronic device 600.

[0223] Communication interface 602 enables electronic devices to communicate with other terminals or servers via a network.

[0224] The memory 603 is configured to store instructions and applications executable by the processor 601, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 601 and various modules in the electronic device 600. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 601, the communication interface 602, and the memory 603 can be performed via bus 604.

[0225] It should be noted that the descriptions of the storage medium and device embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

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

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

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

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

[0230] In addition, each functional unit in the embodiments of this disclosure can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0231] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

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

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

Claims

1. A method for controlling tile rendering, characterized in that, The control method includes: The tile is divided into at least one first sub-tile; wherein the tile is obtained by dividing the screen to be rendered, the screen to be rendered includes at least two layers to be rendered, and the initialization of the at least two layers to be rendered is completed in one initialization. Based on the first primitive list of the block, at least one second sub-block is determined from the at least one first sub-block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered; Render the at least one second sub-tile using the target rendering core corresponding to the tile; The step of determining at least one second sub-block from the at least one first sub-block based on the first primitive list of the blocks includes: for each first sub-block, if the position information of the primitives in the first primitive list is within the range of the first sub-block, then the first sub-block is regarded as a second sub-block.

2. The control method according to claim 1, characterized in that, The step of dividing a map tile into at least one first sub-map tile includes: The partition size is determined based on the granularity of the cache lines of the cache module; wherein, the cache module is located in the target rendering core; The map block is divided according to the specified division size to obtain at least one first sub-map block.

3. The control method according to claim 1, characterized in that, The control method further includes: The target cache line corresponding to the second sub-tile is determined from at least one cache line in the cache module, and the primitive information corresponding to the second sub-tile is stored in the target cache line.

4. The control method according to claim 3, characterized in that, Determining the target cache line corresponding to the second sub-tile from at least one cache line in the cache module includes: The system iterates through at least one cache line in the cache module, determines the traversal result of the second sub-plot based on the state of the currently traversed cache line, and stops traversing if the traversal result of the second sub-plot is the first result; wherein the first result indicates that the state of the currently traversed cache line is unoccupied. Based on the traversal results of the second sub-plot, the target cache line corresponding to the second sub-plot is determined.

5. The control method according to claim 4, characterized in that, Determining the target cache line corresponding to the second sub-map tile based on the traversal result of the second sub-map tile includes: If the traversal result of the second sub-plot is the first result, the cache line of the current traversal is taken as the target cache line corresponding to the second sub-plot; If the traversal result of the second sub-plot is the second result, the preset cache line is taken as the target cache line corresponding to the second sub-plot; wherein, the second result indicates that the state of each cache line in the cache module is occupied.

6. The control method according to claim 3, characterized in that, The control method further includes: In response to receiving the rendering completion signal of the target second sub-plot, the target cache line corresponding to the target second sub-plot is cleared, and the state of the target cache line corresponding to the target second sub-plot is switched to the unoccupied state.

7. The control method according to any one of claims 1 to 6, characterized in that, The control method further includes: Based on the description information of the tile, a first primitive list of the tile is determined from the second primitive list; wherein the second primitive list includes at least one primitive from the at least two layers to be rendered of the image to be rendered.

8. The control method according to claim 7, characterized in that, The second primitive list includes primitive structures and layer identifier structures; the control method further includes: At least one primitive from the at least two layers to be rendered is sequentially placed into the primitive structure; According to the order of the at least one graphic element in the graphic element structure, the layer identifiers corresponding to the at least one graphic element are sequentially placed into the layer identifier structure.

9. A graphics processor, characterized in that, The graphics processor includes at least two rendering cores, and the graphics processor performs tile rendering based on a tile rendering (TBR) architecture, wherein: The partitioning module in the backend module of the TBR architecture is used to divide a tile into at least one first sub-tile; wherein, the tile is obtained by partitioning the image to be rendered, and the image to be rendered includes at least two layers to be rendered, and the initialization of the at least two layers to be rendered is completed in one initialization. The processing module in the backend module of the TBR architecture is used to determine at least one second sub-block from the at least one first sub-block based on the first primitive list of the block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered; The backend module of the TBR architecture is used to render the at least one second sub-tile using the target rendering core corresponding to the tile; The processing module is further configured to, for each first sub-plot, if the position information of the elements in the first element list falls within the range of the first sub-plot, treat the first sub-plot as a second sub-plot.

10. The graphics processor according to claim 9, characterized in that, The parameter reading module in the backend module of the TBR architecture is used to determine the first primitive list of the block from the second primitive list based on the block description information; wherein the second primitive list includes at least one primitive from the at least two layers to be rendered of the image to be rendered.

11. The graphics processor according to claim 10, characterized in that, The second primitive list includes primitive structure and layer identifier structure; The front-end module of the TBR architecture is used to sequentially place at least one primitive from the at least two layers to be rendered into the primitive structure, and sequentially place the layer identifiers corresponding to the at least one primitive into the layer identifier structure according to the order of the at least one primitive in the primitive structure.

12. The graphics processor according to claim 9, characterized in that, The target rendering core includes a caching module; The processing module is further configured to: send the allocation request corresponding to the second sub-plot to the cache module; The caching module is used to determine the target cache line corresponding to the second sub-plot from at least one cache line based on the allocation request corresponding to the second sub-plot, and send the identification information of the target cache line corresponding to the second sub-plot to the processing module; The processing module is further configured to: store the primitive information corresponding to the second sub-plot into the target cache line corresponding to the second sub-plot based on the identifier information of the target cache line corresponding to the second sub-plot.

13. The graphics processor according to claim 12, characterized in that, The backend module of the TBR architecture is also used to obtain the primitive information corresponding to the second sub-plot from the target cache line corresponding to the second sub-plot, and to render the second sub-plot based on the primitive information corresponding to the second sub-plot using the target rendering core corresponding to the plot.

14. The graphics processor according to any one of claims 9 to 13, characterized in that, The front-end module of the TBR architecture is used to: divide the image to be rendered according to a preset partitioning strategy to obtain at least one tile.

15. A control device for tile rendering, characterized in that, The device includes: The first determining module is used to divide a tile into at least one first sub-tile; wherein the tile is obtained by dividing the screen to be rendered, the screen to be rendered includes at least two layers to be rendered, and the initialization of the at least two layers to be rendered is completed in one initialization. The second determining module is configured to determine at least one second sub-block from the at least one first sub-block based on the first primitive list of the block; wherein the first primitive list of the block includes at least one primitive from at least one layer to be rendered; The rendering module is used to render the at least one second sub-tile using the target rendering core corresponding to the tile; The second determining module is further configured to, for each first sub-block, if the position information of the elements in the first element list falls within the range of the first sub-block, designate the first sub-block as a second sub-block.

16. An electronic device comprising a processor and a memory, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 8.

17. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 8.

Images