Tile filling apparatus, method, graphics processor, electronic device

Abstract

The present disclosure relates to the field of graphic processors, and provides a tile filling device, a tile filling method, a graphic processor and an electronic device. The tile is used to store attribute information generated when a geometry processing pipeline implements a function of a shader. The device comprises a control module configured to determine a corresponding position of a vertex in a tile; wherein, in a case that the shader is a mesh shader and the attribute information comprises attribute information of a primitive, the corresponding position of the vertex is incremented by one each time the vertex serves as a trigger vertex of one primitive, and the newly added position is used to store the attribute information of the primitive; and a filling module configured to write the attribute information into the position corresponding to the vertex in the tile. In a case that the graphic processor implements the mesh shader, the device can reduce hardware storage cost and bandwidth occupation, reduce power consumption, and improve performance and throughput of the graphic processor.

Description

Technical Field

[0001] This disclosure relates to the field of graphics processors, and more particularly to a tile filling device, method, graphics processor, and electronic device. Background Technology

[0002] A graphics processor includes a geometry processing pipeline and a pixel processing pipeline. The geometry processing pipeline implements the functionality of the mesh shader (MS).

[0003] When implementing a mesh shader, the geometry processing pipeline generates primitive and vertex attribute information, which needs to be stored in structured primitive blocks. While existing block-filling mechanisms can store primitive and vertex attribute information in blocks, they consume significant hardware storage costs and bandwidth, increase power consumption, and reduce graphics processor performance and throughput. Summary of the Invention

[0004] In view of this, this disclosure proposes a tile-filling device, method, graphics processor, and electronic device. When the graphics processor implements a mesh shader, this device can reduce hardware storage costs and bandwidth usage, lower power consumption, and improve graphics processor performance and throughput.

[0005] According to one aspect of this disclosure, a tile filling device is provided. The tile is used to store attribute information generated when a geometry processing pipeline implements the function of a shader. The device includes: a control module, used to determine the position of a vertex in the tile; wherein, when the shader is a mesh shader and the attribute information includes attribute information of primitives, the position corresponding to the vertex is incremented by one each time the vertex is used as a trigger vertex of a primitive, and the newly added position is used to store the attribute information of the primitive; and a filling module, used to write the attribute information to the position corresponding to the vertex in the tile.

[0006] In one possible implementation, the control module is configured to: test whether the vertices of a graph element hit the block, on a graph element-by-graph basis; when the vertex does not hit the block, select an empty position in the block and determine it as the position corresponding to the vertex; when the vertex hits the block, the position corresponding to the vertex remains unchanged; when the vertex is the trigger vertex of the currently tested graph element, the determined position is used to store the attribute information of the currently tested graph element.

[0007] In one possible implementation, when the shader is a mesh shader and the attribute information includes primitive attribute information, the control module is configured to: force the vertex to miss the tile when the vertex is the trigger vertex of the currently tested primitive; when the vertex is not the trigger vertex of the currently tested primitive, determine whether a position corresponding to the vertex already exists in the tile; when there is a position corresponding to the vertex in the tile, the vertex misses the tile; when there is no position corresponding to the vertex in the tile, the vertex misses the tile.

[0008] In one possible implementation, when the shader is a mesh shader and the attribute information does not include primitive attribute information, the control module is configured to: determine whether a position corresponding to the vertex already exists in the tile; when a position corresponding to the vertex exists in the tile, the vertex hits the tile; when no position corresponding to the vertex exists in the tile, the vertex does not hit the tile.

[0009] In one possible implementation, the tile is further used to store an index group corresponding to the primitive, and the control module is further used to obtain the index group corresponding to the primitive based on the position of each vertex in the primitive, and cache the index group in the filling module; the filling module is further used to write the cached index group into the tile.

[0010] In one possible implementation, the control module is further configured to: instruct the pixel processing pipeline to extract the attribute information of the primitive from the tile in a flat interpolation mode.

[0011] In one possible implementation, the attribute information further includes vertex attribute information. When writing attribute information to the position corresponding to the vertex, the filling module is configured to: if the attribute information to be written includes both the vertex attribute information and the primitive attribute information, use the primitive attribute information as one item in the vertex attribute information; if the attribute information to be written only includes the vertex attribute information, use a target data segment as one item in the vertex attribute information, wherein the length of the target data segment is the same as the length of the primitive attribute information, and the position of the target data segment in the vertex attribute information is the same as the position of the primitive attribute information in the vertex attribute information.

[0012] In one possible implementation, the control module includes a primitive control unit and a vertex control unit, and the filling module includes an index group cache and a filling unit. The primitive control unit is used to instruct the vertex control unit to start a hit test; when the shader is a mesh shader and the attribute information includes primitive attribute information, it also instructs the vertex control unit to allow the vertex to be forced to miss the tile when the vertex is the trigger vertex of the currently tested primitive; the vertex control unit is used to test whether the vertices of a primitive hit the tile, on a primitive-by-primary basis, according to the instruction of the primitive control unit; when the vertex misses the tile, it selects an empty position in the tile and determines it as the position corresponding to the vertex; when the vertex hits the tile, the position corresponding to the vertex remains unchanged; based on the position corresponding to each vertex in each primitive, it obtains an index group corresponding to each primitive and caches the index group in the index group cache; the filling unit is used to write attribute information to the position corresponding to the vertex in the tile according to the index group included in the index group cache, and write the index group included in the index group cache into the tile.

[0013] According to another aspect of this disclosure, a tile filling method is provided, the method being applied to a tile filling device, wherein the tile is used to store attribute information generated when a geometry processing pipeline implements the function of a shader, the device including a control module and a filling module, and the method comprising: the control module determining the position of a vertex in the tile; wherein, when the shader is a mesh shader and the attribute information includes attribute information of primitives, for each vertex as a trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive; and the filling module writing the attribute information to the position corresponding to the vertex in the tile.

[0014] In one possible implementation, the control module determines the position of a vertex in a tile by: testing whether a vertex of a graphic element hits the tile, on a graphic element-by-graphic element basis; when a vertex does not hit the tile, selecting an empty position in the tile and determining it as the position corresponding to the vertex; when a vertex hits the tile, the position corresponding to the vertex remains unchanged; when the vertex is the trigger vertex of the currently tested graphic element, the determined position is used to store the attribute information of the currently tested graphic element.

[0015] In one possible implementation, when the shader is a mesh shader and the attribute information includes primitive attribute information, the test for whether a vertex of a primitive hits the tile includes: when the vertex is the trigger vertex of the currently tested primitive, forcibly setting the vertex to not hit the tile; when the vertex is not the trigger vertex of the currently tested primitive, determining whether a position corresponding to the vertex already exists in the tile; when there is a position corresponding to the vertex in the tile, the vertex hits the tile; when there is no position corresponding to the vertex in the tile, the vertex does not hit the tile.

[0016] In one possible implementation, when the shader is a mesh shader and the attribute information does not include primitive attribute information, the test for whether a vertex of a primitive hits the tile includes: determining whether a position corresponding to the vertex already exists in the tile; if a position corresponding to the vertex exists in the tile, the vertex hits the tile; if no position corresponding to the vertex exists in the tile, the vertex does not hit the tile.

[0017] In one possible implementation, the tile is also used to store an index group corresponding to the primitive, and the method further includes: the control module obtains the index group corresponding to the primitive based on the position of each vertex in the primitive, and caches the index group in the filling module; the filling module writes the cached index group into the tile.

[0018] In one possible implementation, the method further includes: the control module instructing a pixel processing pipeline to extract the attribute information of the primitive from the tile in a flat interpolation mode.

[0019] In one possible implementation, the attribute information further includes vertex attribute information. When writing attribute information to the position corresponding to the vertex, writing attribute information to the position corresponding to the vertex in the tile includes: if the attribute information to be written includes the attribute information of the vertex and the attribute information of the primitive, the attribute information of the primitive is used as one item in the attribute information of the vertex; if the attribute information to be written only includes the attribute information of the vertex, a target data segment is used as one item in the attribute information of the vertex, the length of the target data segment is the same as the length of the attribute information of the primitive, and the position of the target data segment in the attribute information of the vertex is the same as the position of the attribute information of the primitive in the attribute information of the vertex.

