Program performance analysis method and device, equipment, storage medium and computer program

Abstract

The invention discloses a program performance analysis method and device, equipment, a storage medium and a computer program, and belongs to the field of computers. The method comprises the following steps: providing a program test interface, wherein the program test interface is used for obtaining a rendering program to be tested; obtaining program performance parameters of the rendering program in a plurality of feature collection levels, wherein the plurality of feature collection levels comprise one or more of the following levels: a drawing calling level, a shader level, a basic block level and an instruction level; and determining the performance bottleneck of the rendering program based on the obtained program performance parameters. Namely, according to the application, the program performance parameters of the rendering program at the plurality of feature acquisition levels are obtained, so that the performance bottleneck of the rendering program is determined based on the program performance parameters of the plurality of feature acquisition levels. Therefore, through hierarchical data acquisition and analysis, the efficiency of determining the performance bottleneck of the rendering program is improved.

Description

[0001] This application claims priority to Chinese patent application No. 202311239709.2 filed on September 22, 2023, with invention name “Application performance detection method, device, equipment and storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a program performance analysis method, apparatus, device, storage medium and computer program. Background Art

[0003] Graphics rendering is an important branch in the field of computer applications. It is used to process and display images on the computer screen. It is widely used in games, movie special effects production, industrial design, medical imaging and other fields. To ensure the quality and efficiency of graphics rendering, before performing graphics rendering operations, it is necessary to perform performance tests on the rendering program designed by software developers to determine the performance bottleneck that causes the rendering program to run inefficiently.

[0004] In the related art, a rendering program written in a high-level language is first compiled to obtain a binary code that can be executed by a central processing unit (CPU) or a graphics processing unit (GPU), and then a test code is inserted into the binary code. When a computing device executes the binary code through the CPU and / or GPU, performance detection tools such as Perf, Vtune, and Nsight Graphic are used to analyze the function calls, instruction execution, memory usage, etc. of the application programming interface (API) in the rendering program, thereby determining the performance bottleneck of the rendering program.

[0005] However, when analyzing the performance bottleneck of a rendering program, the above-mentioned performance detection tools have a single detection granularity and are less efficient in locating the performance bottleneck. Summary of the invention

[0006] The present application provides a program performance analysis method, apparatus, device, storage medium and computer program, which can analyze the program performance parameters of the rendering program layer by layer from multiple feature collection levels for the rendering program to be tested, so as to quickly and effectively determine the performance bottleneck of the rendering program. The technical solution is as follows:

[0007] In a first aspect, a program performance analysis method is provided, the method comprising: providing a program test interface, the program test interface being used to obtain a rendering program to be tested; obtaining program performance parameters of the rendering program at multiple feature collection levels, the multiple feature collection levels comprising one or more of the following: a draw call level, a shader level, a basic block level, and an instruction level; based on the obtained program performance parameters, determining a performance bottleneck of the rendering program; wherein the draw call level comprises multiple draw call commands, the shader level comprises multiple shaders, the basic block level comprises multiple basic blocks, the instruction level comprises multiple instructions, and the draw call command corresponds to at least one of the shaders, the shader corresponds to at least one of the basic blocks, and the basic block comprises at least one of the instructions.

[0008] It can be seen that for the rendering program, this application sets multiple feature collection levels from coarse granularity to fine granularity. When performing performance testing on the rendering program, the program performance parameters of the rendering program at multiple feature collection levels of the rendering program are obtained, so as to determine the performance bottleneck of the rendering program based on the program performance parameters of multiple feature collection levels. In this way, the efficiency of determining the performance bottleneck of the rendering program is improved through hierarchical data collection and analysis.

[0009] Optionally, obtaining program performance parameters of the rendering program at multiple feature collection levels of the rendering program includes: inserting test code into an intermediate representation of the rendering program to obtain a test program, the intermediate representation refers to an intermediate program obtained before the rendering program is compiled into binary code; during the running of the test program, obtaining program performance parameters of the rendering program at the multiple feature collection levels in sequence according to the collection order of the multiple feature collection levels; wherein the collection order of the draw call level is earlier than that of the shader level, the collection order of the shader level is earlier than that of the basic block level, and the collection order of the basic block level is earlier than that of the instruction level.

[0010] Since the intermediate representation is the intermediate result of compiling the source program rather than a binary code associated with the hardware architecture, when obtaining program performance parameters and analyzing program performance bottlenecks, there is no need to consider the specific form of the underlying hardware architecture, nor is it restricted by the hardware architecture.

[0011] Optionally, the program performance parameters of the rendering program at the drawing call level include the execution duration of the drawing call command, the program performance parameters of the rendering program at the shader level include the number of executions of the shader, the program performance parameters of the rendering program at the basic block level include the number of calls of the basic block, and the program performance parameters of the rendering program at the instruction level include the number of executions of the instruction.

[0012] Optionally, the performance bottleneck of the rendering program includes a program hotspot; determining the performance bottleneck of the rendering program based on the acquired program performance parameters includes: determining a target drawing call command with the longest execution time from the multiple drawing call commands; determining a target shader with the largest number of executions from at least one shader corresponding to the target drawing call command; determining a target basic block with the largest number of calls from at least one basic block corresponding to the target shader; and determining a program hotspot of the rendering program based on the target basic block, the program hotspot including the instruction with the largest number of executions in the target basic block.

[0013] It can be seen that when determining the program hotspots of the rendering program, the embodiment of the present application can perform layer-by-layer analysis in the order of "drawing call level - shader level - thread level - basic block level - instruction level", and continuously narrow the analysis scope of the program hotspots, thereby quickly and effectively determining the program hotspots of the rendering program.

[0014] Optionally, the multiple feature collection levels also include a thread level, the collection order of the thread level is later than the shader level and earlier than the basic block level, the thread level includes multiple threads, and at least one basic block corresponding to the shader is executed in parallel by multiple threads.

[0015] Optionally, the program performance parameters of the rendering program at the thread level include the execution path of the thread; determining the target basic block with the largest number of calls from at least one basic block corresponding to the target shader includes: determining the target thread with the longest execution path from multiple threads used to execute at least one basic block corresponding to the target shader; determining the target basic block with the largest number of calls from the basic blocks executed by the target thread, the basic block executed by the target thread being the basic block assigned to the target thread for execution from at least one basic block corresponding to the target shader.

[0016] When multiple threads execute the target shader code in parallel, the execution path of the threads can be used to quickly determine the target basic block from the target shader without analyzing all the basic blocks in the target shader, thereby reducing the amount of data analysis and improving the efficiency of determining the target basic block from the rendering program.

[0017] Optionally, the method also includes: determining an optimization scheme for the rendering program based on the performance bottleneck of the rendering program, the optimization scheme including a program optimization method for the rendering program, and / or an optimization method for a hardware device that executes the rendering program; wherein the program optimization method includes optimization methods corresponding to the multiple feature acquisition levels respectively; and displaying the performance bottleneck of the rendering program and the optimization scheme for the rendering program through the program test interface.

