Methods and systems for vertex attribute mapping in GPU front-end and back-end shaders

Abstract

This invention discloses a method and system for vertex attribute mapping between GPU front-end and back-end shaders. The method includes: calculating the corresponding address in the vertex intermediate data buffer for the output vertex attributes of the front-end shader based on the output definition of the front-end shader and the input definition of the back-end shader, establishing a first mapping relationship between the output vertex attributes and the address; searching for the corresponding address in the vertex intermediate data buffer for the input vertex attributes of the back-end shader, establishing a second mapping relationship between the input vertex attributes and the address; and performing storage and retrieval processing on the input vertex attributes according to the first and second mapping relationships. The system includes a first mapping module, a second mapping module, and a rasterization module. The technical solution of this invention can save storage space in the vertex intermediate data buffer, reducing the data processing pressure on the rasterization stage and the back-end shader, thus improving the speed and efficiency of GPU graphics rendering.

Description

Technical Field

[0001] This invention relates to the field of graphics rendering technology, and in particular to a method and system for vertex attribute mapping for GPU front-end and back-end shaders. Background Technology

[0002] The GPU (Graphics Processing Unit) graphics rendering process involves a series of sequences and steps, known as the pipeline. Each step performs its specific function, ultimately completing the graphics rendering. Typically, we divide the GPU rendering pipeline into two main categories: the front stage and the back stage. The front stage includes input assemblies, vertex shaders, tessellation shaders, and geometry shaders, while the back stage includes rasterization, pixel shaders, output merging, and stream output. We also categorize shaders based on their position in the pipeline: front-end shaders include vertex shaders, hull shaders, domain shaders, and geometry shaders, while back-end shaders include pixel shaders. The entire pipeline is as follows: Figure 1 As shown, the front-end shader processes vertices or the primitives formed by vertices, while the back-end shader processes all pixels in each frame. Typically, the latter processes significantly more data than the former. Therefore, improving the efficiency of the back-end shader is a key factor in GPU graphics rendering speed.

[0003] In traditional graphics rendering pipelines, there is a one-to-one mapping relationship between the vertex attributes of the front-end shader and the back-end shader. However, in some graphics rendering applications, the vertex attributes output by the front-end shader are not used by the back-end shader to calculate pixel color attributes. When the back-end shader does not use all the output of the front-end shader, the following problems may occur: (1) wasting storage space for intermediate data; (2) redundant and useless data interpolation operations; (3) wasting the resources of the back-end shader. Summary of the Invention

[0004] One of the objectives of this invention is to overcome the shortcomings of the prior art. In view of the problem that GPU front-end shaders and back-end shaders waste GPU resources and affect the speed and efficiency of graphics rendering during the graphics rendering process, this invention provides a method and system for vertex attribute mapping of GPU front-end and back-end shaders.

[0005] To achieve the above objectives, the present invention is implemented through the following technical solution:

[0006] In a first aspect, the present invention provides a method for vertex attribute mapping in GPU front-end and back-end shaders, the method comprising:

[0007] Step 100: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader, and establish the first mapping relationship between the output vertex attribute and the address.

[0008] Step 200: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, find the corresponding address for the input vertex attribute of the back-end shader in the vertex intermediate data buffer, and establish a second mapping relationship between the input vertex attribute and the address.

[0009] Step 300: Perform storage and retrieval processing on the input vertex attributes according to the first mapping relationship and the second mapping relationship.

[0010] In a preferred embodiment of this application, Step 100 specifically includes:

[0011] Step 110: Predefine the output vertex attributes of the front-end shader and the input vertex attributes of the back-end shader to obtain the output definition of the front-end shader and the input definition of the back-end shader;

[0012] Step 120: Determine whether the output vertex attributes of the front-end shader can be used as the input vertex attributes of the back-end shader.

[0013] Step 130: According to the order of the multiple output vertex attributes in the output definition, allocate the address of the vertex intermediate data buffer area for each output vertex attribute in sequence;

[0014] Step 140: Establish the first mapping relationship based on the output vertex attributes of the front-end shader and their corresponding addresses.

[0015] In a preferred embodiment of this application, Step 130 specifically includes:

[0016] Step 131: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, determine whether each output vertex attribute has a corresponding input vertex attribute according to the order in which the output vertex attributes are output; if no corresponding input vertex attribute exists, proceed to Step 132; if a corresponding input vertex attribute exists, proceed to Step 133.

[0017] Step 132: Record the storage code of the output vertex attribute as 0, and continue to allocate addresses for the next output vertex attribute;

[0018] Step 133: Based on the channel activated by the corresponding input vertex attribute in the output vertex attribute, record the storage code corresponding to the output vertex attribute;

[0019] Step 134: Based on the storage code corresponding to the output vertex attribute, allocate the same number of addresses in the vertex intermediate data buffer as the channels recorded in the storage code.

[0020] In a preferred embodiment of this application, during the execution of Step 134 address allocation, addresses are sequentially allocated to vertex attributes starting from the first address.

[0021] In a preferred embodiment of this application, Step 300 specifically includes:

[0022] Step 310: Based on the first mapping relationship, determine whether the output vertex attribute needs to be stored by using the storage code of the output vertex attribute; if the storage code is 0, then execute Step 320; if the storage code is not 0, then execute Step 330.

[0023] Step 320: Discard the output vertex attribute;

[0024] Step 330: Query the address corresponding to the channel activated by the output vertex attribute, and send a storage request to the vertex intermediate data buffer;