[0020] In one possible implementation, the control module includes a primitive control unit and a vertex control unit, and the filling module includes an index group cache and a filling unit. Determining the position of a vertex in the tile includes: the primitive control unit instructing the vertex control unit to start a hit test; and when the shader is a mesh shader and the attribute information includes primitive attribute information, the vertex control unit is further instructed to allow the vertex to be forced to miss the tile when the vertex is the trigger vertex of the primitive being tested. The vertex control unit, according to the instruction of the primitive control unit, tests whether the vertices of a primitive hit the block, on a primitive-by-primary basis; if a vertex does not hit the block, an empty position is selected in the block and determined as the position corresponding to the vertex; if a vertex hits the block, the position corresponding to the vertex remains unchanged; based on the positions corresponding to each vertex in each primitive, an index group corresponding to each primitive is obtained, and the index group is cached in the index group cache; writing attribute information to the position corresponding to the vertex in the block includes: the filling unit writes attribute information to the position corresponding to the vertex in the block according to the index group included in the index group cache, and writes the index group included in the index group cache into the block.

[0021] According to another aspect of this disclosure, a graphics processor is provided, including the tile filling device described above.

[0022] According to another aspect of this disclosure, an electronic device is provided, including the graphics processor described above.

[0023] In the tile filling device according to an embodiment of this disclosure, the control module is used to determine the position of a vertex in the tile; wherein, when the shader is a mesh shader and the attribute information includes the attribute information of primitives, each time a vertex is used as a trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive; the filling module is used to write the attribute information to the position corresponding to the vertex in the tile. This eliminates the need to treat the attribute information of primitives as inherent attributes of the tile, allowing the tile to store more information, reducing the number of tiles, and reducing the storage space and bandwidth occupied by the tiles. In summary, when the graphics processor implements a mesh shader and generates the attribute information of primitives that need to be stored, this device can reduce hardware storage costs and bandwidth usage, reduce power consumption, and thereby improve the performance and throughput of the graphics processor.

[0024] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0025] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0026] Figure 1 This diagram illustrates the data structure of a tile constructed using a traditional rendering pipeline.

[0027] Figure 2 This illustrates an exemplary application scenario of the tile filling device according to embodiments of the present disclosure.

[0028] Figure 3 A schematic diagram showing the structure of a geometric processing pipeline according to an embodiment of the present disclosure is provided.

[0029] Figure 4 A schematic diagram illustrating the correspondence between shader patterns and implemented shaders in a geometry processing pipeline according to an embodiment of the present disclosure.

[0030] Figure 5a A schematic diagram showing the structure of a tile filling device according to an embodiment of the present disclosure is provided.

[0031] Figure 5b A schematic diagram illustrating the operation of a tile filling apparatus according to an embodiment of the present disclosure is shown.

[0032] Figure 6 A schematic diagram showing vertices included in primitives according to an embodiment of the present disclosure is provided.

[0033] Figure 7 This diagram illustrates the process of determining whether a vertex hits a tile according to an embodiment of the present disclosure.

[0034] Figure 8 A schematic diagram showing the determination of the position corresponding to a vertex according to an embodiment of the present disclosure is provided.

[0035] Figure 9 This diagram illustrates the process of determining whether a vertex hits a tile according to an embodiment of the present disclosure.

[0036] Figure 10 This diagram illustrates the determination of the position corresponding to a vertex according to an embodiment of the present disclosure.

[0037] Figure 11 This diagram illustrates the process of determining the shader type and setting the vertex hit test method according to an embodiment of the present disclosure.

[0038] Figure 12 A schematic diagram of an index group for a tile storage according to an embodiment of the present disclosure is shown.

[0039] Figure 13 A schematic diagram of an index group for a tile storage according to an embodiment of the present disclosure is shown.

[0040] Figure 14 A schematic diagram illustrating the workflow of the filling module according to an embodiment of the present disclosure is shown.

[0041] Figure 15 A schematic diagram showing the structure of the control module and the filling module according to an embodiment of the present disclosure is provided. Detailed Implementation

[0042] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0043] As used herein, the terms “comprising,” “including,” “having,” or variations thereof are open-ended and include one or more of the stated features, integrals, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integrals, elements, steps, components, functions, or groups thereof.

[0044] When an element is referred to as “connected,” “coupled,” “responding,” or a variation thereof relative to another element, it may be directly connected, coupled, or responding to another element, or there may be an intermediate element present.

[0045] Although the terms first, second, third, etc., may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another. Therefore, without departing from the teachings of the inventive concept, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments.

[0046] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0047] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0048] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant regions.

[0049] The following is an explanation of the terms that may appear in this article.

[0050] Providing vertex: A providing vertex is a specific vertex in a primitive (such as a triangle or line segment) used to determine some attributes of the primitive (such as color, normal, face orientation, etc.). For example, when it is necessary to determine the color of a primitive, the color of the providing vertex of that primitive is used as the color of the primitive.

[0051] Flat Interpolation is an interpolation method used to uniformly distribute vertex attributes on primitives. It takes the attributes of a specific vertex (usually the trigger vertex) as the attributes of the primitive, a process similar to interpolation.

[0052] The following section will first introduce the traditional method of filling blocks using the rendering pipeline.

[0053] The traditional rendering pipeline introduced in DirectX 11.3 includes vertex shaders, tessellation shaders, and geometry shaders, collectively known as the VGT rendering pipeline. This traditional pipeline has the following drawbacks: vertex and geometry shaders are processed sequentially, limiting the efficiency of parallel computation and easily leading to performance bottlenecks; each shader has a fixed function, lacking flexibility when handling complex geometry and making it difficult to achieve advanced rendering effects; it also cannot simplify the processing of a large number of similar primitives, potentially leading to resource waste and inefficiency.

[0054] Figure 1 This diagram illustrates the data structure of a tile constructed using a traditional rendering pipeline.

[0055] like Figure 1 As shown, a block consists of control information, primitive index, vertex position information, and vertex attribute information.

[0056] Control information includes, but is not limited to, information about the backend pixel shader (such as the starting position of the pixel shader), the number of vertices and primitives corresponding to the current tile, the number of attribute information items of the vertices stored in the current tile (the attribute information of a vertex may include multiple items), and the interpolation mode of each attribute information of the vertex.

[0057] The primitive index includes an index group corresponding to each primitive. The index group corresponding to each primitive includes the indices of the vertices of that primitive. For example, if primitive ABC includes vertices A, B, and C, and the index of vertex A is 0, the index of vertex B is 1, and the index of vertex C is 2, then the index group corresponding to primitive ABC can be [0-1-2].

[0058] Vertex position information includes the position coordinates of each vertex. Coordinates in different dimensions can be represented using a uniform 32-bit floating-point format, or specific formats can be used for specific coordinates. For example, in one implementation, the X and Y coordinates of each vertex are represented using a 24-bit fixed-point format, with 16 integer bits and 8 fractional bits. The Z coordinate is represented using a 32-bit floating-point format.

[0059] Vertex attribute information includes vertex color value, vertex normal vector, vertex tangent vector, vertex texture map position, etc. If two primitives corresponding to the same tile share vertices, then the primitive only needs to store one copy of the vertex attribute information for that shared vertex.

[0060] Due to the aforementioned drawbacks of traditional rendering pipelines, DX12 introduced new rendering pipelines, including a geometry processing pipeline and a pixel processing pipeline. The geometry processing pipeline implements the mesh shader function, while the pixel processing pipeline implements the pixel shader function. In this process, the geometry processing pipeline generates primitive attribute information (such as primitive IDs) and vertex attribute information, which are then populated into tiles for storage. The subsequent pixel processing pipeline extracts the attribute information from the tiles and processes it using the pixel shader.