[0018] That is, after the performance test of the rendering program is performed, the performance bottleneck of the rendering program and the optimization scheme of the rendering program can be displayed to the user through the program test interface. In this way, the user can refer to the performance bottleneck and the optimization scheme to optimize the rendering program or optimize the hardware device executing the rendering program.

[0019] In a second aspect, a program performance analysis device is provided, which has the function of implementing the program performance analysis method in the first aspect. The program performance analysis device includes at least one module, which is used to implement the program performance analysis method provided in the first aspect.

[0020] In a third aspect, a computing device cluster is provided, the computing device cluster comprising at least one computing device, each computing device comprising a processor and a memory;

[0021] The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the program performance analysis method described in the first aspect above.

[0022] In a fourth aspect, a computer-readable storage medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the program performance analysis method described in the first aspect.

[0023] In a fifth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the program performance analysis method described in the first aspect.

[0024] The technical effects obtained by the above-mentioned second, third, fourth and fifth aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is a flowchart of a program performance analysis method provided by an embodiment of the present application;

[0026] Figure 2 It is a schematic diagram of a collection process of program performance parameters provided in an embodiment of the present application;

[0027] Figure 3 It is a schematic diagram of a basic block branch flow graph of a ray tracing reflection program provided by an embodiment of the present application;

[0028] Figure 4It is a schematic diagram of the instruction ratio of a ray tracing program in a ray tracing pipeline provided in an embodiment of the present application;

[0029] Figure 5 is a schematic diagram of the structure of a program performance analysis device provided in an embodiment of the present application;

[0030] Figure 6 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0031] Figure 7 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0032] Figure 8 It is a schematic diagram of the network connection relationship of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0034] For ease of understanding, before explaining in detail the program performance analysis method provided in the embodiment of the present application, the terminology, relevant background and application scenarios involved in the embodiment of the present application are first introduced.

[0035] First, the terms involved in the embodiments of the present application are introduced.

[0036] 1. Intermediate representation (IR)

[0037] The intermediate representation is a very important data structure in the compiler. In compiler theory, the compiler is usually divided into the front end and the back end. The front end will perform lexical analysis, syntax analysis, semantic analysis, etc. on the input source program to generate the intermediate representation; while the back end will optimize the intermediate representation and convert the intermediate representation into binary code (also called target code or machine code) that can be executed by the target machine.

[0038] In other words, the intermediate representation is the source program representation between the syntax analysis of the source program and the generation of the target code. The intermediate representation can also be called intermediate code.

[0039] 2. Program static analysis (dynamic instrumentation)

[0040] Program static analysis, referred to as static analysis for short, refers to an analysis technique that scans a program through lexical analysis, syntax analysis, control flow, data flow analysis and other techniques without executing the program to verify whether the code meets indicators such as standardization, security, reliability, and maintainability.

[0041] In most cases, the input of static analysis is the source program. Therefore, static analysis mainly focuses on the static structure and properties of the code without involving the actual execution path and runtime behavior.

[0042] 3. Dynamic instrumentation

[0043] Dynamic instrumentation is a software debugging and analysis technology that is used to insert additional code into the code while the program is running to collect program running information, monitor program behavior, or perform program debugging and performance analysis.

[0044] 4. Draw call command (draw call)

[0045] A draw call is a command from the central processing unit (CPU) to the graphics processing unit (GPU) to point to a list of primitives that need to be rendered. A draw call can be an instruction, such as an application program interface (API) call function; it can also be a collection of multiple instructions. For example, in the open graphics library or open graphics library (OpenGL), a draw call usually contains multiple API call functions. This draw call can be considered as a drawing instruction to complete a drawing. A draw call can draw one target, or multiple draw calls can draw one target or one draw call can draw multiple targets.

[0046] 5. Shaders

[0047] A shader is a program in computer graphics that is used to color and render images during the graphics rendering process. Shaders can control image effects such as lighting, materials, textures, shadows, etc., making the rendered images more realistic and detailed.

[0048] Among them, shaders can be simply divided into the following categories:

[0049] (1) Vertex shader

[0050] Vertex shaders are mainly used to transform and process the vertices of a model. Vertex shaders receive input vertex data, such as position, normal, texture coordinates, etc., then calculate and transform these data, and finally output the transformed vertex position and other attributes.

[0051] (2) Fragment shader

[0052] Fragment shader, also known as pixel shader, is used to process each pixel of the model. Fragment shader receives data passed by vertex shader, such as vertex position, normal, texture coordinates, etc., and then performs lighting calculation, texture sampling, color calculation, etc. based on these data, and finally determines the final color and transparency of each pixel.

[0053] (3) Geometry shader

[0054] The geometry shader is an optional stage between the vertex shader and the fragment shader, which can process and operate geometric primitives (such as points, lines, triangles), such as generating new geometric primitives, modifying vertex attributes, etc. Geometry shaders are usually used to implement functions such as geometric transformations, particle systems, and normal calculations.

[0055] (4) Compute shader

[0056] Compute shader is a type of shader that is independent of the graphics rendering pipeline. It can perform general computing on the GPU, not just limited to graphics rendering. Compute shaders are often used for parallel computing tasks such as physics simulation, image processing, data processing, etc.

[0057] 6. Basic Blocks

[0058] A basic block is a sequence of statements executed sequentially in a program, with only one entry and one exit. The entry is the first statement of the program, the target statement of a transfer statement, or the first statement after a transfer statement; the exit is the last statement of the program or a transfer statement. Therefore, a typical feature of a basic block is that, if the program does not exit unexpectedly, as long as the first instruction in the basic block is executed, all instructions in the basic block will be executed only once in sequence.

[0059] 7. Threads

[0060] A thread is the smallest unit that a computer operating system can run and execute. It is part of a process and is scheduled to run by the operating system. It can run in parallel on a single or multiple CPUs / GPUs.

[0061] Secondly, the relevant background and application scenarios of the embodiments of the present application are introduced.

[0062] Graphics rendering is an important branch of computer application. Rendering involves the technology of processing and displaying images on the computer screen. It has a wide range of applications in games, movie special effects production, industrial design, medical imaging and other fields. In games, augmented reality and virtual reality, the performance of real-time graphics has a direct impact on the end-user experience; in multiple markets including game consoles, mobile devices and high-end desktops, the performance and quality of graphics applications are also regarded as a key differentiating factor.

[0063] For each graphics application designed by software developers, before it goes online, it is often necessary to perform performance analysis on the rendering program used in the graphics application to determine the performance bottleneck of the rendering program. Among them, the performance bottleneck refers to the part that limits the performance of the rendering program during its operation. It may be a function, a piece of code, or a link in the entire program. The performance bottleneck may cause the rendering program to run slower, respond late, consume too many resources, etc., thereby affecting the overall performance of the rendering program.