[0025] Step 340: According to the storage request, the vertex intermediate data buffer stores the channel data activated by the output vertex attribute into the corresponding address;

[0026] Step 350: Based on the second mapping relationship, obtain the address occupied by the output vertex attribute corresponding to the input vertex attribute in the vertex intermediate data buffer area;

[0027] Step 360: Read the output vertex attribute corresponding to the input vertex attribute according to the address, and perform storage and retrieval processing on the input vertex attribute.

[0028] In a preferred embodiment of this application, Step 200 specifically includes:

[0029] Step 210: Based on the output definition of the front-end shader and the input definition of the back-end shader, query the storage address of the input vertex attribute of the back-end shader in the vertex intermediate data buffer area one by one according to the output vertex attribute of the front-end shader corresponding to the input vertex attribute of the back-end shader.

[0030] Step 220: Establish a second mapping relationship based on the attributes of each input vertex and its corresponding address.

[0031] In a second aspect, the present invention provides a system for vertex attribute mapping of GPU front-end and back-end shaders, the system comprising a first mapping module, a second mapping module and a vertex processing rasterization module;

[0032] The first mapping module is used to calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader according to the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, and establish a first mapping relationship between the output vertex attribute and the address;

[0033] The second mapping module is used to find the corresponding address of the input vertex attribute of the backend shader in the vertex intermediate data buffer according to the correspondence between the output definition of the frontend shader and the input definition of the backend shader, and establish a second mapping relationship between the input vertex attribute and the address;

[0034] The vertex processing rasterization module is used to store and process the input vertex attributes according to the first mapping relationship and the second mapping relationship.

[0035] Thirdly, the present invention provides a GPU graphics rendering pipeline, the pipeline system including a front-end pipeline, a vertex intermediate data buffer, a back-end pipeline, a first mapping module and a second mapping module;

[0036] The first mapping module is connected in the front-end pipeline between the last front-end shader and the vertex intermediate data buffer.

[0037] The second mapping module is connected between the rasterization module of the back-end pipeline and the vertex intermediate data buffer.

[0038] The vertex intermediate data buffer area is connected to the rasterization module;

[0039] The first mapping module is used to calculate the address of the final output vertex attribute of the front-end shader in the vertex intermediate data buffer according to the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, and establish a first mapping relationship between the output vertex attribute and the address.

[0040] The second mapping module is used to find the corresponding address of the input vertex attribute of the backend shader in the vertex intermediate data buffer according to the correspondence between the output definition of the frontend shader and the input definition of the backend shader, and establish a second mapping relationship between the input vertex attribute and the address;

[0041] The vertex processing rasterization module is used to store and process the input vertex attributes according to the first mapping relationship and the second mapping relationship.

[0042] Fourthly, the present invention provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the vertex attribute mapping method for GPU front-end and back-end shaders as described in the first aspect.

[0043] Fifthly, the present invention provides a computer program product comprising a computer program that, when run on a computer, causes the computer to perform the vertex attribute mapping method for GPU front-end and back-end shaders as described in the first aspect.

[0044] The method and system for vertex attribute mapping for GPU front-end and back-end shaders disclosed in this invention can save storage space in the vertex intermediate data buffer area, which serves as the vertex intermediate data buffer area, reduce the data processing pressure of the rasterization stage and the back-end shader, and help improve the speed and efficiency of GPU graphics rendering. Attached Figure Description

[0045] The present invention is described with reference to the following figures:

[0046] Figure 1 This is a flowchart of the steps in the existing GPU graphics rendering pipeline;

[0047] Figure 2 It refers to the mapping relationship between vertex shaders and vertex intermediate data buffers, and between pixel shaders and vertex intermediate data buffers in the existing GPU graphics rendering process;

[0048] Figure 3 This is a flowchart of the vertex data processing steps in the existing GPU graphics rendering process.

[0049] Figure 4This is a flowchart of the steps of the method for vertex attribute mapping for GPU front-end and back-end shaders in Embodiment 1 of the present invention;

[0050] Figure 5 This is a flowchart of Step 100 in the method for vertex attribute mapping of GPU front-end and back-end shaders in Embodiment 1 of the present invention.

[0051] Figure 6 This is a flowchart of Step 130 in the method for vertex attribute mapping of GPU front-end and back-end shaders in Embodiment 1 of the present invention.

[0052] Figure 7 This is a flowchart of Step 200 in the method for vertex attribute mapping of GPU front-end and back-end shaders in Embodiment 1 of the present invention.

[0053] Figure 8 This is a flowchart of Step 300 in the method for vertex attribute mapping of GPU front-end and back-end shaders in Embodiment 1 of the present invention.

[0054] Figure 9 This is a schematic diagram of the operation of storing and retrieving input vertex attributes of the back-end shader in the vertex attribute mapping method for GPU front-end and back-end shaders in Embodiment 1 of the present invention.

[0055] Figure 10 This is a schematic diagram of the system for vertex attribute mapping of GPU front-end and back-end shaders in Embodiment 2 of the present invention;

[0056] Figure 11 This is a schematic diagram of the GPU graphics rendering pipeline in Embodiment 3 of the present invention.

[0057] 11-First mapping module; 12-Second mapping module; 13-Rasterization module; 20-Front end; 30-Vertex intermediate data buffer; 40-Back end. Detailed Implementation

[0058] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0059] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0060] Example 1