[0061] The existing solution involves adding a storage area within the tile to store the attribute information of primitives, with all primitives corresponding to each tile having identical attribute information. In other words, if adjacent primitives ABC and ACD have different attribute information, then the attribute information of primitive ACD cannot be stored in the tile corresponding to primitive ABC; it needs to be stored in a new tile. The increased number of tiles leads to increased storage resource and bandwidth consumption, and adding new tiles also incurs additional power consumption, increasing the burden on the pixel processing pipeline. Furthermore, two adjacent primitives are highly likely to share vertices. In traditional rendering pipelines, when filling tiles, if the same tile corresponds to primitives with shared vertices, then the attribute information of the shared vertices in that tile only needs to be stored once. However, in the existing geometry processing pipeline, when filling tiles, if two primitives with shared vertices correspond to two tiles, then each tile needs to store a separate copy of the shared vertex attribute information, leading to increased storage resource and bandwidth consumption, and the redundant storage of data also incurs additional power consumption. The increased storage resources and bandwidth consumed, along with the increased power consumption, reduce the overall performance and throughput of the graphics processor.

[0062] In view of this, this disclosure proposes a tile-filling device, method, graphics processor, and electronic device. When the graphics processor implements a mesh shader, this device can reduce hardware storage costs and bandwidth usage, lower power consumption, and improve graphics processor performance and throughput.

[0063] Furthermore, compared to existing technologies, this method can reduce the burden on pixel processing pipelines.

[0064] Figure 2 This illustrates an exemplary application scenario of the tile filling device according to embodiments of the present disclosure.

[0065] A graphics processing unit (GPU) includes a geometry processing pipeline and a pixel processing pipeline. For example... Figure 2 As shown, the tile filling device can be located in the geometry processing pipeline of the graphics processor. The tile filling device fills attribute information generated by the shader implemented in the geometry processing pipeline into tiles. The attribute information to be filled into the tiles depends on the type of shader implemented in the geometry processing pipeline; it may include only vertex attribute information, or it may include both vertex attribute information and primitive attribute information. The vertex attribute information includes both vertex attribute information and vertex position information as in the prior art. The geometry processing pipeline can write the filled tiles to a storage module. Subsequent pixel processing pipelines can read the tiles from the storage module and process the stored attribute information of the tiles using the shader implemented in the pixel processing pipeline.

[0066] Figure 3 A schematic diagram showing the structure of a geometric processing pipeline according to an embodiment of the present disclosure is provided.

[0067] like Figure 3 As shown, the geometry processing pipeline may include a first task generation unit, a first shader engine, a second task generation unit, a second shader engine, a shader task construction unit, a shader execution unit, an on-chip storage unit, a task control unit, a vertex buffer unit, a tile filling device, and a tile storage unit.

[0068] The first task generation unit receives draw commands and dispatch mesh commands from the user. The draw commands specify the drawing method, while the dispatch mesh commands configure the shader mode of the geometry processing pipeline. The first task generation unit can split the received commands into first tasks and send them downstream (i.e., the first shader engine). When the shaders implemented in the geometry processing pipeline change, the first task generation unit needs to generate corresponding control flags and send them downstream along with the first tasks.

[0069] The first shader engine is responsible for generating the second task executed by the shaders implemented by the geometry processing pipeline. The second shader engine is responsible for generating the third task executed by the shaders implemented by the geometry processing pipeline. Embodiments of this disclosure support user-defined shader modes for the geometry processing pipeline; different shader modes result in different shaders implemented by the geometry processing pipeline. Figure 4 A schematic diagram illustrating the correspondence between shader patterns and implemented shaders in a geometry processing pipeline according to an embodiment of the present disclosure.

[0070] like Figure 4 As shown, the shaders that can be implemented in the geometry processing pipeline include vertex shaders (VS), hull shaders (HS), domain shaders (DS), geometry shaders (GS), amplifier shaders (AS), and mesh shaders (MS).

[0071] The first shader engine can determine which type of shader(s) it generates as the second task based on the first task generated from the first task generation unit (which carries the user-defined shader pattern).

[0072] When the shader mode is VS ONLY, the geometry processing pipeline only implements the vertex shader. The second task executed by the vertex shader is generated using the first shader engine, and there is no need to use the second shader engine.

[0073] When the shader mode is MS ONLY, the geometry processing pipeline only implements the mesh shader, using the first shader engine to generate the second task executed by the mesh shader, without needing to use the second shader engine.

[0074] When the shader mode is VS+GS, the geometry processing pipeline implements vertex shaders and geometry shaders. The first shader engine generates the second task performed by the vertex shaders and geometry shaders, so there is no need to use a second shader engine.

[0075] The three shader modes, VS ONLY, MS ONLY, and VS+GS, only use the first shader engine, and therefore belong to the single shader engine mode.

[0076] When the shader mode is AS+MS, the geometry processing pipeline implements the amplification shader and the mesh shader, uses the first shader engine to generate the second task executed by the amplification shader, and uses the second shader engine to generate the third task executed by the mesh shader.

[0077] When the shader pattern is VS+HS+DS, the geometry processing pipeline implements vertex shaders, shell shaders, and domain shaders. The first shader engine generates the second task executed by the vertex shaders and shell shaders, and the second shader engine generates the third task executed by the domain shaders.

[0078] When the shader pattern is VS+HS+DS+GS, the geometry processing pipeline implements vertex shaders, shell shaders, domain shaders, and geometry shaders. The first shader engine generates the second task executed by the vertex shaders and shell shaders, and the second shader engine generates the third task executed by the domain shaders and geometry shaders.

[0079] AS+MS, VS+HS+DS, and VS+HS+DS+GS are three shader modes that use two shader engines simultaneously, belonging to the dual-shader engine mode. In the dual-shader engine mode, the first and second shader engines can work in parallel, improving task generation efficiency.

[0080] The shader task construction unit is used to receive the second task sent from the first shader engine, allocate resources such as on-chip storage units for the received second task, and send the second task to the shader execution unit. The information of the second task can be sent to the task control unit synchronously.

[0081] The shader execution unit is responsible for implementing the shader that executes the received second task. It uses on-chip memory and other resources to execute the second task sent by the shader task construction unit. The final execution result of the second task is output to the vertex buffer unit for storage. Specifically: when the shader mode is VS ONLY, the output of the vertex shader is the final execution result of the second task; when the shader mode is VS + GS, the output of the vertex shader serves as the input of the geometry shader, and the output of the geometry shader serves as the final execution result of the second task; when the shader mode is VS + HS + DS, the output of the vertex shader serves as the input of the shell shader, and the output of the shell shader serves as the final execution result of the second task; when the shader mode is VS + HS + DS + GS, the output of the vertex shader serves as the input of the shell shader, and the output of the shell shader serves as the final execution result of the second task; when the shader mode is MS ONLY, the output of the mesh shader is the final execution result of the second task; and when the shader mode is AS + MS, the output of the magnification shader serves as the final execution result of the second task.

[0082] The task control unit receives the second task sent from the shader task construction unit and monitors its execution progress. After the final execution result of the second task is stored in the vertex buffer unit, if the second shader engine is still needed, it notifies the second task generation unit to generate a fourth task. The second shader engine can then determine which type of shader(s) it will generate for the third task based on the fourth task. After the final execution result of the second task is stored in the vertex buffer unit, if the second shader engine is no longer needed, a fifth task can be sent to the tile filling device.

[0083] The shader task construction unit is used to receive the third task sent from the second shader engine, allocate resources such as on-chip storage units for the received third task, and send the third task to the shader execution unit. The information of the third task can be sent to the task control unit synchronously.

[0084] The shader execution unit is responsible for implementing the shader that executes the received third task. It uses on-chip memory and other resources to execute the third task sent by the shader task construction unit, and the final execution result of the third task is output to the vertex buffer unit for storage. Specifically, when the shader mode is VS + HS + DS, the output of the shell shader (the final execution result of the second task) serves as the input of the domain shader, and the output of the domain shader serves as the final execution result of the third task. When the shader mode is VS + HS + DS + GS, the output of the vertex shader serves as the input of the shell shader, the output of the shell shader (the final execution result of the second task) serves as the input of the domain shader, the output of the domain shader serves as the input of the geometry shader, and the output of the geometry shader serves as the final execution result of the third task. When the shader mode is AS + MS, the output of the magnification shader (the final execution result of the second task) serves as the input of the mesh shader, and the output of the mesh shader serves as the final execution result of the third task.