[0064] When performing performance analysis on a rendering program, test code is usually inserted into the compiled binary code. Then, when the computing device executes the binary code through the CPU and / or GPU, performance detection tools such as Perf, Vtune, and NsightGraphic are used to analyze the function calls, instruction executions, memory usage, etc. in the rendering program, thereby determining the performance bottleneck of the rendering program.

[0065] Since the compiled binary code is associated with the CPU and GPU architecture of the computing device that executes the binary code, different hardware architectures will also affect the actual detection effect of the above-mentioned performance detection tools. The performance bottleneck detection function of the above-mentioned performance detection tools is strongly coupled with the hardware architecture. For example, Intel's Vtune only supports the x86 architecture and Intel's GPU architecture, and Nsight Graphics only supports Nvidia's GPU architecture. Therefore, when analyzing the performance bottleneck of the rendering program based on binary code, the above-mentioned performance detection tools cannot be applied to other GPU architectures, and the detection scenarios are relatively limited. Moreover, the above-mentioned performance detection tools only analyze from the aspects of function calls and instruction execution, with a single detection granularity and low efficiency in determining performance bottlenecks.

[0066] Based on this, an embodiment of the present application provides a program performance analysis method. For a rendering program, multiple feature collection levels are set from coarse granularity to fine granularity, and the program performance parameters of the rendering program are collected and analyzed layer by layer in the collection order, so as to quickly and effectively determine the performance bottleneck of the rendering program.

[0067] The program performance analysis method provided in the embodiments of the present application can be applied to a variety of scenarios, such as the following four application scenarios.

[0068] Scenario 1: Performance Analysis and Optimization

[0069] Software developers can use the program performance analysis method provided in the embodiments of the present application to analyze the performance bottlenecks of the application and determine the parts of the application that need to be optimized, such as GPU utilization, memory access, hot functions, hot instructions, etc., to improve the response time and operating efficiency of the application.

[0070] Scenario 2: Monitoring resource utilization

[0071] The program performance analysis method provided by the embodiment of the present application can use program performance parameters collected from multiple feature collection levels to assist in monitoring resource utilization in a computing device, such as memory usage, etc. This helps developers identify resource bottlenecks when a computing device runs the application, thereby replanning resource allocation and expanding capacity.

[0072] Scenario 3: Performance Benchmarking

[0073] When an application undergoes a system upgrade or changes its configuration, the program performance analysis method provided in the embodiment of the present application may be used to perform a performance benchmark test to ensure that the system performance of the application does not degrade after the upgrade.

[0074] Scenario 4: Program Behavior Analysis

[0075] Software developers can use the program performance analysis method provided in the embodiments of the present application to analyze the specific behavior of the application during operation, such as function calls, shader types, basic block calls, memory usage, etc., so as to perform performance analysis and troubleshooting based on program behavior.

[0076] It should be understood that the application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person of ordinary skill in the art may know that with the emergence of new application detection or analysis scenarios, the program performance analysis solution based on multiple levels of collection and analysis of program performance parameters in the embodiments of the present application is also applicable to similar technical problems and application scenarios.

[0077] After introducing the relevant terms and background involved in the embodiments of the present application, the program performance analysis method provided in the embodiments of the present application is explained in detail.

[0078] Please refer to Figure 1 , Figure 11 is a flowchart of a program performance analysis method provided in an embodiment of the present application. The method can be applied to a computing device or a computing device cluster. The method includes the following steps:

[0079] Step 101: providing a program testing interface, where the program testing interface is used to obtain a rendering program to be tested.

[0080] That is, software developers, administrators and other users can upload the rendering program to be tested in the program testing interface, so that the computing devices in the computing device cluster can automatically detect and analyze the rendering program according to the following steps 102-103 to determine the performance bottleneck of the rendering program.

[0081] Step 102: Obtain program performance parameters of the rendering program at multiple feature collection levels of the rendering program.

[0082] The multiple feature collection levels of the rendering program include one or more of a draw call level, a shader level, a basic block level, and an instruction level. For a rendering program, the draw call level includes multiple draw call commands, the shader level includes multiple shaders, the basic block level includes multiple basic blocks, the instruction level includes multiple instructions, and the draw call command corresponds to at least one shader, the shader corresponds to at least one basic block, and the basic block includes at least one instruction.

[0083] It should be noted that when performing graphics rendering, the draw call command is used to pass the data of one or more basic blocks of the rendering program to the GPU for rendering. The basic block is usually composed of a group of vertices and fragments, and these vertices and fragments are connected by primitives (such as triangles, line segments, etc.). That is, the role of the draw call command is to send the data of these basic blocks to the GPU, and the GPU performs rendering calculations. The shader is a program used to handle specific tasks in the graphics rendering process, which is used to process the input vertex and fragment data to generate the final image. In the graphics rendering process, shaders are usually used to achieve various effects, such as lighting, shadows, texture mapping, etc. The relationship between the draw call command and the shader is: the draw call command sends the data of at least one basic block in the rendering program to the GPU. In the process of the GPU performing rendering calculations, the geometric data and attributes of the basic block are first converted into the shader code, and then the input vertex and fragment data are processed by the shader to generate the final image.

[0084] That is, each drawing call command corresponds to at least one shader, so as to complete the drawing operation indicated by the drawing call command by running the code of the at least one shader, and each shader corresponds to at least one basic block, so as to perform corresponding operations on the data indicated by the instructions in the at least one basic block by running the shader.

[0085] In some embodiments, when obtaining the program performance parameters of the rendering program at the multiple feature collection levels in step 102, the obtaining methods include static analysis and dynamic instrumentation. Static analysis is to directly analyze the code of the rendering program without running the rendering program; while dynamic instrumentation is to obtain the behavior information of the rendering program during its operation by inserting test code when the rendering program is running.

[0086] Taking dynamic instrumentation as an example, the implementation process of the above step 102 can be: inserting test code into the intermediate representation of the rendering program to obtain the test program; in the process of running the test program, according to the collection order of multiple feature collection levels, sequentially obtain the program performance parameters of the rendering program at multiple feature collection levels. Among them, the collection order of the draw call level is earlier than the shader level, the collection order of the shader level is earlier than the basic block level, and the collection order of the basic block level is earlier than the instruction level.

[0087] It should be noted that the intermediate representation refers to the intermediate program obtained before the rendering program is compiled into binary code. Since the intermediate representation is the intermediate result of compiling the source program, rather than the binary code associated with the hardware architecture, when obtaining program performance parameters and analyzing program performance bottlenecks, there is no need to consider the specific form of the underlying hardware architecture, nor is it limited by the hardware architecture.