[0061] Embodiment 1 of this invention discloses a method for vertex attribute mapping in GPU front-end and back-end shaders, which can be applied to graphics rendering applications. In these applications, the back-end shader only uses the vertex attributes to calculate pixel color attributes. In conventional methods, all outputs of the front-end shader are stored in a cache and interpolated as input to the back-end shader. This approach results in useless intermediate data consuming storage space, and interpolating useless channels in pixels reduces the efficiency of the back-end shader.

[0062] For example, suppose that in a graphics rendering process, the vertex shader is the last module in the front end and performs rasterization. The output vertex attributes of the vertex shader and the input vertex attributes of the pixel shader are defined respectively, as shown in Table 1 below.

[0063] Vertex shader output definition Pixel shader input definition dcl_outputo[0].xyzw dcl_input_psv[5].xyzw dcl_outputo[1].xyzw dcl_input_psv[2].x dcl_outputo[2].xyzw dcl_input_psv[3].yw dcl_outputo[3].xyzw dcl_input_psv[0].z dcl_outputo[4].xyzw dcl_outputo[5].xyzw

[0064] Table 1: Examples of Vertex Shader Outputs and Pixel Shader Inputs

[0065] In this design, the vertex shader has six output vertex attributes, Output0 to Output5, while the pixel shader only uses four outputs of the vertex shader, with input vertex attributes being Output5.xyzw, Output2.x, Output3.yw, and Output0.z, respectively. In existing technologies and methods, the mapping relationship between the vertex shader's output vertex attributes, storage, and the pixel shader's input vertex attributes is as follows: Figure 2 As shown, the data flow for graphical plotting is as follows: Figure 3 As shown. It should be noted that both output vertex attributes and input vertex attributes are vertex attributes. The channel data contained in the output vertex attributes can be used as parameters by the input vertex attributes. The distinction between "output" and "input" here is only to indicate the data flow direction of the vertex attributes.

[0066] See Figure 2 Although the pixel shader only uses a portion of the vertex output attributes from the vertex shader, the latter stores all of its vertex output attributes in the intermediate vertex data buffer, wasting the storage space of the intermediate vertex data buffer. Specifically:

[0067] 1. The vertex shader's Output 0 occupies addresses 0 / 1 / 2 / 3 of the vertex intermediate data buffer, a total of 4 DWORDs (storage units, 1 DWORD = 32 bits). The pixel shader uses the z channel data, a total of 1 DWORD, wasting 1 DWORD space.

[0068] 2. Output 1 of the vertex shader occupies addresses 4 / 5 / 6 / 7 of the vertex intermediate data buffer, a total of 4 DWORDs. The pixel shader does not use any channel data, wasting 4 DWORDs of space.

[0069] 3. Output 2 of the vertex shader occupies addresses 8 / 9 / 10 / 11 of the vertex intermediate data buffer, a total of 4 DWORDs. The pixel shader uses the x channel data, a total of 1 DWORD, wasting 3 DWORDs of space.

[0070] 4. Output 3 of the vertex shader occupies addresses 12 / 13 / 14 / 15 of the vertex intermediate data buffer, a total of 4 DWORDs. The pixel shader uses the y and w channel data, a total of 2 DWORDs, wasting 2 DWORDs of space.

[0071] 5. Output 4 of the vertex shader occupies addresses 16 / 17 / 18 / 19 of the vertex intermediate data buffer, a total of 4 DWORDs. The pixel shader does not use any channel data, wasting 4 DWORDs of space.

[0072] 6. Output 5 of the vertex shader occupies addresses 20 / 21 / 22 / 23 of the vertex intermediate data buffer, a total of 4 DWORDs. The pixel shader uses the x, y, w, z channel data, a total of 4 DWORDs, wasting 0 DWORDs of space.

[0073] As can be seen from the above analysis, the vertex shader outputs 6 vertex attributes, occupying 24 DWORD storage spaces, of which 8 are useful data and the remaining 16 are useless data.

[0074] like Figure 3 As shown, the tessellation shader and geometry shader are not active (indicated by dashed lines), and the vertex shader passes its output vertex attribute data through to the vertex intermediate data buffer. The rasterization module interpolates the output vertex attributes of all vertex shaders and uses them as input vertex attributes for the pixel shader. This processing method wastes GPU resources and affects graphics rendering speed and efficiency.

[0075] Therefore, the method disclosed in Embodiment 1 can reduce intermediate data access operations and storage space, eliminate interpolation of useless channels in pixels, reduce input to the back-end shader, and help improve the speed and efficiency of GPU graphics rendering.

[0076] See Figure 4 The method in this embodiment 1 includes:

[0077] Step 100: Based on the output definition of the front-end shader and the input definition of the back-end shader, calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader, and establish the first mapping relationship between the output vertex attribute and the address.

[0078] Step 200: Based on the output definition of the front-end shader and the input definition of the back-end shader, find the corresponding address in the vertex intermediate data buffer for the input vertex attributes of the back-end shader, and establish the second mapping relationship between the input vertex attributes and the address.

[0079] Step 300: Storing and retrieving the input vertex attributes according to the first and second mapping relationships.