[0085] The task control unit receives the third task sent from the shader task construction unit, monitors the execution progress of the third task, and determines that rasterization can proceed and pixel processing can be enabled after the final execution result of the third task is stored in the vertex buffer unit. The fifth task can be sent to the tile fill device.

[0086] The tile filling device receives a fifth task, which triggers it to begin constructing and filling tiles, and indicates the storage location of attribute information in the vertex buffer unit. Based on the fifth task, the tile filling device retrieves attribute information from the vertex buffer unit, determines which storage locations within the tile should contain the attribute information, fills the attribute information into the determined storage locations, and writes the filled tile into the tile storage unit. The tile storage unit then stores the tile in the storage module.

[0087] exist Figure 3 In the example, the geometry processing pipeline belongs to a Tile Based Render (TBR) architecture graphics processor, therefore the geometry processing pipeline also includes a tile generation unit. The tile storage unit also outputs tiles to the tile generation unit.

[0088] The tile generation unit constructs a tile control flow based on the tiles and stores the tile control flow in the storage module. Subsequent pixel processing pipelines retrieve the tile control flow and tiles from the storage module and process the tile control flow and tiles using their own implemented pixel shaders.

[0089] Figure 5a A schematic diagram showing the structure of a tile filling device according to an embodiment of the present disclosure is provided. Figure 5b A schematic diagram illustrating the operation of a tile filling apparatus according to an embodiment of the present disclosure is shown.

[0090] In one possible implementation, the tiles are used to store attribute information generated when the geometry processing pipeline implements the functionality of the shader, and the apparatus includes:

[0091] The control module is used to determine the position of the vertex in the tile;

[0092] In the case where the shader is a mesh shader and the attribute information includes the attribute information of primitives, each time a vertex is used as a trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive.

[0093] The fill module is used to write attribute information to the positions corresponding to vertices in the tile.

[0094] For example, a tile can be structured data used to store attribute information. In addition to storing attribute information, tiles can also store control information (see example). Figure 1 The present disclosure does not limit the data structure of the blocks (as described in the relevant descriptions).

[0095] like Figure 5a As shown, the block filling device may include a control module 501 for performing actions such as... Figure 5b Step S51, as shown, determines the position of the vertex in the tile.

[0096] In this context, vertices belong to primitives. When the shader is a mesh shader, the attribute information may include both primitive and vertex attribute information, or it may only include vertex attribute information. Vertex attribute information includes vertex color value, vertex normal vector, vertex tangent vector, vertex texture map position, vertex position coordinates, etc. Primitive attribute information includes the primitive's color, normal, face orientation, etc. This embodiment of the disclosure does not limit the specific content of the primitive and vertex attribute information.

[0097] One of the vertices included in each primitive is used as the trigger vertex for that primitive. The trigger vertices of different primitives may be the same or different. Figure 6 A schematic diagram showing vertices included in primitives according to an embodiment of the present disclosure is provided.

[0098] For example, such as Figure 6 As shown, primitive ABC includes vertices A, B, and C, with vertex A serving as the trigger vertex for primitive ABC. Primitive ACD includes vertices A, C, and D, with vertex A serving as the trigger vertex for primitive ACD. Primitive DFE includes vertices D, F, and E, with vertex D serving as the trigger vertex for primitive DFE.

[0099] In one example, when the shader is a mesh shader and the attribute information includes primitive attribute information, each time a vertex is used as a trigger vertex for a primitive, the position corresponding to that vertex is incremented by one, and the newly added position is used to store the primitive's attribute information. That is, if a vertex is used as a trigger vertex for multiple primitives, then at least multiple positions corresponding to that vertex will be determined, each used to store the attribute information of multiple primitives.

[0100] For example, suppose primitive ABC is the first primitive, including vertices A, B, and C, where vertex A is the trigger vertex for primitive ABC. Suppose primitive ACD is the second primitive, including vertices A, C, and D, with vertex A as the trigger vertex for primitive ACD. Suppose primitive DFE is the third primitive, including vertices D, F, and E, with vertex D as the trigger vertex for primitive DFE.

[0101] This determines at least two positions corresponding to vertex A: one for storing attribute information of primitive ABC and one for storing attribute information of primitive ACD. It also determines at least one position corresponding to vertex D, used to store attribute information of primitive DFE.

[0102] This embodiment does not limit the specific method by which the control module determines the position of a vertex in a tile. As long as the shader is a mesh shader and the attribute information includes the attribute information of the primitive, each time a vertex is used as a trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive.

[0103] like Figure 5a As shown, the block filling device may further include a filling module 502 for performing tasks such as... Figure 5b Step S52, as shown, writes attribute information to the positions in the tile corresponding to vertices. Positions in the tile that do not correspond to vertices do not need to have attribute information written to them.

[0104] For example, if positions 0-7 in a block correspond to vertices, but positions 8-11 do not, attribute information is written to positions 0-7.

[0105] As mentioned above, some locations are used to store attribute information of primitives. Therefore, when writing attribute information to a block, the attribute information of each primitive can be written to the location used to store that primitive's attribute information. For example, if it is determined that location 0 corresponding to vertex A is used to store the attribute information of primitive ABC, location 3 corresponding to vertex A is used to store the attribute information of primitive ACD, and location 5 corresponding to vertex D is used to store the attribute information of primitive DFE, then the attribute information of primitive ABC can be stored in location 0, the attribute information of primitive ACD can be stored in location 3, and the attribute information of primitive DFE can be stored in location 5. This embodiment of the present disclosure does not limit the specific method by which the filling module writes attribute information to the locations corresponding to vertices, as long as the block ultimately stores the attribute information corresponding to each primitive.

[0106] according to Figure 6 For example, when the attribute information of primitive ABC and primitive ACD is different, according to the existing technical solution, the attribute information of primitive ABC and primitive ACD cannot be stored in the same block, resulting in an increase in the number of blocks and wasted storage space in the blocks. However, according to the block filling method of the present disclosure, the attribute information of primitive ABC and the attribute information of primitive ACD can be stored in different locations in the block, which can reduce the number of blocks and reduce the storage space and bandwidth occupied by the blocks.

[0107] In the tile filling device according to an embodiment of this disclosure, the control module is used to determine the position of a vertex in the tile; wherein, when the shader is a mesh shader and the attribute information includes the attribute information of primitives, each time a vertex is used as a trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive; the filling module is used to write the attribute information to the position corresponding to the vertex in the tile. This eliminates the need to treat the attribute information of primitives as inherent attributes of the tile, allowing the tile to store more information, reducing the number of tiles, and reducing the storage space and bandwidth occupied by the tiles. In summary, when the graphics processor implements a mesh shader and generates the attribute information of primitives that need to be stored, this device can reduce hardware storage costs and bandwidth usage, reduce power consumption, and thereby improve the performance and throughput of the graphics processor.

[0108] In one possible implementation, the control module is used for:

[0109] Test whether the vertices of a primitive hit a block, using primitives as the unit.

[0110] When a vertex does not match a block, select an empty position in the block and designate it as the position corresponding to the vertex.

[0111] When a vertex hits a tile, the position corresponding to the vertex remains unchanged;

[0112] When a vertex is used as the trigger vertex of the primitive being tested, the determined position is used to store the attribute information of the primitive being tested.

[0113] For example, the control module tests whether the vertices of a graphic element hit a block, on a per-graphic-element basis.

[0114] The testing module can test whether the vertices of multiple primitives hit the block in sequence. For example, it can first test whether the vertices of primitive ABC hit the block, then test whether the vertices of primitive ACD hit the block, and finally test whether the vertices of primitive DFE hit the block. The testing module can also test whether the vertices of multiple primitives hit the block in parallel. This embodiment of the disclosure does not limit the order of testing.

[0115] When any primitive is tested, multiple vertices of that primitive are tested to see if they are in a block. If a vertex is not in a block, an empty position in the block is selected and designated as the vertex's position. If a vertex is in a block, no new position is assigned to the vertex; that is, the position corresponding to the vertex remains unchanged.