[0088] In a possible implementation, during the running of the test program, according to the collection order of multiple feature collection levels, first obtain the program performance parameters of the rendering program at the draw call level, that is, the relevant parameters of each draw call command in the rendering program; then, for at least one shader corresponding to each draw call command, obtain the program performance parameters of the rendering program at the shader level, that is, the relevant parameters of each shader in the rendering program; then, for at least one basic block corresponding to each shader, obtain the program performance parameters of the rendering program at the basic block level, that is, the relevant parameters of each basic block in the rendering program; finally, for at least one instruction included in each basic block, obtain the program performance parameters of the rendering program at the instruction level, that is, the relevant parameters of each instruction.

[0089] It can be seen that the embodiment of the present application is aimed at a rendering program, and comprehensively analyzes the rendering program from different levels to obtain program performance parameters of the rendering program from different levels.

[0090] It should be noted that static analysis and dynamic instrumentation are different only in the analysis objects. Static analysis is performed on the source program or intermediate of the rendering program, while dynamic instrumentation analyzes the test program after the intermediate representation of the rendering program has been instrumented. However, the process of obtaining the program performance parameters of the rendering program at multiple feature collection levels is similar, so the static analysis process will not be elaborated here.

[0091] As an example, the program performance parameters of the rendering program at the draw call level include one or more of the number of draw call commands, the synchronization type of the draw call commands, the type and size of memory allocated by the draw call commands, the branch type and proportion of the draw call commands, and the execution time of the draw call commands; the program performance parameters of the rendering program at the shader level include the type and number of shaders; the program performance parameters of the rendering program at the basic block level include one or more of the number of basic blocks corresponding to each shader, the total number of basic blocks, the basic block branch flow graph (i.e., the loop mode of the basic block), the number of calls of the basic block, and the number of instructions of the basic block. one or more of the following: the program performance parameters of the rendering program at the instruction level include the maximum number of instructions in a basic block, the minimum number of instructions in a basic block, the average number of instructions in a basic block, the proportion of the number of executions of each instruction to the total dynamic executions, the instruction mix, the number of different types of instructions, the number of dynamic instructions per shader, the average number of executed instructions per thread cluster (also called warp or wavefront, usually each thread cluster includes 32 threads), the data dependency distance (i.e., the number of dynamic instructions executed within the interval from operand write operation to operand read operation), and the proportion of atomic operation instructions to the total dynamic execution instructions.

[0092] Optionally, since static analysis does not run the program, the program performance parameters obtained by static analysis and dynamic instrumentation may be slightly different. Therefore, in actual implementation, a combination of static analysis and dynamic instrumentation can be used to obtain the program performance parameters of the rendering program at multiple feature collection levels, and the obtained data can be merged, counted and analyzed.

[0093] As an example, static analysis is used to obtain the type and number of shaders, the size of basic blocks, the category of instructions, the number of instructions in each basic block, etc. in the rendering program; dynamic instrumentation is used to obtain the execution times of each basic block in the rendering program, the number of dynamic instructions, etc.

[0094] In some embodiments, the above-mentioned multiple feature collection levels also include a thread level, the collection order of the thread level is later than the shader level and earlier than the basic block level, the thread level includes multiple threads, and at least one basic block corresponding to the shader is executed in parallel by multiple threads.

[0095] That is, for each shader, at least one basic block corresponding to it can be executed by one thread or by multiple threads in parallel. When at least one basic block corresponding to a shader is executed in parallel by multiple threads, the embodiment of the present application can further collect program performance parameters when each shader is executed by multiple threads at the shader level.

[0096] As an example, the program performance parameters of the rendering program at the thread level include one or more of the thread execution path, thread execution efficiency, and GPU utilization, which is not limited in the embodiments of the present application.

[0097] Based on the above description, for ease of understanding, see Figure 2 , in the case where multiple feature collection levels include draw call level, shader level, thread level, basic block level and instruction level, the process of collecting program performance parameters by static analysis and dynamic instrumentation can be: Since API is the interface between the program and the operating system, hardware or other software services, they allow the application to request the operating system or other services to provide specific functions or resources. Therefore, during the running of the rendering program, the relevant parameters of each draw call command in the rendering program are intercepted and collected from the API layer. For the intercepted target draw call command, the drawing function provided by the API, such as the glShaderSource function of OpenGL or the PSSetShader function of the multimedia programming interface (direct extension, referred to as DX), etc., is used to load the written shader code into the corresponding shader object, and the test code is inserted into the intermediate representation of the rendering program to collect the relevant parameters during the running of the test program. Then, the type and number of at least one shader corresponding to the target draw call command, the basic block size, instruction category statistics, the number of instructions in the basic block, etc. are determined by static analysis; and the thread execution path, basic block execution times, dynamic instruction counts, etc. of multiple threads executing the shader code are obtained by dynamic analysis. Finally, the parameters obtained from static analysis and dynamic analysis are combined to obtain the program performance parameters of the rendering program at multiple feature collection levels.

[0098] Step 103: Determine the performance bottleneck of the rendering program based on the acquired program performance parameters.

[0099] Among them, the performance bottlenecks of the rendering program include program hotspots and insufficient memory resources, and may also include other factors that lead to low program running efficiency, which are not limited in the embodiments of the present application.

[0100] In an embodiment of the present application, when analyzing program hotspots of a rendering program, the program performance parameters that need to be collected include: the execution time of each drawing call command obtained at the drawing call level, the execution times of each shader obtained at the shader level, the call times of each basic block obtained at the basic block level, and the execution times of each instruction obtained at the instruction level. On this basis, if multiple feature collection levels include a thread level, the program performance parameters that need to be collected also include the execution path of each thread obtained at the thread level.

[0101] In other words, with respect to analyzing program hotspots of a rendering program, program performance parameters collected by the rendering program at a drawing call level include the execution time of a drawing call command, program performance parameters at a shader level include the number of shader executions, program performance parameters at a basic block level include the number of basic block calls, and program performance parameters at an instruction level include the number of instruction executions.

[0102] In a possible implementation, based on program performance parameters of the rendering program at multiple feature collection levels, the implementation process of determining the program hotspot of the rendering program may include the following steps (1)-(4).

[0103] (1) From multiple draw call commands, determine a target draw call command with the longest execution time.

[0104] The longer the execution time of the draw call command is, the higher the probability that the draw call command contains a program hotspot. Therefore, in the embodiment of the present application, for a rendering program, based on the execution time of multiple draw call commands, a target draw call command that may contain a program hotspot is first determined from the rendering program.

[0105] (2) Determine a target shader with the largest number of executions from at least one shader corresponding to the target draw call command.

[0106] Since the implementation of the target draw call command requires at least one shader, and the shader with the most execution times is the bottleneck for executing the target draw call command. Therefore, after determining the target draw call command, the embodiment of the present application can count the execution times of each shader in the at least one shader corresponding to the target draw call command, and determine the shader with the most execution times as the target shader. The program hotspot of the rendering program may exist in the target shader.