[0080] Specifically, the GPU graphics rendering process is divided into two stages: the front-end and the back-end. For example... Figure 1 The two dashed boxes shown represent the front and back ends. The front end includes the front shader, which outputs vertex attributes, while the back end includes the back end shader, which inputs vertex attributes. In some cases, not all of the data output by the front end is used by the back end; some data becomes useless. Therefore, it is necessary to filter the front end's output data, discarding data that will not be used by the back end and not storing it in the vertex intermediate data buffer. For example... Figure 2 The mid-vertex shader outputs data containing four output vertex attributes that correspond to the input vertex attributes of the pixel shader. These four output vertex attributes correspond to non-zero addresses, occupying eight addresses in the vertex intermediate data buffer. By storing the data used by the input vertex attributes in the output vertex attributes into the vertex intermediate data buffer, and ignoring unused data, a significant amount of storage space is saved in the vertex intermediate data buffer, greatly reducing resource consumption. A first mapping relationship is established between the data in the front-end output stored in the vertex intermediate data buffer and its address in the vertex intermediate data buffer. Then, based on the output and address associations in the first mapping relationship, the back-end input data is associated with its address. This second mapping relationship is the correspondence between the back-end input data and its storage address. Finally, when processing the input vertex attributes, based on the second mapping relationship, only the data needed by the back-end needs to be read from the vertex intermediate data buffer, greatly reducing the data processing pressure on the back-end and improving the speed and efficiency of GPU graphics rendering.

[0081] See Figure 5 In the method of this embodiment 1, Step 100 specifically includes:

[0082] Step 110: Predefine the output vertex properties of the front-end shader and the input vertex properties of the back-end shader to obtain the output definition of the front-end shader and the input definition of the back-end shader;

[0083] Step 120: Determine whether the output vertex attributes of the front-end shader can be used as the input vertex attributes of the back-end shader.

[0084] Step 130: Allocate the address of the intermediate data buffer area for each vertex in the order of the multiple output vertex attributes in the output definition;

[0085] Step 140: Establish the first mapping relationship based on the attributes of each output vertex and its corresponding address.

[0086] Specifically, the data output from the front end is stored in the vertex intermediate data buffer. This data is output by the last working module in the front end (e.g., the last vertex shader). To facilitate the processing of data from the front end and the back end, the output vertex attributes of the front end shader and the input vertex attributes of the back end shader are predefined according to pre-set rules, ensuring that the output and input vertex attributes have the same format, as shown in Table 1 above. The process of establishing the first mapping relationship involves establishing a one-to-one correspondence between the output vertex attributes of the front end shader, the storage codes representing the quantity and type of data used by the input vertex attributes of the back end shader in the output vertex attributes, and the addresses where these data are stored in the vertex intermediate data buffer, and then removing useless data. Taking the example in Table 1, for the 24 data points output from the front end, 8 are useful and 16 are useless. Removing the useless data saves 16 addresses of storage space in the vertex intermediate data buffer.

[0087] See Figure 6 In the method of this embodiment 1, Step 130 specifically includes:

[0088] Step 131: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, check whether each output vertex attribute has a corresponding input vertex attribute in the order in which the output vertex attributes are output; if no corresponding input vertex attribute exists, proceed to Step 132; if a corresponding input vertex attribute exists, proceed to Step 133.

[0089] Step 132: Record the storage code of the vertex attribute as 0, and continue to allocate addresses for the next output vertex attribute;

[0090] Step 133: Based on the channel activated by the corresponding input vertex attribute in the output vertex attribute, record the storage code corresponding to the output vertex attribute;

[0091] Step 134: Based on the storage code corresponding to the output vertex attribute, allocate the same number of addresses in the vertex intermediate data buffer as the channels recorded in the storage code.

[0092] Specifically, the output definition encodes the attributes and channels of each output vertex in the front-end output, while the input definition encodes the attributes and channels of each input vertex in the back-end input. The output vertex attributes of the front-end shader and the input vertex attributes of the back-end shader are arranged sequentially, as are the channels in the output vertex attributes and the channels in the input vertex attributes. For example, in the example shown in Table 1 above, the six output vertex attributes of the front-end shader are arranged in the order {0,1,2,3,4,5}, and the four channels of each output vertex attribute are arranged in the order {x,y,z,w}. The four input vertex attributes of the back-end shader correspond to the indices of the output vertex attributes of the front-end shader, which are {5,2,3,0}, and the channels of each output vertex attribute are still arranged in the order {x,y,z,w}. However, not all output vertex attributes have corresponding input vertex attributes, and not every channel in an output vertex attribute with a corresponding input vertex attribute is activated by that input vertex attribute. Therefore, by assigning different values ​​to the channels activated and inactive by the corresponding input vertex attributes in each output vertex attribute—for example, assigning a value of 1 to activated channels and a value of 0 to inactive channels—each output vertex attribute can have a corresponding code through the permutation and combination of 1s and 0s. This code constitutes the storage code for each output vertex attribute, representing the channel usage. Each channel corresponds to 1 bit, and each storage code corresponds to 4 bits. The storage code reveals the number of addresses and storage locations that each output vertex attribute should occupy in the vertex intermediate data buffer, allowing for the allocation of addresses to each output vertex attribute sequentially. Preferably, during the address allocation process in Step 134, addresses are allocated sequentially starting from the first address, that is, starting from address 0 in the vertex intermediate data buffer for the first output vertex attribute.Taking the configuration in Table 1 as an example, in output vertex attribute "0", the z channel is used by the backend shader, its storage code is 0x4[0b0100], which is the binary number 0100, the starting address is 0, and the actual storage location occupied is 1 DWORD; in output vertex attribute "1", no data is used by the input vertex attribute, its storage code is 0x0[0b0000], which is the binary number 0000, the actual storage location occupied is 0, the starting address is meaningless, and no data is stored; in output vertex attribute "2", the x channel is used by the input vertex attribute, its storage code is 0x1[0b0001], which is the binary number 0001, the starting address is 1, and the actual storage location occupied is 1 DWORD. In the output vertex attribute "3", the y and w channels are used by the input vertex attribute, and their storage code is 0xA[0b1010], which is the binary number 1010. The starting address is 2, and the actual storage location occupied is 2 DWORDs. In the output vertex attribute "4", no data is used by the input vertex attribute, and its storage code is 0x0[0b0000], which is the binary number 0000. The actual storage location occupied is 0, and the starting address is meaningless, so no data is stored. In the output vertex attribute "5", x, y, z, and w are used by the input vertex attribute, and their storage code is 0xF[0b1111], which is the binary number 1111. The starting address is 4, and the actual storage location occupied is 4 DWORDs.