[0116] For example, before testing whether the vertices of primitive ACD hit a tile, it is already determined that vertex A corresponds to position 0, vertex C corresponds to position 2, and there is no position corresponding to vertex D. When testing whether the vertices of primitive ACD hit a tile, if vertex A does not hit the tile, then an empty position (such as position 3) is selected in the tile and determined as the position corresponding to vertex A. At this time, vertex A corresponds to positions 0 and 3. If vertex C hits the tile, then the position corresponding to vertex C remains unchanged, and vertex C still corresponds to position 2. If vertex D does not hit the tile, then an empty position (such as position 4) is selected in the tile and determined as the position corresponding to vertex D. At this time, vertex D corresponds to position 4.

[0117] When a vertex is the trigger vertex for the currently tested primitive, the determined position is used to store the attribute information of the currently tested primitive. For example, assuming vertex A is the trigger vertex for vertex ACD, then position 3 is used to store the attribute information of primitive ACD.

[0118] In one possible implementation, when the shader is a mesh shader and the attribute information includes primitive attribute information, the control module is used to:

[0119] When a vertex is the trigger vertex of the current test primitive, force the vertex to miss the tile;

[0120] If a vertex is not the trigger vertex for the current test primitive, determine whether a position corresponding to the vertex already exists in the block; if a position corresponding to the vertex exists in the block, the vertex hits the block; if no position corresponding to the vertex exists in the block, the vertex does not hit the block.

[0121] For example, as mentioned above, the shader mode of the geometry pipeline indicates the shader implemented by the geometry pipeline. In the AS+MS and MS ONLY shader modes, the geometry pipeline implements a mesh shader, generating vertex attribute information. If subsequent pipelines need to use primitive attribute information, the geometry pipeline will also generate primitive attribute information; both vertex and primitive attribute information need to be stored in the tiles. If subsequent pipelines do not need primitive attribute information, the geometry pipeline may not generate primitive attribute information, only storing vertex attribute information in the tiles. In other shader modes, the shader implemented by the geometry pipeline does not include a mesh shader; the geometry pipeline generates vertex attribute information but not primitive attribute information. Only vertex attribute information needs to be stored in the tiles.

[0122] When the shader is a mesh shader and the attribute information includes primitive attribute information, the control module is used to force the vertex to miss the tile when the vertex is the trigger vertex of the primitive being tested.

[0123] In other words, when the shader is a mesh shader and the attribute information includes primitive attribute information, when testing whether a vertex of a primitive hits a block, for the triggering vertex, regardless of whether the position corresponding to the vertex has been determined beforehand, an empty position is selected as the position corresponding to the vertex to store the attribute information of the current primitive. To achieve this effect, when a vertex is the triggering vertex of the currently tested primitive, it can be forcibly set that the vertex does not hit the block.

[0124] For non-trigger vertices, if a corresponding position has already been determined for that vertex, a new position does not need to be determined for that vertex, thus saving storage space occupied by the tile. To achieve this effect, when a vertex is not the trigger vertex of the currently tested primitive, it is determined whether a position corresponding to the vertex already exists in the tile; if a position corresponding to the vertex exists in the tile, the vertex hits the tile; if no position corresponding to the vertex exists in the tile, the vertex does not hit the tile.

[0125] In this case, if a vertex is the trigger vertex for x primitives (x is a positive integer), then that vertex may eventually correspond to at least x positions. If a vertex is not the trigger vertex, or if a vertex is the trigger vertex but belongs to only one primitive, then that vertex corresponds to only one position.

[0126] For example, to test whether the vertices of primitive ABC hit a tile, where vertex A is the trigger vertex of primitive ABC. If the shader is a mesh shader and the attribute information includes the primitive's attribute information, then vertex A is forced to miss the tile. For vertices B and C, the vertex hit test is performed in the normal way (the vertex hits the tile if there is a corresponding position in the tile; the vertex misses the tile if there is no corresponding position in the tile).

[0127] Figure 7 This diagram illustrates the process of determining whether a vertex hits a tile according to an embodiment of the present disclosure.

[0128] like Figure 7 As shown, when the shader is a mesh shader and the attribute information includes the attribute information of the primitive, to test whether any vertex of a primitive hits a tile, step S71 is first executed to determine whether the vertex is the trigger vertex of the current primitive. If yes, then the vertex has not hit the tile. If not, step S72 is executed to determine whether a position corresponding to the vertex already exists in the tile. If there is no position corresponding to the vertex in the tile, then it is determined that the vertex has not hit the tile. If there is a position corresponding to the vertex in the tile, then it is determined that the vertex has hit the tile.

[0129] It should be understood that in this embodiment, the hit test for different vertices of any primitive uses the same determination scheme, i.e., the conventional method described above. However, when the shader is a mesh shader and the attribute information includes the primitive's attribute information, the triggering vertex of the primitive is forcibly set to a missed block before the hit test begins. Furthermore, the forced setting of the triggering vertex is invalidated after the test for that primitive ends.

[0130] It should be understood that it is also possible to choose to execute step S72 first, and then execute step S71 to correct the result of step S72. This embodiment of the present disclosure does not limit the execution order of steps S71 and S72.

[0131] Figure 8 A schematic diagram showing the determination of the position corresponding to a vertex according to an embodiment of the present disclosure is provided.

[0132] Assume the shader is a mesh shader and the attribute information includes primitive attributes and vertex attributes. The primitives to be tested include... Figure 6 The shown primitives are ABC, ACD, and DFE. The storage locations within the blocks include... Figure 8 Positions 0-11 are shown.

[0133] Primitive ABC is the first primitive tested, including vertices A, B, and C, where vertex A serves as the trigger vertex for primitive ABC. A hit test is performed on the vertices included in primitive ABC. Assuming all positions in the block are currently empty, vertex A, being the trigger vertex, is forcibly set to a miss. Vertices B and C satisfy the condition that "there is no position corresponding to a vertex in the block," therefore, vertices A, B, and C are all determined to have missed the block. Figure 8 As shown, position 0 can be selected to correspond to vertex A, position 1 to correspond to vertex B, and position 2 to correspond to vertex C. Position 0 is used to store the attribute information of primitive ABC.

[0134] Primitive ACD is the second primitive tested, including vertices A, C, and D, with vertex A serving as the trigger vertex for primitive ACD. A hit test is performed on the vertices included in primitive ACD. Vertex A, being the trigger vertex, is forcibly set to a miss. Vertex C satisfies the condition that "there is a position corresponding to the vertex in the block," and vertex D satisfies the condition that "there is no position corresponding to the vertex in the block." Therefore, vertices A and D are determined to be misses in the block, while vertex C is a hit. Figure 8 As shown, position 3 can be selected to correspond to vertex A, and position 4 can be selected to correspond to vertex D. In this case, vertex A corresponds to positions 0 and 3, vertex B corresponds to position 1, vertex C corresponds to position 2, and vertex D corresponds to position 4. Position 3 is used to store the attribute information of primitive ACD.

[0135] The primitive DFE is the third primitive tested, including vertices D, F, and E, where vertex D is the trigger vertex of primitive DFE. A hit test is performed on the vertices included in primitive DFE. Vertex D, being the trigger vertex, is forcibly set to a miss. Vertices F and E satisfy the condition that "there is no position corresponding to a vertex in the block," therefore, vertices D, F, and E are determined to be missing from the block. Figure 8 As shown, position 5 can be selected to correspond to vertex D, position 6 to correspond to vertex F, and position 7 to correspond to vertex E. Position 5 is used to store the attribute information of primitive DFE.

[0136] Combination Figure 6 and Figure 8 As can be seen, although primitives ABC and ACD share the same vertex C, under existing technical solutions, the attribute information of primitives ABC and ACD cannot be stored in the same tile when their attribute information is different. This prevents the previously shareable attribute information of vertex C from being shared. However, according to the tile filling method of this disclosure, position 0 can store the attribute information of primitive A, and position 3 can store the attribute information of primitive ACD. Primitives ABC and ACD can still share the attribute information of vertex C.

[0137] This approach improves the data reuse of tiles, further reducing the storage space and bandwidth occupied by tiles.

[0138] In one possible implementation, when the shader is a mesh shader and the attribute information does not include primitive attribute information, the control module is used to:

[0139] Determine whether a position corresponding to a vertex already exists in the tile;