[0107] It can be seen that in the process of locating the target shader from the rendering program, the embodiment of the present application can utilize the execution time of each drawing call command to quickly determine the target shader from at least one shader corresponding to the target drawing call command without analyzing all shaders involved in the rendering program, thereby reducing the amount of data analysis and improving the efficiency of determining the target shader from the rendering program.

[0108] (3) From at least one basic block corresponding to the target shader, determine the target basic block with the most calls.

[0109] When the multiple feature collection levels do not include a thread level, for the target shader, it is necessary to count the number of calls of all basic blocks in the target shader in turn, and determine the basic block with the largest number of calls as the target basic block.

[0110] In the case where the multiple feature acquisition levels include a thread level, when determining the target basic block from at least one basic block corresponding to the target shader, the following two situations are included:

[0111] In the first case, if at least one basic block corresponding to the target shader is executed by a single thread, the call times of all basic blocks corresponding to the target shader are counted in turn, and the basic block with the largest number of calls is determined as the target basic block.

[0112] In the second case, if at least one basic block corresponding to the target shader is executed in parallel by multiple threads, the number of calls to the basic block in the thread can be estimated through the execution path of each thread. When the execution path of the thread is longer, the number of calls to the basic block executed by the thread will be more; when the execution path of the thread is shorter, the number of calls to the basic block executed by the thread will be relatively small. Based on this, the implementation process of determining the target basic block with the most calls can be: from multiple threads used to execute at least one basic block corresponding to the target shader, determine the target thread with the longest execution path; from the basic blocks executed by the target thread, determine the target basic block with the most calls.

[0113] It can be seen that when multiple threads execute the code of the target shader in parallel, the execution path of the thread can be used to quickly determine the target basic block from the target shader without analyzing all the basic blocks in the target shader, which reduces the amount of data analysis and improves the efficiency of determining the target basic block from the rendering program.

[0114] It should be understood that the basic block executed by the target thread is the basic block assigned to the target thread for execution in at least one basic block corresponding to the target shader. Among the multiple threads executing at least one basic block corresponding to the target shader, the basic blocks executed by each thread may be the same or different, and the embodiments of the present application do not limit this.

[0115] (4) Based on the target basic blocks, determine the program hotspots of the rendering program.

[0116] Among them, program hotspots include the instructions with the highest number of executions in the target basic block.

[0117] That is, after determining the target basic block, based on the execution times of each instruction in the target basic block, the instruction with the most execution times is used to determine the program hotspot. If there are multiple identical instructions in the target basic block, the execution times of the instruction are the total execution times of the instruction in the target basic block.

[0118] It can be seen that when determining the program hotspots of the rendering program, the embodiment of the present application can perform layer-by-layer analysis in the order of "drawing call level - shader level - thread level - basic block level - instruction level", and continuously narrow the analysis scope of the program hotspots, thereby quickly and effectively determining the program hotspots of the rendering program.

[0119] It should be noted that the above steps (1)-(4) are only explained by determining the program hotspots at the instruction level, and the granularity of analyzing the program hotspots is the finest. Of course, it is also possible to only execute the above steps (1)-(3) to determine the target basic block with the most calls from the basic block level. The target basic block is the program hotspot of the rendering program. Compared with the instruction level, the granularity of analyzing the program hotspot at the basic block level is coarser. Similarly, it is also possible to only execute the above steps (1) and (2) to determine the program hotspots from the shader level, or to only execute the above step (1) to determine the program hotspots from the drawing call level. The embodiments of the present application do not limit this.

[0120] In summary, for the rendering program, the embodiment of the present application sets multiple feature collection levels from coarse granularity to fine granularity in sequence. When performing performance testing on the rendering program, the program performance parameters of the rendering program at the multiple feature collection levels of the rendering program are obtained, thereby determining the performance bottleneck of the rendering program based on the program performance parameters at the multiple feature collection levels. In this way, the efficiency of determining the performance bottleneck of the rendering program is improved through hierarchical data collection and analysis.

[0121] In some embodiments, after determining the performance bottleneck of the rendering program, the computing device may also determine an optimization solution for the rendering program based on the performance bottleneck of the rendering program; and display the performance bottleneck of the rendering program and the optimization solution for the rendering program through the above-mentioned program test interface.

[0122] Among them, the optimization scheme includes a program optimization method of the rendering program and / or an optimization method of the hardware device that executes the rendering program; the program optimization method includes optimization methods corresponding to multiple feature collection levels.

[0123] It should be understood that based on the performance bottleneck and optimization scheme of the rendering program displayed on the program test interface, the user (referring to the user who uploaded the rendering program) can refer to the performance bottleneck and optimization scheme to optimize the rendering program to optimize the overall performance of the program. Of course, after the user optimizes the rendering program, the above steps 101-103 can also be executed in a loop to perform performance testing on the optimized program again. The embodiment of the present application does not limit the number of performance analysis times of the rendering program.

[0124] In a possible implementation, the program optimization method may include at least one of a draw call level optimization method, a shader level optimization method, and a basic block level optimization method. The methods for optimizing the rendering program at different levels are also different, and are introduced below.

[0125] The first program optimization method is to optimize the rendering program at the draw call level based on the execution time of each draw call command. When optimizing the rendering program at the draw call level, the optimization methods include but are not limited to:

[0126] (1) If the draw call involves a large amount of vertex data, consider whether the number of vertices can be reduced. For example, use a lower resolution model, reduce the level of detail of the drawing, or use techniques such as geometry merging to reduce the number of vertices in the draw call.

[0127] (2) The complexity of the shader may cause the execution time of the draw call command to be longer, so the shader code corresponding to the draw call command can be optimized to reduce the amount of calculation and avoid unnecessary texture sampling. For example, use a shader model suitable for the hardware, merge multiple shaders, etc.

[0128] (3) If a large number of texture maps are used for rendering, texture compression technology can be used to reduce memory and bandwidth consumption while ensuring that the size of these texture maps is appropriate; at the same time, texture collections can be used to reduce rendering calls.

[0129] (4) Combine multiple draw call commands into one batch to reduce the number of rendering calls.

[0130] (5) If lighting and shadow calculations take a lot of time, consider using a simpler lighting model, reducing the quality of shadows, or using techniques such as deferred rendering to improve the performance of draw call commands.

[0131] (6) Avoiding frequent GPU state switching may also lead to performance degradation. Therefore, try to render similar rendering objects together to reduce the frequency of GPU state switching.

[0132] (7) Use multi-threading or GPU instancing techniques to process multiple draw call commands in parallel to fully utilize the performance of multi-core processors.

[0133] (8) Optimize memory access patterns to reduce memory bandwidth usage; use object pools to reduce memory allocation and recycling overhead.

[0134] (9) Optimize for specific hardware platforms and use hardware features to improve performance. For example, use the GPU's shader cache to improve shader performance.

[0135] The second program optimization method is to optimize the rendering program at the shader level based on the number of executions of each shader. When optimizing the rendering program at the shader level, the optimization methods include but are not limited to:

[0136] (1) Review the shader code, try to reduce unnecessary calculations and operations, and optimize complex mathematical expressions.

[0137] (2) Reduce the number of texture sampling in the shader to avoid multiple texture sampling and try to merge sampling operations.

[0138] (3) Reduce complex conditional statements and branches in shaders to avoid GPU pipeline stalls.

[0139] (4) Reduce the number of loop iterations, or consider using techniques such as loop unrolling, using a simpler algorithm, or choosing a simpler and more efficient algorithm.

[0140] (5) If multiple draw call commands use similar shaders, you can consider merging them into a batch to reduce the number of shader switches.

[0141] (6) Use texture compression, texture arrays, texture caches and other technologies to reduce resource usage and ensure that the textures and resources used in the shader are efficient.

[0142] (7) Utilize the parallel processing capabilities of multi-core GPUs to execute shader code in parallel.

[0143] (8) Reduce the resolution of the rendering target to reduce the workload of the shader.

[0144] The third program optimization method is to determine the target thread with the longest execution path based on the execution path of each thread during the multi-threaded execution of the rendering program, and the basic block executed by the target thread is the longest branch in the basic block branch flow graph of the rendering program. Therefore, the rendering program can be optimized at the basic block level, and the optimization method includes but is not limited to: merging the basic blocks that generate branches to reduce the branches in the rendering program.

[0145] As an example, take the rendering program as a ray tracing reflections program, see Figure 3 The basic block branch flow chart of the ray tracing reflection program is shown. Each box represents a basic block, the number in the box is the ID of the basic block, the arrow indicates the execution direction of the basic block, and the number on the arrow indicates the number of times the basic block is executed in the execution direction. For example, basic block No. 182 is executed 1498.695k times in the direction pointing to basic block No. 186.

[0146] Therefore, based on Figure 3 In the basic block branch flow graph shown, when optimizing the ray tracing reflection program at the basic block level, you can try to merge the basic blocks that generate branches. For example, try to merge basic blocks 2097407 and 2097413, basic blocks 2097416 and 2097422, etc.

[0147] It should be noted that when merging the basic blocks that generate branches, the normal operation of the rendering program should not be affected, so as to avoid the situation where the rendering program cannot run normally after blindly merging the basic blocks.

[0148] In addition, by analyzing the proportion of various types of instructions at the instruction layer, the hardware device running the rendering program can be optimized based on the proportion of various types of instructions.

[0149] As an example, see Figure 4 The ray tracing pipeline called in the Vulkan (a cross-platform graphics application program interface) interface includes ray tracing textures program, ray tracing shadows program, ray tracing reflections program, ray tracing callable program and ray tracing basic program.

[0150] Among them, in the ray tracing texture program, composite instructions (i.e. composite instructions) accounted for 13.89%, load instructions (i.e. ld instructions) accounted for 28.87%, memory instructions (i.e. mem instructions) accounted for 19.18%, and storage instructions (i.e. st instructions) accounted for 13.63%; in the ray tracing shadow program, composite instructions accounted for 11.72%, ld instructions accounted for 28.35%, mem instructions accounted for 25.41%, and st instructions accounted for 13.16%; in the ray tracing reflection program, composite instructions accounted for 11.72%, ld instructions accounted for 28.35%, mem instructions accounted for 25.41%, and st instructions accounted for 13.16%. In the ray tracing callback program, composite instructions account for 20.99%, ld instructions account for 25.91%, mem instructions account for 19.71%, and st instructions account for 13.56%; in the ray tracing basic program, composite instructions account for 21.84%, ld instructions account for 25.27%, mem instructions account for 18.51%, and st instructions account for 13.72%.

[0151] It can be seen that the proportion of ld instructions and st instructions is relatively high, so you can try to optimize the hardware related to memory access.

[0152] It should be noted that Figure 4 Only the proportion of composite instructions, ld instructions, mem instructions and st instructions are marked in the figure. There are other instructions in the above five programs, such as atomic operation instructions (i.e. ato instructions), barrier instructions (i.e. barcount instructions), control flow instructions (i.e. cf instructions), comparison and selection instructions (i.e. cs instructions), floating point instructions (i.e. fp instructions), graphics instructions (i.e. image instructions), integer instructions (i.e. int instructions), logical operations and bit-level operation instructions (i.e. ls instructions), move and conversion instructions (i.e. mc instructions), other miscellaneous instructions (i.e. mi instructions), etc. These instructions also have a certain proportion. Figure 4 Not marked in.

[0153] To summarize, after using the above-mentioned program performance analysis method to determine the performance bottleneck of the rendering program, an optimization plan for the rendering program can be output based on the performance bottleneck to guide software developers to optimize the rendering program from multiple feature collection levels and improve the running efficiency of the rendering program; an optimization method for the hardware device can also be output to optimize the hardware device running the rendering program and improve the overall running performance of the rendering program.

[0154] See also Figure 5 , Figure 51 is a schematic diagram of a program performance analysis device provided in an embodiment of the present application. The program performance analysis device 500 can be implemented as part or all of a computing device by software, hardware or a combination of both. The program performance analysis device 500 includes: a program acquisition module 501, a parameter acquisition module 502 and a performance analysis module 503.

[0155] A program acquisition module 501 is used to provide a program test interface, and the program test interface is used to acquire a rendering program to be tested;

[0156] A parameter acquisition module 502 is used to acquire program performance parameters of a rendering program at multiple feature collection levels of the rendering program, wherein the multiple feature collection levels include one or more of the following: a draw call level, a shader level, a basic block level, and an instruction level;

[0157] A performance analysis module 503, used to determine the performance bottleneck of the rendering program based on the acquired program performance parameters;

[0158] The draw call level includes multiple draw call commands, the shader level includes multiple shaders, the basic block level includes multiple basic blocks, the instruction level includes multiple instructions, and the draw call command corresponds to at least one shader, the shader corresponds to at least one basic block, and the basic block includes at least one instruction.

[0159] Optionally, the parameter acquisition module 502 includes:

[0160] A program processing unit, used for inserting a test code into an intermediate representation of a rendering program to obtain a test program, wherein the intermediate representation refers to an intermediate program obtained before the rendering program is compiled into a binary code;

[0161] The parameter collection unit is used to obtain the program performance parameters of the rendering program at multiple feature collection levels in sequence during the running of the test program according to the collection order of multiple feature collection levels; wherein the collection order of the draw call level is earlier than that of the shader level, the collection order of the shader level is earlier than that of the basic block level, and the collection order of the basic block level is earlier than that of the instruction level.

[0162] Optionally, the program performance parameters of the rendering program at the drawing call level include the execution time of the drawing call command, the program performance parameters of the rendering program at the shader level include the number of shader executions, the program performance parameters of the rendering program at the basic block level include the number of basic block calls, and the program performance parameters of the rendering program at the instruction level include the number of instruction executions.