[0093] The first mapping relationship established as a result is shown in Table 2:

[0094] Output vertex properties of the front shader Storage code address 0 0xC[0b0100] 0 1 0x0[0b0000] N / A 2 0x1[0b0001] 1 3 0xA[0b1010] 2 4 0x0[0b0000] N / A 5 0xF[0b1111] 4

[0095] Table 2: First mapping relationship between the output vertex attributes of the front-end shader and the addresses of the vertex intermediate data buffer.

[0096] In Table 2, the six output vertex attributes in the first column are represented by the numbers in brackets of the output definitions listed in Table 1. These numbers correspond to the output ports of the front end. The six storage codes in the second column represent the input vertex attributes and channel usage corresponding to the output vertex attributes. The six addresses in the third column, represented by numbers or symbols, indicate... Figure 2 The address is the storage location in the intermediate vertex data buffer, where "N / A" indicates that no address is allocated. The above output vertex attributes from the 6 output vertex attributes of the front-end shader produce a total of 24 channels. Using this first mapping relationship, only 9 channels are stored, effectively eliminating useless channels and saving storage space in the intermediate vertex data buffer.

[0097] See Figure 7 In the method of this embodiment 1, Step 200 specifically includes:

[0098] Step 210: Based on the output definition of the front-end shader and the input definition of the back-end shader, query the storage address of the input vertex attribute of the back-end shader in the vertex intermediate data buffer area one by one according to the output vertex attribute of the front-end shader corresponding to the input vertex attribute of the back-end shader.

[0099] Step 220: Establish a second mapping relationship based on the attributes of each input vertex and its corresponding address.

[0100] Specifically, if the backend input does not utilize all the outputs from the frontend, the input vertex attributes of the backend shader will not be consistent with the output vertex attributes of the frontend shader, and their order may also differ. Therefore, to ensure the correctness of the backend input, a second mapping relationship needs to be established to characterize the correspondence between the input vertex attributes of the backend shader and the addresses of the output vertex attributes of the frontend shader that it should request to be read, stored in the vertex intermediate data buffer. For example, in the example shown in Table 1 above, the six output vertex attributes of the frontend shader are arranged in the order {0,1,2,3,4,5}, and the four channels of each output vertex attribute are arranged in the order {x,y,z,w}. The four input vertex attributes of the backend shader correspond to the four input ports of the backend {0,1,2,3}, and the channels of each input vertex attribute are still arranged in the order {x,y,z,w}. Referring to the correspondence between input vertex attributes and output vertex attributes shown in Table 1 above, and the first mapping relationship between output vertex attributes and addresses shown in Table 2 above, the starting position and number of addresses to be read from the vertex intermediate data buffer are determined by judging the number of channels activated by each input vertex attribute. Inputting vertex attribute "0" corresponds to outputting vertex attribute "5", activating four channels {x, y, z, w}. According to the first mapping relationship, its starting address in the vertex intermediate data buffer is 4, and four consecutive DWORDs are read. Inputting vertex attribute "1" corresponds to outputting vertex attribute "2", activating one channel {x}. According to the first mapping relationship, its starting address in the vertex intermediate data buffer is 1, and one DWORD is read. Inputting vertex attribute "2" corresponds to outputting vertex attribute "3", activating two channels {y, w}. According to the first mapping relationship, its starting address in the vertex intermediate data buffer is 2, and two consecutive DWORDs are read. Inputting vertex attribute "3" corresponds to outputting vertex attribute "0", activating one channel {z}. According to the first mapping relationship, its starting address in the vertex intermediate data buffer is 0, and one DWORD is read. The second mapping relationship established in this way is shown in Table 3.

[0101] Input vertex properties of the backend shader Corresponding output vertex attributes address 0 5.xyzw 4 1 2.x 1 2 3.yw 2 3 0.z 0

[0102] Table 3: Second mapping relationship between input vertex attributes of the backend shader and addresses of the vertex intermediate data buffer