[0140] A vertex is a match for a tile when there is a position corresponding to a vertex.

[0141] A vertex is not matched if there is no corresponding position in the tile.

[0142] For example, when the shader is a mesh shader and the attribute information does not include primitive attribute information, it means that the tile does not need to store primitive attribute information. In this case, each vertex can be assigned a location. That is, as long as there is a storage location for a vertex in the tile, there is no need to assign a new location to the same vertex. In other words, it checks whether a location corresponding to a vertex already exists in the tile; if there is a location corresponding to a vertex in the tile, the vertex is a match for the tile; if there is no location corresponding to a vertex in the tile, the vertex is not a match for the tile.

[0143] Figure 9 This diagram illustrates the process of determining whether a vertex hits a tile according to an embodiment of the present disclosure.

[0144] like Figure 9 As shown, when the shader is a mesh shader and the attribute information does not include primitive attribute information, to test whether a vertex of a primitive hits a block, step S91 can be executed to directly determine whether a position corresponding to the vertex already exists in the block. If there is no position corresponding to the vertex in the block, it is determined that the vertex has not hit the block. If there is a position corresponding to the vertex in the block, it is determined that the vertex has hit the block.

[0145] Figure 10 This diagram illustrates the determination of the position corresponding to a vertex according to an embodiment of the present disclosure.

[0146] Assume the shader is a mesh shader and the attribute information only includes vertex attributes. The primitives to be tested include... Figure 6 The shown primitives ABC, ACD, and DFE have attribute information that can be stored in [the relevant storage location]. Figure 10 Positions 0-11 are shown.

[0147] Primitive ABC is the first primitive tested, including vertices A, B, and C, with vertex A serving as the trigger vertex for primitive ABC. A hit test is performed on the vertices included in primitive ABC. Assuming all positions in the primitive are currently empty, vertices A, B, and C all satisfy the condition that "there is no position corresponding to a vertex in the primitive," therefore, vertices A, B, and C are determined to have missed the target position in the primitive. Figure 10 As shown, position 0 corresponds to vertex A, position 1 corresponds to vertex B, and position 2 corresponds to vertex C.

[0148] Primitive ACD is the second primitive tested, including vertices A, C, and D. Vertex A is used as the trigger vertex for primitive ACD. A hit test is performed on the vertices included in primitive ACD. Vertices A and C satisfy the condition that "there is a position corresponding to the vertex in the block," while vertex D satisfies the condition that "there is no position corresponding to the vertex in the block." Therefore, vertex D is determined to be a non-hit vertex, while vertices A and C are hit vertexes. Figure 10 As shown, position 3 can be selected to correspond to vertex D. At this time, vertex A corresponds to position 0, vertex B corresponds to position 1, vertex C corresponds to position 2, and vertex D corresponds to position 3.

[0149] The primitive DFE is the third primitive tested, including vertices D, F, and E, with vertex D serving as the trigger vertex. A hit test is performed on the vertices included in primitive DFE. Vertex D satisfies the condition that "there is a position corresponding to the vertex in the block," while vertices F and E satisfy the condition that "there is no position corresponding to the vertex in the block." Therefore, vertices F and E are determined to be missing from the block, while vertex D is a hit. Figure 10 As shown, position 4 can be selected to correspond to vertex F, and position 5 can be selected to correspond to vertex E. At this time, vertex A corresponds to position 0, vertex B corresponds to position 1, vertex C corresponds to position 2, vertex D corresponds to position 3, vertex F corresponds to position 4, and vertex E corresponds to position 5.

[0150] In this way, when implementing a mesh shader in a geometry processing pipeline, different types of attribute information can be selected to fill the tiles according to the application scenario requirements, improving the flexibility of tile filling methods and saving tile storage resources.

[0151] It should be understood that when the geometry processing pipeline implements other shaders, it also generates vertex attribute information. This can be achieved using... Figure 10 As shown, the position of the vertex is determined and the attribute information is stored in the tile.

[0152] The tile filling device of this embodiment does not change the data structure of the tile, but only slightly adjusts the method of determining the position of the vertex and the content of the attribute information stored in some positions. Therefore, the power consumption and implementation complexity are low, and the burden on the downstream pipeline is also smaller.

[0153] Figure 11 This diagram illustrates the process of determining the shader type and setting the vertex hit test method according to an embodiment of the present disclosure.

[0154] like Figure 11 As shown, in one example, the control module executes steps S81-S85 to determine the shader type and set the vertex hit test method.

[0155] Step S81: Determine whether the shader is a mesh shader. For example, if the shader mode is AS+MS or MS ONLY, the shader is a mesh shader. Otherwise, the shader is not a mesh shader.

[0156] Step S82: If the shader is not a mesh shader, perform a hit test on the vertices in the normal manner.

[0157] Step S83: If the shader is a mesh shader, determine whether the attribute information includes the attribute information of the primitives.

[0158] Step S84: If the attribute information includes the attribute information of the primitive, force the trigger vertex to miss the block and perform a hit test on the non-trigger vertex in a normal manner.

[0159] Step S85: If the attribute information does not include the attribute information of primitives, perform a hit test on the vertices in a conventional manner.

[0160] Those skilled in the art should understand that it is also possible to first determine whether the attribute information includes the attribute information of the primitive, and then determine whether the shader is a mesh shader. The embodiments of this disclosure do not limit the order of determining the shader type and the content of the attribute information.

[0161] In one possible implementation, the block is also used to store the index group corresponding to the primitive. The control module is also used to obtain the index group corresponding to the primitive based on the position of each vertex in the primitive, and cache the index group in the filling module. The filling module is also used to write the cached index group into the block.

[0162] Figure 12 and Figure 13 A schematic diagram of an index group for a tile storage according to an embodiment of the present disclosure is shown.

[0163] like Figure 12As shown, when the shader is a mesh shader and the attribute information includes the attribute information of primitives, after the control module determines that position 0 corresponds to vertex A, position 1 corresponds to vertex B, and position 2 corresponds to vertex C, it can cache [0-1-2] as an index group corresponding to primitives ABC in the fill module, and the fill module writes the index group into the tile. Here, the index of the triggering vertex position can be located at a specific position in the index group, for example... Figure 12 In the example, the index of the trigger vertex position is written to the first position in the index group. Similarly, [3-2-4] can be cached in the fill module as the index group corresponding to primitive ACD, and [5-6-7] can be cached in the fill module as the index group corresponding to primitive DFE, and the fill module will write the index group into the tile.

[0164] like Figure 13 As shown, when the shader is a mesh shader and the attribute information does not include primitive attribute information, after the control module determines that position 0 corresponds to vertex A, position 1 corresponds to vertex B, and position 2 corresponds to vertex C, it can cache [0-1-2] as an index group corresponding to primitives ABC in the fill module, and the fill module will write the index group into the tile. The index of the trigger vertex can be located at any position in the index group. Similarly, [0-2-3] can be cached as an index group corresponding to primitives ACD in the fill module, and [3-4-5] can be cached as an index group corresponding to primitive DFE in the fill module, and the fill module will write the index group into the tile.

[0165] In this case, when the pixel processing pipeline extracts attribute information from the tile, it can determine the position of the attribute information included in the target primitive in the tile based on the index group corresponding to the target primitive, thereby extracting the required attribute information from the tile.

[0166] In one possible implementation, the control module is also used to instruct the pixel processing pipeline to extract primitive attribute information from the tile in a flat interpolation mode.

[0167] For example, when extracting attribute information of primitives, the attribute information of the primitives can be copied to the pixel processing pipeline. To achieve this, the control module is also used to instruct the pixel processing pipeline to extract the attribute information of primitives from the tile in a flat interpolation mode. In flat interpolation mode, the pixel processing pipeline only extracts the attribute information of primitives from the locations in the tile used to store the attribute information of primitives.

[0168] In this way, the attribute information of graphic elements can be accurately extracted from the graphic blocks.

[0169] In one possible implementation, the attribute information also includes vertex attribute information. When writing attribute information to the position corresponding to the vertex, the filling module is used to:

[0170] If the attribute information to be written includes vertex attribute information and primitive attribute information, the primitive attribute information is treated as one of the vertex attribute information.