[0163] Optionally, the performance bottleneck of the rendering program includes program hotspots; the performance analysis module 503 includes:

[0164] A first analyzing unit is used to determine a target draw call command with the longest execution time from the multiple draw call commands;

[0165] A second analysis unit is used to determine a target shader with the largest number of execution times from at least one shader corresponding to the target draw call command;

[0166] A third analysis unit is used to determine a target basic block with the largest number of calls from at least one basic block corresponding to the target shader;

[0167] The fourth analysis unit is used to determine a program hotspot of the rendering program based on the target basic block, where the program hotspot includes instructions with the highest number of execution times in the target basic block.

[0168] Optionally, the multiple feature acquisition levels also include a thread level, the acquisition order of the thread level is later than the shader level and earlier than the basic block level, the thread level includes multiple threads, and at least one basic block corresponding to the shader is executed in parallel by multiple threads.

[0169] Optionally, the program performance parameters of the rendering program at the thread level include the execution path of the thread; the third analysis unit is specifically used to:

[0170] Determine a target thread having the longest execution path from among a plurality of threads for executing at least one basic block corresponding to the target shader;

[0171] A target basic block with the largest number of calls is determined from the basic blocks executed by the target thread, wherein the basic block executed by the target thread is a basic block allocated to the target thread for execution in at least one basic block corresponding to the target shader.

[0172] Optionally, the program performance analysis device 500 further includes:

[0173] A determination module is used to determine an optimization scheme for the rendering program based on the performance bottleneck of the rendering program, wherein the optimization scheme includes a program optimization method for the rendering program and / or an optimization method for a hardware device that executes the rendering program; wherein the program optimization method includes optimization methods corresponding to a plurality of feature collection levels respectively;

[0174] The display module is used to display the performance bottleneck of the rendering program and the optimization plan of the rendering program through the program test interface.

[0175] In the embodiment of the present application, for the rendering program, the embodiment of the present application sequentially sets multiple feature collection levels from coarse granularity to fine granularity. When the program performance analysis device performs performance testing on the rendering program, the program performance parameters of the rendering program at the multiple feature collection levels of the rendering program are sequentially obtained, thereby determining the performance bottleneck of the rendering program based on the program performance parameters at the multiple feature collection levels. In this way, the efficiency of determining the performance bottleneck of the rendering program is improved through hierarchical data collection and analysis.

[0176] The program performance analysis device provided in the above embodiment only uses the division of the above functional modules as an example when performing performance analysis on the rendering program to determine its performance bottleneck. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the program performance analysis device provided in the above embodiment and the program performance analysis method embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0177] In the above Figure 5 In the program performance analysis device shown, the program acquisition module, the parameter acquisition module and the performance analysis module can all be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the performance analysis module is introduced below by taking the performance analysis module as an example. Similarly, the implementation of the program acquisition module and the parameter acquisition module can refer to the implementation of the performance analysis module.

[0178] As an example of a software functional unit, a performance analysis module may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the above-mentioned computing instance may be one or more. For example, the performance analysis module may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with similar geographical locations. Among them, usually a region may include multiple AZs.

[0179] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0180] As an example of a hardware functional unit, the performance analysis module may include at least one computing device, such as a server, etc. Alternatively, the performance analysis module may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0181] The multiple computing devices included in the performance analysis module can be distributed in the same region or in different regions. The multiple computing devices included in the performance analysis module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the performance analysis module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0182] It should be noted that, in other embodiments, the performance analysis module can be used to execute any step in the program performance analysis method, the program acquisition module can be used to execute any step in the program performance analysis method, and the parameter acquisition module can be used to execute any step in the program performance analysis method. That is, the steps that the program acquisition module, parameter acquisition module and performance analysis module are responsible for implementing can be specified as needed, and the full functions of the program performance analysis device are realized by respectively implementing different steps in the program performance analysis method through the program acquisition module, parameter acquisition module and performance analysis module.

[0183] The present application embodiment also provides a computing device 100. Figure 6As shown, the computing device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate through the bus 102. The computing device 100 can be a server or a terminal device. It should be understood that the embodiment of the present application does not limit the number of processors and memories in the computing device 100.

[0184] The bus 102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The bus 104 is represented by only one line, but does not mean that there is only one bus or one type of bus. The bus 104 may include a path for transmitting information between various components of the computing device 100 (eg, the memory 106, the processor 104, and the communication interface 108).

[0185] The processor 104 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0186] The memory 106 may include a volatile memory, such as a random access memory (RAM). The processor 104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0187] The memory 106 stores executable program codes, and the processor 104 executes the executable program codes to respectively implement the functions of the aforementioned program acquisition module, parameter acquisition module, and performance analysis module, thereby implementing the program performance analysis method. That is, the memory 106 stores instructions for executing the program performance analysis method.

[0188] The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0189] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0190] like Figure 7 As shown, the computing device cluster includes at least one computing device 100. The memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the program performance analysis method.

[0191] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the program performance analysis method. In other words, the combination of one or more computing devices 100 may jointly execute instructions for executing the program performance analysis method.

[0192] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the program performance analysis device. That is, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more modules among the program acquisition module, the parameter acquisition module and the performance analysis module.

[0193] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Figure 8 A possible implementation is shown. Figure 8 As shown, two computing devices 100A and 100B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the functions of the program acquisition module and the parameter acquisition module. At the same time, the memory 106 in the computing device 100B stores instructions for executing the functions of the performance analysis module.

[0194] Figure 8The connection method between the computing device clusters shown may be based on the consideration that the program performance analysis method provided in the present application requires the collection of a large number of program performance parameters and the processing of a large number of program performance parameters, and therefore it is considered that the functions implemented by the performance analysis module are handed over to the computing device 100B for execution.

[0195] It should be understood that Figure 8 The functions of the computing device 100A shown in FIG. 1 may also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 100.

[0196] The present application embodiment also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to that of Figure 7 and Figure 8 The connection mode of the computing device cluster is different in that the memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the program performance analysis method.

[0197] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the program performance analysis method. In other words, the combination of one or more computing devices 100 may jointly execute instructions for executing the program performance analysis method.

[0198] The present application also provides a computer program product including instructions. The computer program product may be a software or program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above Figure 1 The program performance analysis method shown.

[0199] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above Figure 1 The program performance analysis method shown.

[0200] It should be understood that the "multiple" mentioned herein refers to two or more. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit them to be necessarily different.

[0201] 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, stored data, displayed data, etc.) and signals involved in the embodiments of the present application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0202] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A program performance analysis method, characterized in that: The method comprises: Providing a program testing interface, wherein the program testing interface is used to obtain a rendering program to be tested; Obtaining program performance parameters of the rendering program at multiple feature collection levels, respectively, wherein the multiple feature collection levels include one or more of the following: a draw call level, a shader level, a basic block level, and an instruction level; Determining the performance bottleneck of the rendering program based on the acquired program performance parameters; The draw call level includes multiple draw call commands, the shader level includes multiple shaders, the basic block level includes multiple basic blocks, the instruction level includes multiple instructions, and the draw call command corresponds to at least one of the shaders, the shader corresponds to at least one of the basic blocks, and the basic block includes at least one of the instructions.