[0103] In Table 3, the four numbers in the first column represent the backend input ports, each corresponding one-to-one with the pixel attributes used for graphics rendering based on the input vertex attributes. The four codes in the second column represent the output vertex attributes corresponding to the four input vertex attributes. These codes are composed of the sequence numbers of each output vertex attribute in the first column of Table 1 and the channels activated by the input vertex attributes. The address in the third column indicates the starting position where the corresponding output vertex attribute should be stored in the vertex intermediate data buffer for the input vertex attribute. The number of read addresses is determined by the number of activated channels in the second column. For example, inputting vertex attribute "0" should start from address "4" in the vertex intermediate data buffer and sequentially read the output vertex attribute "5.xyzw" corresponding to four addresses {4,5,6,7}. Inputting vertex attribute "1" should start from address "1" in the vertex intermediate data buffer and sequentially read the output vertex attribute "2.x" corresponding to one address {1}. Inputting vertex attribute "2" should start from address "2" in the vertex intermediate data buffer and sequentially read the output vertex attribute "3.yw" corresponding to two addresses {2,3}. Inputting vertex attribute "3" should start from address "0" in the vertex intermediate data buffer and sequentially read the output vertex attribute "0.z" corresponding to one address {0}. The reading order of these four input vertex attributes is not fixed and can start from any input vertex attribute.

[0104] The method in this embodiment 1 can process vertex attributes through the first and second mapping relationships established above.

[0105] See Figure 8 In the method of this embodiment 1, Step 300 specifically includes:

[0106] Step 310: Based on the first mapping relationship, determine whether the output vertex attribute needs to be stored by checking the storage code of the output vertex attribute; if the storage code is 0, proceed to Step 320; if the storage code is not 0, proceed to Step 330.

[0107] Step 320: Discard the output vertex attribute;

[0108] Step 330: Query the address corresponding to the channel activated by the output vertex attribute, and send a storage request to the vertex intermediate data buffer;

[0109] Step 340: Based on the storage request, store the channel activated by the output vertex attribute into the corresponding address in the vertex intermediate data buffer;

[0110] Step 350: Based on the second mapping relationship, obtain the address occupied by the output vertex attribute corresponding to the input vertex attribute in the vertex intermediate data buffer area;

[0111] Step 360: Read the output vertex attribute corresponding to the input vertex attribute according to the address, and perform storage and retrieval processing on the input vertex attribute.

[0112] Specifically, Steps 310 to 360 involve processing the input vertex attributes. Based on the first and second mapping relationships, the storage of the front-end output and the reading of the back-end input are processed, and finally, the input vertex attributes are processed at the back-end. This enables memory saving, elimination of redundant interpolation, and reduction of back-end input during the graphics rendering process. The GPU graphics rendering process in Example 1 is explained using the front-end output definition and back-end input definition shown in Table 1 as examples.

[0113] See Figure 9During GPU graphics rendering, Steps 310 to 330 process the output vertex attributes of the front-end shader. The storage codes corresponding to the output vertex attributes in the first mapping relationship are used to determine whether a corresponding input vertex attribute exists, deciding whether to discard the output vertex attribute or allocate an address to it. The storage codes for output vertex attributes "0", "2", "3", and "5" are not 0, indicating the existence of corresponding input vertex attributes. However, the storage codes for output vertex attributes "1" and "4" are 0, indicating the absence of corresponding input vertex attributes. Therefore, when processing output vertex attributes "1" and "4", these two output vertex attributes are discarded. When processing output vertex attributes "0", "2", "3", and "5", the subsequent Step 340 is executed to allocate addresses for them. Continuing with the first mapping relationship, the starting positions of the addresses corresponding to the output vertex attributes "0", "2", "3", and "5" in the vertex intermediate data buffer are found to be "0", "1", "2", and "4", respectively. Then, based on the number of channels with codewords of 1 recorded in the storage code, address {0} is assigned to output vertex attribute "0", address {1} to output vertex attribute "2", address {2,3} to output vertex attribute "3", and address {4,5,6,7} to output vertex attribute "5". Storage requests are sent to the vertex intermediate data buffer based on the addresses corresponding to the output vertex attributes "0", "2", "3", and "5". The vertex intermediate data buffer, according to the storage codes corresponding to the output vertex attributes in the first mapping relationship (i.e., Table 2), stores the channels with codewords of 1 in each output vertex attribute into the corresponding addresses. According to the stored code, the channel activated for output vertex attribute "0" is {z}, and it is stored in address {0}; the channel activated for output vertex attribute "2" is {x}, and it is stored in address {1}; the channel activated for output vertex attribute "3" is {y,w}, and it is stored in address {2,3}; the channel activated for output vertex attribute "5" is {x,y,z,w}, and it is stored in address {4,5,6,7}.

[0114] After completing the storage phase of the output vertex attributes of the front-end shader, Steps 350 to 360 are executed to continue the phase of reading and processing the input vertex attributes of the back-end shader. The vertex intermediate data buffer, based on the request to read the input vertex attributes from the back-end, reads the corresponding channels of the output vertex attributes stored at each address according to the reading position of the address corresponding to each input vertex attribute in the second mapping relationship (i.e., Table 3). For input vertex attribute "0", the channel {x,y,z,w} of output vertex attribute "5" stored at address {4,5,6,7} is read; for input vertex attribute "1", the channel {x} of output vertex attribute "2" stored at address {1} is read; for input vertex attribute "2", the channel {y,w} of output vertex attribute "3" stored at address {2,3} is read; and for input vertex attribute "3", the channel {z} of output vertex attribute "0" stored at address {0} is read. The intermediate vertex data buffer sends the read data to the backend, where the rasterization module performs primitive creation, clipping, culling, perspective correction, and interpolation on the read input vertex attribute data, and the pixel shader processes the results.