[0171] If the attribute information to be written only includes the attribute information of vertices, the target data segment is treated as one of the attribute information of the vertex. The length of the target data segment is the same as the length of the attribute information of the primitive. The position of the target data segment in the attribute information of the vertex is the same as the position of the attribute information of the primitive in the attribute information of the vertex.

[0172] For example, after the hit test, the positions in the tiles can be divided into three categories: positions where no attribute information needs to be written, positions where vertex attribute information needs to be written, and positions where primitive attribute information and vertex attribute information need to be written. For example, as... Figure 7 As shown, positions 8-11 are positions where attribute information does not need to be written, positions 0, 3, and 5 are positions where attribute information for primitives and vertices needs to be written, and positions 1, 2, 4, 6, and 7 are positions where attribute information for vertices needs to be written.

[0173] If the attribute information to be written includes both vertex attribute information and primitive attribute information, the primitive attribute information can be included as one of the vertex attribute information. In practical applications, the primitive attribute information can be placed at the beginning, the end, or in any other determinable order of the existing vertex attribute information.

[0174] If some locations only have vertex attribute information written, while others have both vertex and primitive attribute information written, the bit width will be inconsistent across locations where data is written. This can easily lead to errors in the pixel processing pipeline when extracting attribute information from tiles. Therefore, if the attribute information to be written only includes vertex attribute information, the fill module can add an additional target data segment when writing attribute information to that location. The length of the target data segment is the same as the length of the primitive attribute information, ensuring that all locations where data is written have the same bit width. The position of the target data segment in the vertex attribute information can be the same as the position of the primitive attribute information in the vertex attribute information. This method facilitates the removal of target data segments.

[0175] Figure 14 A schematic diagram illustrating the workflow of the filling module according to an embodiment of the present disclosure is shown.

[0176] like Figure 14As shown, if a mesh shader is implemented and the attribute information includes primitive attribute information, the fill module executes step S141 to first determine whether the vertex is a trigger vertex. If the vertex is a trigger vertex, then step S142 is executed, where the attribute information to be written at the position corresponding to the vertex includes both vertex attribute information and primitive attribute information; in this case, the primitive attribute information is used as one of the vertex attribute information items. Step S143 is executed, where the attribute information to be written at the position corresponding to the vertex includes vertex attribute information; in this embodiment, the target data segment can be used as one of the vertex attribute information items. This embodiment does not restrict the execution order of steps S142 and S143. If the vertex is not a trigger vertex, step S144 is executed, where the target data segment is used as one of the attribute information items when writing attribute information to the position corresponding to the vertex.

[0177] The target data segment can include any data, as long as its length and position meet the above conditions. For example, the data bits of the target data segment can all be 1 or 0, or the attribute information of the corresponding primitive, or other preset values. Furthermore, in flat interpolation mode, the pixel processing pipeline only extracts the primitive's attribute information from the location used to store it; therefore, adding a target data segment has no impact on the extraction of the primitive's attribute information. In this way, the probability of errors in the graphics processor can be reduced, thus improving the graphics processor's performance.

[0178] Figure 15 A schematic diagram showing the structure of the control module and the filling module according to an embodiment of the present disclosure is provided.

[0179] like Figure 15 As shown, in one possible implementation, the control module 501 includes a primitive control unit 510 and a vertex control unit 511, and the filling module 502 includes an index group cache 520 and a filling unit 521.

[0180] The primitive control unit 510 is used to instruct the vertex control unit 511 to start a hit test; when the shader is a mesh shader and the attribute information includes the attribute information of primitives, it also instructs the vertex control unit 511 to allow the forced setting of a vertex missing a block when the vertex is the trigger vertex of the primitive being tested.

[0181] Vertex control unit 511 is used to test whether the vertices of a primitive hit a block, on a primitive basis, according to the instructions of primitive control unit 510; if the vertex does not hit a block, an empty position in the block is selected and determined as the position corresponding to the vertex; if the vertex hits a block, the position corresponding to the vertex remains unchanged; based on the position corresponding to each vertex in each primitive, an index group corresponding to each primitive is obtained, and the index group is cached in index group cache 520.

[0182] The filling unit 521 is used to write attribute information to the position corresponding to the vertex in the tile according to the index group included in the index group cache 520, and to write the index group included in the index group cache 520 into the tile.

[0183] The primitive control unit can receive a fifth task from the task control unit. This fifth task may include the shader mode, the content of the attribute information, and the position of the attribute information generated by the shader in the vertex buffer unit. The primitive control unit instructs the vertex control unit to start a hit test. When the shader mode and the content of the attribute information meet the conditions (the shader is a mesh shader and the attribute information includes the attribute information of the primitives), the primitive control unit also instructs the vertex control unit to allow the forced setting of triggering vertex miss blocks. The primitive control unit can also determine the attribute information of each primitive and the position of the attribute information in the vertex buffer unit based on the content of the attribute information and the position of the attribute information in the vertex buffer unit, and send the determined storage location to the vertex control unit in the order of the primitives.

[0184] The vertex control unit, according to the instructions of the primitive control unit, tests whether the vertices of a primitive hit a tile, on a primitive-by-primary basis, and determines the position of the vertex based on the vertex's hit status. Exemplary testing and position determination methods can be found in [reference needed]. Figures 7-11 The relevant description is provided. The vertex control unit is also used to obtain an index group corresponding to each primitive based on the position of each vertex in each primitive, and cache the index group in the index group cache. An exemplary implementation can be found in [reference needed]. Figure 12 and Figure 13 Related descriptions.

[0185] The index group cache stores the index group corresponding to each primitive. Once a tile is constructed (e.g., there are no more free spaces in the tile), the index group cache can send a refresh command to the fill cell.

[0186] The filling unit, upon receiving a refresh command from the index group cache, retrieves attribute information from the vertex buffer unit based on the storage location (from the vertex control unit) of each primitive's attribute information and the attribute information of its included vertices in the vertex buffer unit. It then writes the attribute information of that vertex (the primitive's attribute information can be used as one item of the vertex's attribute information) to the corresponding position of the vertex according to the index group included in the index group cache, and writes the index group included in the index group cache into the tile. An exemplary implementation can be found in [reference needed]. Figure 12 and Figure 13 Related descriptions.

[0187] Those skilled in the art will understand that the structures of the control module and the filling module are not limited to the examples described above. As long as the control module and the filling module can achieve the above functions, the specific structures of the control module and the filling module are not limited in the embodiments of this disclosure.

[0188] This disclosure also proposes a block filling method, the flowchart of which can be found in [reference needed]. Figure 5b .

[0189] like Figure 5b As shown, in one possible implementation, the method is applied to a tile filling device, the tiles being used to store attribute information generated when the geometry processing pipeline implements the function of the shader. The device includes a control module and a filling module, and the method includes:

[0190] Step S51: The control module determines the position of the vertex in the tile; wherein, when the shader is a mesh shader and the attribute information includes the attribute information of the primitive, each time a vertex is used as a trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive.

[0191] Step S52: The fill module writes attribute information to the positions corresponding to the vertices in the block.

[0192] In one possible implementation, the control module determines the position of a vertex in a tile by: testing whether a vertex of a graphic element hits the tile, on a graphic element-by-graphic element basis; when a vertex does not hit the tile, selecting an empty position in the tile and determining it as the position corresponding to the vertex; when a vertex hits the tile, the position corresponding to the vertex remains unchanged; when the vertex is the trigger vertex of the currently tested graphic element, the determined position is used to store the attribute information of the currently tested graphic element.

[0193] In one possible implementation, when the shader is a mesh shader and the attribute information includes primitive attribute information, the test for whether a vertex of a primitive hits the tile includes: when the vertex is the trigger vertex of the currently tested primitive, forcibly setting the vertex to not hit the tile; when the vertex is not the trigger vertex of the currently tested primitive, determining whether a position corresponding to the vertex already exists in the tile; when there is a position corresponding to the vertex in the tile, the vertex hits the tile; when there is no position corresponding to the vertex in the tile, the vertex does not hit the tile.