2. The method according to claim 1, characterized in that The obtaining of program performance parameters of the rendering program at multiple feature collection levels includes: Inserting a test code into an intermediate representation of the rendering program to obtain a test program, wherein the intermediate representation refers to an intermediate program obtained before the rendering program is compiled into binary code; During the running of the test program, program performance parameters of the rendering program at the multiple feature collection levels are acquired in sequence according to the collection order of the multiple feature collection levels; wherein the collection order of the draw call level is earlier than that of the shader level, the collection order of the shader level is earlier than that of the basic block level, and the collection order of the basic block level is earlier than that of the instruction level.

3. The method according to claim 1 or 2, characterized in that The program performance parameters of the rendering program at the drawing call level include the execution time of the drawing call command, the program performance parameters of the rendering program at the shader level include the number of executions of the shader, the program performance parameters of the rendering program at the basic block level include the number of calls of the basic block, and the program performance parameters of the rendering program at the instruction level include the number of executions of the instruction.

4. The method according to claim 3, characterized in that The performance bottleneck of the rendering program includes a program hotspot; and determining the performance bottleneck of the rendering program based on the acquired program performance parameters includes: Determine, from the plurality of draw call commands, a target draw call command with the longest execution time; Determine, from the at least one shader corresponding to the target draw call command, a target shader having the largest number of execution times; Determine, from the at least one basic block corresponding to the target shader, a target basic block with the largest number of calls; Based on the target basic block, a program hotspot of the rendering program is determined, wherein the program hotspot includes instructions with the highest number of execution times in the target basic block.

5. The method according to claim 4, characterized in that The multiple feature collection levels also include a thread level, the collection order of the thread level is later than the shader level and earlier than the basic block level, the thread level includes multiple threads, and at least one basic block corresponding to the shader is executed in parallel by multiple threads.

6. The method according to claim 5, characterized in that The program performance parameter of the rendering program at the thread level includes the execution path of the thread; and determining the target basic block with the most calls from at least one basic block corresponding to the target shader includes: Determine a target thread having the longest execution path from among a plurality of threads for executing at least one basic block corresponding to the target shader; The target basic block with the largest number of calls is determined from the basic blocks executed by the target thread, wherein the basic block executed by the target thread is a basic block allocated to the target thread for execution in at least one basic block corresponding to the target shader.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: Based on the performance bottleneck of the rendering program, determining an optimization scheme for the rendering program, wherein the optimization scheme includes a program optimization method for the rendering program and / or an optimization method for a hardware device that executes the rendering program; wherein the program optimization method includes optimization methods corresponding to the multiple feature collection levels respectively; The program testing interface displays the performance bottleneck of the rendering program and the optimization scheme of the rendering program.

8. A program performance analysis device, characterized in that: The device comprises: A program acquisition module, used for providing a program testing interface, wherein the program testing interface is used for acquiring a rendering program to be tested; A parameter acquisition module, used to acquire program performance parameters of the rendering program at multiple feature collection levels, wherein the multiple feature collection levels include one or more of the following: a draw call level, a shader level, a basic block level, and an instruction level; A performance analysis module, used to determine the performance bottleneck of the rendering program based on the acquired program performance parameters; The draw call level includes multiple draw call commands, the shader level includes multiple shaders, the basic block level includes multiple basic blocks, the instruction level includes multiple instructions, and the draw call command corresponds to at least one of the shaders, the shader corresponds to at least one of the basic blocks, and the basic block includes at least one of the instructions.

9. The device according to claim 8, characterized in that The parameter acquisition module includes: A program processing unit, configured to insert a test code into an intermediate representation of the rendering program to obtain a test program, wherein the intermediate representation refers to an intermediate program obtained before the rendering program is compiled into binary code; A parameter collection unit is used to obtain, during the running of the test program, program performance parameters of the rendering program at the multiple feature collection levels in sequence according to the collection order of the multiple feature collection levels; wherein the collection order of the draw call level is earlier than that of the shader level, the collection order of the shader level is earlier than that of the basic block level, and the collection order of the basic block level is earlier than that of the instruction level.

10. The device according to claim 8 or 9, characterized in that The program performance parameters of the rendering program at the drawing call level include the execution time of the drawing call command, the program performance parameters of the rendering program at the shader level include the number of executions of the shader, the program performance parameters of the rendering program at the basic block level include the number of calls of the basic block, and the program performance parameters of the rendering program at the instruction level include the number of executions of the instruction.

11. The device according to claim 10, characterized in that The performance bottleneck of the rendering program includes program hot spots; The performance analysis module comprises: A first analyzing unit is configured to determine a target draw call command having the longest execution time from among the plurality of draw call commands; A second analysis unit is used to determine a target shader with the largest number of execution times from at least one shader corresponding to the target draw call command; A third analysis unit is used to determine a target basic block with the largest number of calls from at least one basic block corresponding to the target shader; The fourth analysis unit is used to determine a program hotspot of the rendering program based on the target basic block, where the program hotspot includes instructions with the highest number of execution times in the target basic block.

12. The device according to claim 11, characterized in that The multiple feature collection levels also include a thread level, the collection order of the thread level is later than the shader level and earlier than the basic block level, the thread level includes multiple threads, and at least one basic block corresponding to the shader is executed in parallel by multiple threads.

13. The device according to claim 12, characterized in that The program performance parameters of the rendering program at the thread level include the execution path of the thread; the third analysis unit is specifically used to: Determine a target thread having the longest execution path from among a plurality of threads for executing at least one basic block corresponding to the target shader; The target basic block with the largest number of calls is determined from the basic blocks executed by the target thread, wherein the basic block executed by the target thread is a basic block allocated to the target thread for execution in at least one basic block corresponding to the target shader.

14. The device according to any one of claims 8 to 13, characterized in that The device also includes: A determination module, configured to determine an optimization scheme for the rendering program based on a performance bottleneck of the rendering program, wherein the optimization scheme includes a program optimization method for the rendering program and / or an optimization method for a hardware device that executes the rendering program; wherein the program optimization method includes optimization methods corresponding to the multiple feature collection levels respectively; The display module is used to display the performance bottleneck of the rendering program and the optimization solution of the rendering program through the program testing interface.

15. A computing device cluster, the computing device cluster comprising at least one computing device, each of the computing devices comprising a processor and a memory; The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the program performance analysis method according to any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the program performance analysis method according to any one of claims 1 to 7.

17. A computer program product comprising instructions, characterized in that When the instruction is executed by a computing device cluster, the computing device cluster executes the program performance analysis method according to any one of claims 1 to 7.

Images