[0115] The method disclosed in this embodiment 1, compared with the traditional method, can save the storage space of the vertex intermediate data buffer, reduce the back-end interpolation operation, eliminate the useless input of the pixel shader in the back-end, and improve the efficiency of graphics drawing. The efficiency improvement is shown in Table 4 below.

[0116]

[0117] Table 4: Efficiency Improvement of the Method in Example 1 Compared to Traditional Methods

[0118] Example 2

[0119] Embodiment 2 of this invention discloses a system for vertex attribute mapping between GPU front-end and back-end shaders, which can be applied to graphics rendering applications. In these applications, the back-end shader only uses the vertex attributes to calculate pixel color attributes. In existing systems, all outputs of the front-end shader are stored in a cache and interpolated as input to the back-end shader. This process results in useless intermediate data consuming storage space, and interpolating useless channels in pixels reduces the efficiency of the back-end shader.

[0120] See Figure 10The system in this embodiment 2 includes a first mapping module 11, a second mapping module 12, and a vertex processing rasterization module 13. The first mapping module 11 is used to calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader according to the output definition of the front-end shader and the input definition of the back-end shader, and establish a first mapping relationship between the output vertex attribute and the address. The second mapping module 12 is used to find the corresponding address in the vertex intermediate data buffer for the input vertex attribute of the back-end shader according to the output definition of the front-end shader and the input definition of the back-end shader, and establish a second mapping relationship between the input vertex attribute and the address. The vertex processing rasterization module 13 is used to perform storage and retrieval processing on the input vertex attribute according to the first mapping relationship and the second mapping relationship.

[0121] Specifically, the GPU graphics rendering process is divided into two stages: the front-end and the back-end. For example... Figure 1 The two dashed boxes shown represent the front and back ends. The front end includes the front shader, which outputs vertex attributes, while the back end includes the back end shader, which inputs vertex attributes. In some cases, not all of the data output by the front end is used by the back end; some data becomes useless. Therefore, it is necessary to filter the front end's output data, discarding data that will not be used by the back end and not storing it in the vertex intermediate data buffer. For example... Figure 2 The data output by the mid-vertex shader includes four output vertex attributes that correspond to the input vertex attributes of the pixel shader. These four output vertex attributes correspond to non-zero addresses, occupying eight addresses in the vertex intermediate data buffer. By storing the data used by the input vertex attributes in the output vertex attributes into the vertex intermediate data buffer, and ignoring useless data, a significant amount of storage space is saved in the vertex intermediate data buffer, greatly reducing resource consumption. Therefore, the first mapping module 11 establishes a first mapping relationship between the data stored in the vertex intermediate data buffer from the front-end output and its address in the vertex intermediate data buffer. Then, the second mapping module 12 associates the back-end input data with its address based on the output and address associated in the first mapping relationship. The mapping relationship between the back-end input data and its storage address is the second mapping relationship. Finally, when the input vertex attributes are processed by the rasterization module 13 in the GPU, based on the first and second mapping relationships, only the data required by the back-end input needs to be read from the vertex intermediate data buffer, greatly reducing the pressure on the back-end data processing and improving the speed and efficiency of GPU graphics rendering.

[0122] Example 3

[0123] Embodiment 3 of the present invention discloses a GPU graphics rendering pipeline, such as Figure 11As shown, the pipeline system includes a front-end 20, a vertex intermediate data buffer 30, a back-end 40, a first mapping module 11, and a second mapping module 12. The first mapping module 11 is connected between the front-end shader located at the end of the front-end 20 and the vertex intermediate data buffer 30. The second mapping module 12 is connected between the rasterization module 13 of the back-end 40 and the vertex intermediate data buffer 30. The rasterization module 13 can be used to access and process the input vertex attributes. The vertex intermediate data buffer 30 is connected to the rasterization module 13. The first mapping module 11 is used to map the output definition of the front-end shader and the back-end... The input definition of the shader calculates the address of the final output vertex attribute of the front-end shader in the vertex intermediate data buffer 30, establishing a first mapping relationship between the output vertex attribute and the address; the second mapping module 12 is used to find the corresponding address of the input vertex attribute of the back-end shader in the vertex intermediate data buffer 30 according to the output definition of the front-end shader and the input definition of the back-end shader, establishing a second mapping relationship between the input vertex attribute and the address; the rasterization module 13 is used to perform storage and retrieval processing on the input vertex attribute according to the first mapping relationship and the second mapping relationship.

[0124] The GPU graphics rendering pipeline disclosed in Embodiment 3 executes the method disclosed in Embodiment 1 of this application through the system disclosed in Embodiment 2 of this application. It can save storage space in the vertex intermediate data buffer, reduce back-end interpolation operations, eliminate useless inputs of the pixel shader in the back-end, and improve the efficiency of graphics rendering.

[0125] Example 4

[0126] Embodiment 4 of the present invention discloses a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform a vertex attribute mapping method for GPU front-end and back-end shaders as disclosed in Embodiment 1.

[0127] Example 5

[0128] Embodiment 5 of the present invention discloses a computer program product, which includes a computer program that, when run on a computer, causes the computer to perform a vertex attribute mapping method for GPU front-end and back-end shaders as disclosed in Embodiment 1.

[0129] The method and system for vertex attribute mapping for GPU front-end and back-end shaders disclosed in this invention can save storage space in the vertex intermediate data buffer area, which serves as the vertex intermediate data buffer area, reduce the data processing pressure of the rasterization stage and the back-end shader, and help improve the speed and efficiency of GPU graphics rendering.