[0194] In one possible implementation, when the shader is a mesh shader and the attribute information does not include primitive attribute information, the test for whether a vertex of a primitive hits the tile includes: determining whether a position corresponding to the vertex already exists in the tile; if a position corresponding to the vertex exists in the tile, the vertex hits the tile; if no position corresponding to the vertex exists in the tile, the vertex does not hit the tile.

[0195] In one possible implementation, the tile is also used to store an index group corresponding to the primitive, and the method further includes: the control module obtains the index group corresponding to the primitive based on the position of each vertex in the primitive, and caches the index group in the filling module; the filling module writes the cached index group into the tile.

[0196] In one possible implementation, the method further includes: the control module instructing a pixel processing pipeline to extract the attribute information of the primitive from the tile in a flat interpolation mode.

[0197] In one possible implementation, the attribute information further includes vertex attribute information. When writing attribute information to the position corresponding to the vertex, writing attribute information to the position corresponding to the vertex in the tile includes: if the attribute information to be written includes the attribute information of the vertex and the attribute information of the primitive, the attribute information of the primitive is used as one item in the attribute information of the vertex; if the attribute information to be written only includes the attribute information of the vertex, a target data segment is used as one item in the attribute information of the vertex, the length of the target data segment is the same as the length of the attribute information of the primitive, and the position of the target data segment in the attribute information of the vertex is the same as the position of the attribute information of the primitive in the attribute information of the vertex.

[0198] In one possible implementation, the control module includes a primitive control unit and a vertex control unit, and the filling module includes an index group cache and a filling unit. Determining the position of a vertex in the tile includes: the primitive control unit instructing the vertex control unit to start a hit test; and when the shader is a mesh shader and the attribute information includes primitive attribute information, the vertex control unit is further instructed to allow the vertex to be forced to miss the tile when the vertex is the trigger vertex of the primitive being tested. The vertex control unit, according to the instruction of the primitive control unit, tests whether the vertices of a primitive hit the block, on a primitive-by-primary basis; if a vertex does not hit the block, an empty position is selected in the block and determined as the position corresponding to the vertex; if a vertex hits the block, the position corresponding to the vertex remains unchanged; based on the positions corresponding to each vertex in each primitive, an index group corresponding to each primitive is obtained, and the index group is cached in the index group cache; writing attribute information to the position corresponding to the vertex in the block includes: the filling unit writes attribute information to the position corresponding to the vertex in the block according to the index group included in the index group cache, and writes the index group included in the index group cache into the block.

[0199] This disclosure proposes a tile filling method and its corresponding tile filling device. The tile filling method allows the storage of primitive attribute information output by the mesh shader within the tile without significant modifications to the existing tile design, exhibiting good compatibility and ease of implementation. Compared to existing methods that switch tile storage when primitive attributes change, this disclosure can store vertex attribute information of primitives with different attributes within the same tile. This fully utilizes the vertex reuse relationships between primitives, effectively reducing tile generation and storage costs, lowering system power consumption, and improving overall system performance.

[0200] This disclosure also proposes a graphics processor, including the tile filling device described above. Examples of the graphics processor's structure can be found in [reference needed]. Figure 2 Related descriptions.

[0201] This disclosure also proposes an electronic device including the graphics processor described above. The electronic device may be a terminal device or a server; this disclosure does not limit the specific type of electronic device.

[0202] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0203] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A tile filling device, characterized in that, The tile is used to store attribute information generated when the geometry processing pipeline implements the function of the shader. The device includes: The control module is used to determine the position of the vertex in the tile; The control module tests whether the vertices of a primitive hit the block, taking primitives as units. When any primitive is tested, multiple vertices of that primitive are tested to see if they hit the block. If a vertex misses the block, an empty position is selected in the block and designated as the position corresponding to the vertex. When the shader is a mesh shader and the attribute information includes the attribute information of primitives, when a vertex is the trigger vertex of the currently tested primitive, the vertex is forced to miss the block. This causes the position corresponding to the vertex to increment by one each time the vertex becomes the trigger vertex of a primitive, and the newly added position is used to store the attribute information of the primitive. The fill module is used to write attribute information to the position in the block corresponding to the vertex.

2. The apparatus according to claim 1, characterized in that, The control module is used for: When a vertex hits a tile, the position corresponding to the vertex remains unchanged; When the vertex is used as the trigger vertex of the current test primitive, the determined position is used to store the attribute information of the current test primitive.

3. The apparatus according to claim 2, characterized in that, When the shader is a mesh shader and the attribute information includes primitive attribute information, the control module is used to: When the vertex is not used as the trigger vertex of the current test primitive, it is determined whether there is already a position corresponding to the vertex in the block; if there is a position corresponding to the vertex in the block, the vertex hits the block; if there is no position corresponding to the vertex in the block, the vertex does not hit the block.

4. The apparatus according to claim 2, characterized in that, When the shader is a mesh shader and the attribute information does not include primitive attribute information, the control module is used to: Determine whether a position corresponding to the vertex already exists in the tile; When there is a position in the block that corresponds to the vertex, the vertex hits the block; When there is no position corresponding to the vertex in the tile, the vertex is not matched with the tile.

5. The apparatus according to any one of claims 1-4, characterized in that, The block is also used to store the index group corresponding to the graphic element. The control module is further configured to obtain an index group corresponding to the graphic element based on the position of each vertex in the graphic element, and cache the index group in the filling module; The filling module is also used to write the cached index group into the tile.

6. The apparatus according to any one of claims 1-4, characterized in that, The control module is also used for: The instruction pixel processing pipeline extracts the attribute information of the primitives from the tile using a flat interpolation mode.

7. The apparatus according to claim 1, characterized in that, The attribute information also includes vertex attribute information. When writing attribute information to the position corresponding to the vertex, the filling module is used to: If the attribute information to be written includes the attribute information of the vertex and the attribute information of the primitive, the attribute information of the primitive shall be used as one of the attribute information of the vertex. If the attribute information to be written only includes the attribute information of the vertex, the target data segment is used as one item in the attribute information of the vertex. The length of the target data segment is the same as the length of the attribute information of the primitive. The position of the target data segment in the attribute information of the vertex is the same as the position of the attribute information of the primitive in the attribute information of the vertex.

8. The apparatus according to claim 1, characterized in that, The control module includes a primitive control unit and a vertex control unit, and the filling module includes an index group cache and a filling unit. The primitive control unit is used to instruct the vertex control unit to start a hit test; when the shader is a mesh shader and the attribute information includes primitive attribute information, it also instructs the vertex control unit to allow the vertex to be forced to miss the tile when the vertex is the trigger vertex of the primitive being tested. The vertex control unit is used to test whether the vertices of a graph element hit the graph block, on a graph element basis, according to the instructions of the graph element control unit. If the vertex does not match the tile, an empty position is selected in the tile and determined as the position corresponding to the vertex. When a vertex hits a tile, the position corresponding to the vertex remains unchanged; based on the position corresponding to each vertex in each tile, an index group corresponding to each tile is obtained, and the index group is cached in the index group cache; The filling unit is used to write attribute information to the position corresponding to the vertex in the tile according to the index group included in the index group cache, and to write the index group included in the index group cache into the tile.

9. A graphics processor, characterized in that, Includes the tile filling device according to any one of claims 1-8.

10. An electronic device, characterized in that, Includes the graphics processor described in claim 9.

11. A method for filling blocks, characterized in that, The method is applied to a tile filling device, wherein the tile is used to store attribute information generated when the geometry processing pipeline implements the function of the shader. The device includes a control module and a filling module, and the method includes: The control module determines the position of a vertex in a tile; wherein, the control module tests whether the vertices of a primitive hit the tile on a primitive basis; when any primitive is tested, multiple vertices of that primitive are tested to see if they hit the tile; when a vertex does not hit the tile, an empty position is selected in the tile and determined as the position corresponding to the vertex; when the shader is a mesh shader and the attribute information includes the attribute information of primitives, when a vertex is the trigger vertex of the currently tested primitive, the vertex is forced to not hit the tile, so that each time the vertex is the trigger vertex of a primitive, the position corresponding to the vertex is incremented by one, and the newly added position is used to store the attribute information of the primitive; The filling module writes attribute information to the position in the block corresponding to the vertex.

Images