[0130] It should be understood that the above description of specific embodiments of the present invention is only for illustrating the technical approach and features of the present invention, and is intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. However, the present invention is not limited to the specific embodiments described above. All changes or modifications made within the scope of the claims of the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for vertex attribute mapping in GPU front-end and back-end shaders, characterized in that, The method includes: Step 100: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader, and establish a first mapping relationship between the output vertex attribute and the address; Step 100 specifically includes: Step 110: Predefine the output vertex attributes of the front-end shader and the input vertex attributes of the back-end shader to obtain the output definition of the front-end shader and the input definition of the back-end shader; Step 120: Determine whether the output vertex attributes of the front-end shader can be used as the input vertex attributes of the back-end shader; Step 130: Allocate the addresses of the intermediate data buffers for each vertex in the output definition according to the order of its attributes; Step 130 specifically includes: Step 131: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, determine whether each output vertex attribute has a corresponding input vertex attribute in the order of the output vertex attributes; if no corresponding input vertex attribute exists, proceed to Step 132; if a corresponding input vertex attribute exists, proceed to Step 133. Step 132: Record the storage code of the output vertex attribute as 0, and continue to allocate addresses for the next output vertex attribute; Step 133: Based on the channel activated by the corresponding input vertex attribute in the output vertex attribute, record the storage code corresponding to the output vertex attribute; Step 134: Based on the storage code corresponding to the output vertex attribute, allocate the same number of addresses in the vertex intermediate data buffer as the channels recorded in the storage code; Step 140: Establish a first mapping relationship based on the output vertex attributes of the front-end shader and their corresponding addresses; Step 200: Based on the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, find the corresponding address for the input vertex attribute of the back-end shader in the vertex intermediate data buffer, and establish a second mapping relationship between the input vertex attribute and the address. Step 300: Perform storage and retrieval processing on the input vertex attributes according to the first mapping relationship and the second mapping relationship; Step 300 specifically includes: Step 310: Based on the first mapping relationship, determine whether the output vertex attribute needs to be stored by using the storage code of the output vertex attribute; if the storage code is 0, then execute Step 320; if the storage code is not 0, then execute Step 330. Step 320: Discard the output vertex attribute; Step 330: Query the address corresponding to the channel activated by the output vertex attribute, and send a storage request to the vertex intermediate data buffer; Step 340: According to the storage request, the vertex intermediate data buffer stores the channel data activated by the output vertex attribute into the corresponding address; Step 350: Based on the second mapping relationship, obtain the address occupied by the output vertex attribute corresponding to the input vertex attribute in the vertex intermediate data buffer area; Step 360: Read the output vertex attribute corresponding to the input vertex attribute according to the address, and perform storage and retrieval processing on the input vertex attribute.

2. The method according to claim 1, characterized in that, During the execution of Step 134 address allocation, addresses are sequentially allocated to output vertex attributes, starting from the first address.

3. The method according to claim 1, characterized in that, Step 200 specifically includes: Step 210: Based on the output definition of the front-end shader and the input definition of the back-end shader, query the storage address of the input vertex attribute of the back-end shader in the vertex intermediate data buffer area one by one according to the output vertex attribute of the front-end shader corresponding to the input vertex attribute of the back-end shader. Step 220: Establish a second mapping relationship based on the attributes of each input vertex and its corresponding address.

4. A system for vertex attribute mapping in GPU front-end and back-end shaders, characterized in that, The system for performing vertex attribute mapping for GPU front-end and back-end shaders as described in claim 1 includes a first mapping module, a second mapping module, and a rasterization module. The first mapping module is used to calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader according to the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, and establish a first mapping relationship between the output vertex attribute and the address; The second mapping module is used to find the corresponding address of the input vertex attribute of the backend shader in the vertex intermediate data buffer according to the correspondence between the output definition of the frontend shader and the input definition of the backend shader, and establish a second mapping relationship between the input vertex attribute and the address; The rasterization module is used to access and process the input vertex attributes according to the first mapping relationship and the second mapping relationship.

5. A GPU graphics rendering pipeline, characterized in that, The method for vertex attribute mapping for GPU front-end and back-end shaders as described in claim 1, wherein the pipeline system includes a front-end pipeline, a vertex intermediate data buffer, a back-end pipeline, a first mapping module, and a second mapping module; The first mapping module is connected in the front-end pipeline between the last front-end shader and the vertex intermediate data buffer. The second mapping module is connected between the rasterization module of the back-end pipeline and the vertex intermediate data buffer. The vertex intermediate data buffer area is connected to the rasterization module; The first mapping module is used to calculate the address in the vertex intermediate data buffer for the output vertex attribute of the front-end shader according to the correspondence between the output definition of the front-end shader and the input definition of the back-end shader, and establish a first mapping relationship between the output vertex attribute and the address; The second mapping module is used to find the corresponding address of the input vertex attribute of the backend shader in the vertex intermediate data buffer according to the correspondence between the output definition of the frontend shader and the input definition of the backend shader, and establish a second mapping relationship between the input vertex attribute and the address; The rasterization module is used to access and process the input vertex attributes according to the first mapping relationship and the second mapping relationship.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the method for vertex attribute mapping for GPU front-end and back-end shaders as described in any one of claims 1 to 3.

7. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method for vertex attribute mapping for GPU front-end and back-end shaders as described in any one of claims 1 to 3.

Images