A performance parameter calculation method of a virtual GPU, a related device, and a storage medium

Abstract

The application relates to the computer technical field and discloses a performance parameter calculation method of a virtual GPU, related equipment and a storage medium. The method comprises the following steps: determining an original performance parameter of a target module in the virtual GPU, wherein the original performance parameter is used for reflecting the running state of the virtual GPU related to the target module, and the target module is obtained by performing module division on the virtual GPU according to common features of different GPUs; and performing derivative calculation on the original performance parameter to obtain a derivative performance parameter of the virtual GPU, wherein the derivative performance parameter is used for reflecting the device performance of the virtual GPU. By adopting the embodiments of the application, the technical problems that the collection of the existing GPU performance parameters is limited and the universality is poor can be solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method for calculating the performance parameters of a virtual GPU, related equipment, and storage medium. Background Technology

[0002] Many existing GPU performance analysis tools, such as AGI (Android Graphics Interceptor), AMS (Arm Mobile Studio), and Snapdragon Profilerder, rely on their respective performance counters to collect GPU performance parameters. These performance counters often differ significantly, making it difficult for different tools to interpret each other's counters. This results in limited and poorly universal GPU performance parameter collection. Summary of the Invention

[0003] This application discloses a method for calculating the performance parameters of a virtual GPU, related equipment, and storage medium, in order to solve the technical problems of limited collection and comparison of existing GPU performance parameters and poor universality.

[0004] Firstly, a method for calculating the performance parameters of a virtual GPU is provided, the method comprising: The original performance parameters of the target module in the virtual GPU are determined. The original performance parameters are used to reflect the running status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on the common characteristics of different GPUs. The original performance parameters are used to perform derivative calculations to obtain the derived performance parameters of the virtual GPU, which are used to reflect the device performance of the virtual GPU.

[0005] Secondly, a device for calculating the performance parameters of a virtual GPU is provided, comprising a determining unit and a computing unit, wherein: The determining unit is used to determine the original performance parameters of the target module in the virtual GPU. The original performance parameters are used to reflect the operating status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on the common characteristics of different GPUs. The computing unit is used to perform derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU, which are used to reflect the device performance of the virtual GPU.

[0006] Thirdly, a virtual GPU performance counter is provided, including: Memory containing executable program code; A graphics processing unit (GPU) coupled to the memory; The GPU calls the executable program code stored in the memory to execute the method provided in the first aspect above.

[0007] Fourthly, an electronic device is provided, comprising: processor; Graphics Processing Unit (GPU); A memory coupled together with or separately to the processor and the GPU is used to store executable code programs; The GPU calls the executable program code stored in the memory to execute the method provided in the first aspect above.

[0008] Fifthly, a computer-readable storage medium is provided that stores a computer program, wherein the computer program causes a computer to perform the method provided in the first aspect above.

[0009] Compared with the prior art, the embodiments of this application have the following beneficial effects: In this embodiment, a virtual GPU performance counter determines the original performance parameters of a target module within the virtual GPU. These original performance parameters reflect the operating status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on the common characteristics of different GPUs. Derivative calculations are then performed on the original performance parameters to obtain derived performance parameters of the virtual GPU, which reflect the device performance of the virtual GPU. By employing this approach, highly generalizable derived performance parameters can be calculated based on the original performance parameters of the target module within the virtual GPU, thus more significantly reflecting the device performance of the virtual GPU. This solves the technical problems of limited collection and poor universality of GPU performance parameters in existing technologies. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the structure of a virtual GPU performance counter provided in an embodiment of this application.

[0012] Figure 2This is a schematic diagram of another virtual GPU performance counter provided in an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of another virtual GPU performance counter provided in an embodiment of this application.

[0014] Figure 4 This is a schematic diagram of another virtual GPU performance counter provided in an embodiment of this application.

[0015] Figure 5 This is a flowchart illustrating a method for calculating the performance parameters of a virtual GPU provided in an embodiment of this application.

[0016] Figure 6 This is a schematic diagram of the structure of a virtual GPU performance parameter calculation device provided in an embodiment of this application.

[0017] Figure 7 This is a schematic diagram of another virtual GPU performance counter provided in an embodiment of this application.

[0018] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] In the process of filing this application, the applicant also discovered that existing GPU performance analysis tools require GPU performance counters to collect GPU performance parameters, and their implementation requires both hardware support and software driver cooperation. For example, the performance counters used by AGI derive their data from the Android analytics framework Perfetto, and GPU manufacturers must explicitly support this framework for it to be used. The performance counters used by AMS are driven by a software driver called gator, which operates in kernel space. The user-space daemon gatord reads gator information and communicates with the AMS host software, etc.

[0021] GPU performance analysis tools (or GPU manufacturers) design corresponding performance counters based on the hardware characteristics of their own GPUs. Due to the different hardware designs of different GPUs, their corresponding performance counters vary greatly. This means that the performance counters used by different tools often differ significantly. For example, the AMS tool has difficulty parsing the performance counters of Android Adreno GPUs, and the Qualcomm Snapdragon Profilerder tool cannot parse the performance counters of ARM GPUs. Furthermore, many tools (such as AGI) can only display their raw performance counters in practical applications, failing to provide in-depth performance analysis.

[0022] Taking the Mali G710 GPU performance counter as an example, this performance counter is typically divided into four parts: the Command Stream Frontend (CSF), the internal bus (denoted as Memory), the Shader Core, and the Tiler. Among these, the Command Stream Frontend, Shader, and Tiler are strongly hardware-dependent, and other GPUs may not have similar functionalities. This results in the poor universality of GPU performance counters.

[0023] To address the aforementioned issues, this application proposes to functionally divide the virtual GPU performance counter (which may specifically be the corresponding virtual GPU) based on the common characteristics of different GPUs. For example, it may divide the function based on the common characteristics of the unified shading model and the block architecture of mobile GPUs, thereby proposing a virtual GPU performance counter or virtual GPU with strong universality.

[0024] Please see Figure 1 This is a schematic diagram of the structure of a virtual GPU performance counter provided in an embodiment of this application. Figure 1 The virtual GPU performance counters shown may include: a front-end processing module 100, a geometry pipeline module 200, a fragment pipeline module 300, a shader module 400, a back-end processing module 500, and a communication bus 600. The front-end processing module 100, the geometry pipeline module 200, the fragment pipeline module 300, the shader module 400, and the back-end processing module 500 can communicate with each other via the communication bus 600.

[0025] The front-end processing module 100 is responsible for scheduling and processing all pending tasks within the virtual GPU, as well as scheduling its own internal hardware units. Based on the different task objects, the front-end processing module 100 can be divided into computation tasks, vertex tasks, and fragment tasks. When there are multiple tasks, they can be arranged in a queue. Within the front-end processing module 100, a compute queue 101, a vertex queue 102, and a fragment queue 103 can be formed, which are used to process computation tasks, vertex tasks, and fragment tasks, respectively. See details... Figure 2 A schematic diagram of another virtual GPU performance counter is shown.

[0026] Please see also Figure 3 This is a schematic diagram of a virtual GPU performance counter labeled with GPU performance parameters provided in an embodiment of this application. For example... Figure 3 In the process, the GPU performance parameters (also referred to as raw performance parameters) involved in the front-end processing module 100 include, but are not limited to, any one or more GPU performance parameters in the performance parameter table shown in Table 1 below.

[0027] Table 1

[0028] The geometry pipeline module 200 is responsible for data processing during the geometry phase. This geometry pipeline module 200 can be simplified as follows: Figure 2 The diagram shows clipping unit 201, culling unit 202, viewport transformation unit 203, and tile unit 204. Wherein: The clipping unit 201 is responsible for clipping operations in GPU rendering, which may include, but are not limited to, view frustum clipping, view volume clipping, viewport clipping, or occlusion clipping. View frustum clipping can be used to define the 3D image to be rendered, i.e., which part of the 3D scene will be used to create the 2D image in GPU rendering. View volume clipping or viewport clipping can be performed in the geometry stage, by projecting onto a homogeneous clipping space to clip triangles that extend beyond the viewport.

[0029] The culling unit 202 is responsible for culling operations in GPU rendering, including but not limited to frustum culling, occlusion culling, viewport culling, and backface culling. Frustum culling primarily excludes objects outside the visible range from rendering based on the camera's field of view, the distance between the near and far clipping planes, and these culled objects will not enter the geometry stage of rendering. Occlusion culling can remove invisible objects. Viewport culling can occur later in the geometry stage, reducing the overhead of the rasterization stage by culling primitives outside the viewport. Backface culling removes primitives facing away from the viewpoint to eliminate primitives that do not contribute to rendering.

[0030] The viewport transformation 203 is responsible for screen mapping, such as transforming vertex coordinates or primitive coordinates to screen space. Considering rendering power consumption, the block unit 204 adopts a block rendering method to implement GPU rendering, such as dividing the image to be rendered into several blocks for parallel rendering.

[0031] Combination Figure 3 The virtual GPU counter shown, the GPU performance parameters (also referred to as raw performance parameters) involved in the geometry pipeline module 200 include, but are not limited to, any one or more GPU performance parameters in the performance parameter table shown in Table 2 below.

[0032] Table 2

[0033] The fragment pipeline module 300 is responsible for data processing at the fragment stage. This fragment pipeline module 300 can be simplified as follows: Figure 2 The diagram shows a rasterization unit 301, an early depth testing unit 302 (Early ZS), and a hidden surface removal (HSR) unit 303. Wherein: The rasterization unit 301 is responsible for rasterization processing, specifically the pixelation of vector information. This involves transforming a primitive into a two-dimensional image. Each point (pixel) in this two-dimensional image includes color, depth, and texture data; this point and its related information can be called a fragment. The early depth testing unit 302 increases the fragment culling rate to effectively reject occluded fragments. The hidden surface removal unit 303 is responsible for removing unwanted pixels, such as deleting backface hidden surfaces facing away from the viewpoint. Both the early depth testing unit 302 and the hidden surface removal unit 303 aim to filter out useless pixels as early as possible, reducing the workload of the fragment shader.

[0034] Combination Figure 3The virtual GPU counter shown, the GPU performance parameters (also referred to as raw performance parameters) involved in the fragment pipeline module 300 include, but are not limited to, any one or more GPU performance parameters in the performance parameter table shown in Table 3 below.

[0035] Table 3

[0036] The shader module 400 is an abstraction of the programmable pipeline, running all shaders within a unified framework. The shader module 400 includes, but is not limited to, vertex shaders, fragment shaders, and compute shaders. Each shader uses its corresponding target shading thread for its respective shading processing. For example, the vertex shader uses a vertex shading thread, the fragment shader uses a fragment shading thread, and the compute shader uses a compute shading thread. In practical applications, the input to the vertex shader is vertex data, which is used to process the vertex data of each primitive, such as viewpoint transformation. The fragment shader is used to perform shading operations on each fragment to assign the correct color to each pixel, etc. The compute shader is used to perform parallel computations of data, etc.

[0037] Combination Figure 3 The virtual GPU counter shown, the GPU performance parameters (also referred to as raw performance parameters) involved in the shader module 400 include, but are not limited to, any one or more GPU performance parameters in the performance parameter table shown in Table 4 below.

[0038] Table 4

[0039] The back-end processing module 500 is responsible for post-processing, which can be simplified as follows: Figure 2 The diagram shows a late-stage depth testing unit 501 (Late ZS), a blending unit 502 (Blending), a tile difference calculation unit 503 (Tile Diff, also known as a tile difference calculator), and a framebuffer compression unit 504 (Framebuffer Compression, also known as a framebuffer compressor). Among these: The post-deep testing unit 501 performs depth stencil testing after the fragment shader, responsible for eliminating occluded fragments to reduce fragment shading load. The blending unit 502 is responsible for color blending, merging previously rendered color information to output the final pixel color. The tile difference calculation unit 503 compares the differences between the same tile in two adjacent frames; when differences exist, it writes the tile from the on-chip buffer to the frame buffer. The frame buffer operation unit 504 compresses the frame image before writing it to the frame buffer to significantly reduce memory bandwidth, and performs frame buffer writing operations, etc.

[0040] Combination Figure 3 The virtual GPU counter shown, and the GPU performance parameters (also referred to as raw performance parameters) involved in the back-end processing module 500, include, but are not limited to, any one or more GPU performance parameters in the performance parameter table shown in Table 5 below.

[0041] Table 5

[0042] The communication bus 600 may be an internal bus of the virtual GPU, which may include, but is not limited to, a Peripheral Component Interconnect (PCI) bus, an NVLink bus, or other GPU internal buses.

[0043] Combination Figure 3 The virtual GPU counter shown, and the GPU performance parameters (also referred to as raw performance parameters) associated with the communication bus 600, include, but are not limited to, any one or more GPU performance parameters in the performance parameter table shown in Table 6 below.

[0044] Table 6

[0045] It should be noted that the virtual GPU performance counters shown above in this application are merely examples and do not constitute a limitation. In practical applications, the virtual GPU performance counters can be divided according to the actual hardware framework and software functional modules. For example, the virtual GPU performance counters may also include texture units, which are responsible for texture mapping and texturing of polygons generated from vertices, thereby generating realistic images, etc., which will not be described in detail here.

[0046] The functionality of the virtual GPU counter is explained below with specific examples. Please refer to [link / reference]. Figure 4 This is a schematic diagram of another virtual GPU counter provided in an embodiment of this application. Figure 4Taking the GPU logical pipeline defined by the Vulkan Application Programming Interface (API) as an example, the central processing unit (CPU) of an electronic device initiates drawing commands or dispatch commands, which are then converted into hardware instructions by the driver to drive the virtual GPU. This application, considering the common characteristics of mobile GPUs, divides the GPU rendering process into six parts, as shown in the figure: front-end processing module 100, geometry pipeline module 200, fragment pipeline module 300, shader module 400, back-end processing module 500, and communication bus 600. Each part / module executes a corresponding stage or process in the GPU rendering flow. For example... Figure 4 The GPU rendering process shown includes: Input Assembly 401 is located in the front-end processing module 100. Input Assembly 401 assembles vertex data according to the input layout, for example, assembling vertices into primitives according to primitive type and index.

[0047] Vertex Shader 402 is located in the shader module 400. This vertex shader 402 belongs to the programmable pipeline stage and is responsible for storing several related material data for each vertex, such as vertex position, normal, or other digital information related to shading calculations.

[0048] The Tessellation Control Shader 403 is located in the shader module 400. This Tessellation Control Shader 403 belongs to the programmable pipeline stage. During the tessellation surface initiation stage, the primitive assembly mode needs to be set to control point blocks. The Tessellation Control Shader 403 is responsible for calculating the surface tessellation factor and, according to actual needs, changing the coordinates of any control point in the control point block to increase the number of control points.

[0049] Tessellation Primitive Generation 404, located in the geometry pipeline module 200, is a fixed-function stage. Tessellation Primitive Generation 404 is responsible for subdividing the surface based on the surface subdivision factor and control points, and outputting new vertices.

[0050] The Tessellation Evaluation Shader 405, located in the shader module 400, belongs to the programmable pipeline stage. The Tessellation Evaluation Shader 405 is responsible for interpolating the attributes of new vertices based on the attributes of the control points and outputting the modified new vertices.

[0051] The Geometry Shader 406, located in the shader module 400, belongs to the programmable pipeline stage. The Geometry Shader 406 can transform one primitive into another, for example, expanding a point primitive into a triangle primitive.

[0052] Vertex Post Processing 407, located in the geometry pipeline module 200, is a fixed-function stage. Vertex Post Processing 407 is responsible for post-processing the vertices of primitives, such as transforming them into new vertices.

[0053] Rasterization 408, located in the fragment pipeline module 300, is a fixed-function stage. Rasterization 408 is responsible for processing the primitives from the geometric stage into pixel images, specifically converting them into a series of fragments. Each fragment can be understood as a data structure that includes information such as position, color, and depth.

[0054] Early Fragment Tests 409, located in the fragment pipeline module 300, is a fixed function phase. Early Fragment Tests 409 is responsible for early fragment testing to eliminate useless fragments and reduce fragment shading load.

[0055] Fragment Shader 410, located in the shader module 400, belongs to the programmable pipeline stage. Fragment Shader 410, also known as pixel shader, is applied to each fragment to determine the fragment data written in each framebuffer (or frame buffer), such as the fragment's color and depth values.

[0056] Late Per-Fragment Tests 411, located in the backend processing module 500, is a fixed function stage. Late Per-Fragment Tests 411 is responsible for testing fragments in the later stages and removing occluded fragments.

[0057] Blending (412), located in the back-end processing module 500, is a fixed function stage. Blending (412) is responsible for merging pixel color information and outputting the final pixel color / color. It also writes the obtained pixel color data into the frame buffer.

[0058] The GPU internal bus 413 (Memory) is responsible for data communication between the front-end processing module 100, the geometry pipeline module 200, the fragment pipeline module 300, the shader module 400, and the back-end processing module 500. For a description of the front-end processing module 100, the geometry pipeline module 200, the fragment pipeline module 300, the shader module 400, the back-end processing module 500, and the GPU internal bus 413 in this application, please refer to the foregoing descriptions. Figure 1 The relevant descriptions in the embodiments will not be repeated here.

[0059] As can be seen from the above embodiments, the data processing flow in GPU rendering is top-down, from the top-level central processing unit (CPU) -> front-end -> ... -> back-end, representing the logical execution order of tasks. In practical applications, the data processing flow is extremely complex due to parallelism, data dependencies, task dependencies, scheduling, etc. For example, the geometry pipeline module and the fragment pipeline module are usually parallel, and vertex processing and fragment processing within the shader module may originate from different tasks in the front-end module. To better evaluate the device performance of the virtual GPU counter, this application can calculate corresponding derived performance parameters based on the original performance parameters of these functional modules, so as to more intuitively and universally characterize / reflect the device performance of the virtual GPU.

[0060] Based on the above embodiments, please refer to Figure 5 This is a flowchart illustrating a method for calculating the performance parameters of a virtual GPU according to an embodiment of this application. Figure 5 The method shown is applied to the virtual GPU performance counter described in the foregoing embodiments, and the method includes the following implementation steps: S501. Determine the original performance parameters of the target module in the virtual GPU. The original performance parameters are used to reflect the operating status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on the common characteristics of different GPUs.

[0061] The target module described in this application is a module division of the virtual GPU based on the common characteristics of different GPUs. For example, it can be based on the existence of hardware modules similar to block dividers in GPU block architectures, or on the unified shading model of mobile GPUs. For example, please refer to the above... Figure 1 The target module described in this application includes, but is not limited to, those described above. Figure 1 The module includes a front-end processing module 100, a geometry pipeline module 200, a fragment pipeline module 300, a shader module 400, and a back-end processing module 500.

[0062] Different target modules correspond to different raw performance parameters, which reflect the operating status of the target module or the virtual GPU where the target module resides. For a description of these raw performance parameters, please refer to the relevant descriptions in Tables 1-6 above; they will not be repeated here.

[0063] S502. Perform derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU. The derived performance parameters are used to reflect the device performance of the virtual GPU.

[0064] In practical applications, the original performance parameters mentioned in this application can generally be obtained by counting from the indicators supported by the virtual GPU hardware, or by calculating through preset rules, and most of them are absolute values. The derived performance parameters, on the other hand, generally refer to ratios, which are derived from the original performance parameters collected by the original calculator, for example, by using a preset derived calculation formula. The derived calculation formula is a system-defined calculation rule, and this application does not limit its scope.

[0065] In one possible implementation, the target module includes a front-end processing module for instructing the processing of tasks to be processed within the virtual GPU. The number and type of tasks to be processed are not limited and can be determined according to actual needs; for example, the tasks to be processed can be vertex tasks, fragment tasks, or computation tasks. As shown in Table 1 above, the raw performance parameters of the front-end processing module include, but are not limited to, clock cycles when there are tasks in the task queue (fe_active), task clock cycles required to process vertex tasks (fe_vert_q_active), task clock cycles required to process fragment tasks (fe_frag_q_active), and task clock cycles required to process computation tasks (fe_comp_q_active).

[0066] Accordingly, when the original performance parameters include the task clock cycles required to process the task to be processed, such as fe_vert_q_active, fe_frag_q_active, or fe_comp_q_active, this application can calculate the task proportion of the original performance parameters to obtain the corresponding first performance parameter. This first performance parameter reflects the proportion of the task to be processed to all tasks. Specifically, for example, this application can calculate the proportion of vertex tasks to all tasks (fe_vert_rate) based on fe_vert_q_active and fe_active, where the proportion is fe_vert_q_active / fe_active. This application can calculate the proportion of fragment tasks to all tasks (fe_frag_rate) based on fe_frag_q_active and fe_active, where the proportion is fe_frag_q_active / fe_active. This application can calculate the proportion of computation tasks to all tasks (fe_comp_rate) based on fe_comp_q_active and fe_active, where the proportion is fe_comp_q_active / fe_active.

[0067] When the original performance parameters include the clock cycle (fe_active) when there are tasks in the task queue, this application can calculate the non-empty percentage of the queue based on the original performance parameters to obtain a corresponding second performance parameter. This second performance parameter reflects the non-empty percentage or proportion of the task queue. Specifically, this application can calculate the non-idle percentage (fe_rate) of the task queue based on the clock cycle (fe_active) when there are tasks in the task queue and the clock cycle (gpu_active) of the virtual GPU. This non-idle percentage (fe_rate) is fe_active / gpu_active.

[0068] In another possible implementation, the target module includes a geometry pipeline module for instructing geometric preprocessing of the input image to be rendered. This preprocessing includes, but is not limited to, any one or a combination of the following: cropping, culling, viewport transformation, and chunking. For details regarding cropping, culling, viewport transformation, and chunking, please refer to the foregoing descriptions. Figure 2The relevant descriptions in the embodiments will not be repeated here. The original performance parameters involved in the geometry pipeline module include, but are not limited to, the clock cycle of the block unit (geom_tiler_active), the clock cycle of the geometry pipeline module (geom_active), the number of triangles (geom_triangles), the primitives killed in the viewport plane (geom_culled), and the primitives that are visible after being killed (geom_visible), etc., as shown in Table 2 above.

[0069] Accordingly, this application can calculate the proportion of the original performance parameters in the geometry stage to obtain a corresponding third performance parameter, which can be used to reflect the proportion of the original performance parameters in the geometry stage. Specifically, for example, when the original performance parameters include the clock cycle of the geometry pipeline module, this application can calculate the third performance parameter based on the clock cycle (geom_active) of the geometry pipeline module and the clock cycle (shading_active) of the shader module. In this case, the third performance parameter is used to reflect the proportion or percentage (geom_rate) of the time consumed by the geometry pipeline module (also known as the geometry fixed pipeline) in the entire geometry stage, and this percentage can be expressed as: geom_active / (geom_active+shading_active).

[0070] When the original performance parameters include primitives killed in the viewport plane, this application can calculate a third performance parameter based on the primitives killed (geom_culled) and the primitives visible after killing (geom_visible) in the viewport plane. In this case, the third performance parameter reflects the percentage or proportion of primitives killed during the geometry phase (geom_kill_rate), which can be expressed as: geom_culled / (geom_visible + geom_culled).

[0071] Optionally, when the original performance parameters include the clock cycle of the chunk unit, this application can calculate the corresponding derived performance parameters based on the clock cycle of the chunk unit (geom_tiler_active) and the clock cycle of the entire virtual GPU (gpu_active). In this case, the derived performance parameters are used to reflect the proportion of the chunk unit to all GPU time (geom_tiler_rate), and this proportion can be expressed as: geom_tiler_active / gpu_active.

[0072] In another possible implementation, the target module includes a fragment pipeline module for instructing fragment-stage processing of the input image data, the fragment processing including at least rasterization. Optionally, the fragment processing further includes early depth testing and / or hidden surface removal. For details regarding rasterization, early depth testing, and hidden surface removal in the fragment processing, please refer to the foregoing. Figure 2 The relevant descriptions in the embodiments will not be repeated here. The original performance parameters involved in the fragment pipeline module may include, but are not limited to, the clock cycle (frag_active), the number of squares entering / exiting the rasterization unit, the number of Quads entering / exiting the early depth testing unit, etc., as shown in Table 3 above.

[0073] Accordingly, this application can calculate the proportion of the original performance parameters in the fragment stage to obtain a corresponding fourth performance parameter. This fourth performance parameter reflects the proportion of the original performance parameters in the fragment stage. Specifically, for example, when the original performance parameters include at least the clock cycle of the fragment pipeline module, this application can calculate the fourth performance parameter based on the clock cycle (frag_active) of the fragment pipeline module and the clock cycle (shading_active) of the shader module. In this case, the fourth performance parameter reflects the time consumption proportion or ratio (frag_rate) of the fragment pipeline module in the fragment stage, and this ratio can be expressed as: frag_active / (frag_active+shading_active).

[0074] When the original performance parameters include at least the number of Quads killed during fragment processing, specifically the number of Quads killed by the early depth testing unit (frag_early_zs_kill) and the number of Quads filtered by the HSR unit (frag_hsr_kill), this application can calculate a fourth performance parameter based on frag_early_zs_kill, frag_hsr_kill, and the number of Quads exiting the rasterization unit. This fourth performance parameter reflects the percentage or proportion of Quads killed during the fragment stage (frag_early_kill_rate), which can be expressed as: (frag_early_zs_kill + frag_hsr_kill) / frag_raster_out.

[0075] In another possible implementation, the target module includes a shader module for instructing the input image data to undergo colorization processing, such as vertex colorization using a vertex coloring thread, fragment colorization using a fragment coloring thread, or computational colorization using a computational coloring thread. For a more detailed description of the colorization processing described in this application, please refer to the foregoing. Figure 1 The relevant descriptions in the embodiments will not be repeated here. The original performance parameters involved in the shader module include, but are not limited to, the clock cycle (shading_active), number of vertex shading warps (shading_vert_warps), number of fragment shading warps (shading_frag_warps), and number of compute shading warps (shading_comp_warps) of the shader module as shown in Table 4 above.

[0076] Accordingly, when the original performance parameters include the number of target shader warps, such as the number of vertex shader warps, the number of fragment shader warps, or the number of computed shader warps, this application can calculate the proportion of the target shader threads in the original performance parameters to obtain the corresponding fifth performance parameter. This fifth performance parameter reflects the proportion of the target shader threads to all shader threads in the entire shader module, where each image warp in the target shader warp count is shaded using the target shader thread.

[0077] Specifically, for example, when the original performance parameter includes at least the number of vertex shading warps (shading_vert_warps), this application can calculate the proportion of vertex shading threads based on the number of vertex shading warps to obtain a fifth performance parameter. This fifth performance parameter reflects the proportion of vertex shading threads to all shading threads (shading_vert_rate), and this proportion can be expressed as: shading_vert_warps / (shading_vert_warps+shading_frag_warps+shading_comp_warps).

[0078] When the original performance parameters include at least the number of fragment shading warps (shading_frag_warps), this application can calculate the proportion of fragment shading threads based on the number of fragment shading warps to obtain a fifth performance parameter. This fifth performance parameter reflects the proportion of fragment shading threads to all shading threads (shading_frag_rate), which can be expressed as: shading_frag_warps / (shading_vert_warps + shading_frag_warps + shading_comp_warps).

[0079] When the original performance parameters include at least the number of computed shading warps (shading_comp_warps), this application can calculate the proportion of computed shading threads based on the number of computed shading warps to obtain a fifth performance parameter. This fifth performance parameter reflects the proportion of computed shading threads to all shading threads (shading_comp_rate), and this proportion can be expressed as: shading_comp_warps / (shading_vert_warps + shading_frag_warps + shading_comp_warps).

[0080] Optionally, when the original performance parameters include the clock cycle of the shader module, this application can calculate the shading percentage of the original performance parameters to obtain a corresponding sixth performance parameter. In this case, the sixth performance parameter reflects the time consumption percentage or proportion (shading_rate) of the shader module in the entire virtual GPU. Specifically, this application can calculate the sixth performance parameter based on the clock cycle (shading_active) of the shader module and the clock cycle (gpu_active) of the virtual GPU. This sixth performance parameter reflects the proportion of GPU time occupied by the shader module, and this proportion can be expressed as: shading_active / gpu_active.

[0081] In another possible implementation, the target module includes a back-end processing module for instructing post-processing of image data output by a fragment shader (or fragment shader thread). This post-processing includes, but is not limited to, any one or a combination of the following: post-depth testing, pixel blending, block difference calculation, and frame buffer operations. Further details regarding the back-end processing module described in this application can be found in the foregoing description. Figure 2The relevant descriptions in the embodiments will not be repeated here. The raw performance parameters involved in the backend processing module include, but are not limited to, the number of Quads entering / exiting the late-stage depth testing unit, the number of Quads killed by the late-stage depth testing unit, etc., as shown in Table 5 above.

[0082] Accordingly, this application can calculate the proportion of later-stage fragments on the original performance parameters to obtain a corresponding seventh performance parameter. This seventh performance parameter reflects the proportion of the original performance parameters in post-processing. Specifically, for example, when the original performance parameters include at least the number of Quads killed by the later-stage depth testing unit (be_late_zs_kill), this application can calculate the seventh performance parameter based on be_late_zs_kill and the number of Quads entering the later-stage depth testing unit (be_late_zs_in). This seventh performance parameter reflects the proportion or percentage of fragments killed in post-processing (be_late_kill_rate), which can be expressed as: be_late_zs_kill / be_late_zs_in.

[0083] It should be noted that the above-described derivative computing embodiments are merely examples and do not constitute a limitation. In practical applications, this application can derive corresponding derivative performance parameters based on the original performance parameters of the virtual GPU according to the actual situation. Table 7 below summarizes the derivative performance parameters and the calculation rules / formulas used for their derivative calculations.

[0084] Table 7

[0085] By implementing the embodiments of this application, a virtual GPU performance counter determines the original performance parameters of a target module in the virtual GPU. These original performance parameters reflect the operating status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on the common characteristics of different GPUs. Derivative calculations are then performed on the original performance parameters to obtain derived performance parameters of the virtual GPU, which reflect the device performance of the virtual GPU. Using the solution of this application, highly generalizable derived performance parameters can be calculated based on the original performance parameters of the target module in the virtual GPU, thus more significantly reflecting the device performance of the virtual GPU. This solves the technical problems of limited collection and comparison of GPU performance parameters and poor universality in the prior art.

[0086] Please see Figure 6 This is a schematic diagram of the structure of a virtual GPU performance parameter calculation device provided in an embodiment of this application. Figure 6 The apparatus shown includes: a determining unit 602 and a calculating unit 604, wherein: The determining unit 602 is used to determine the original performance parameters of the target module in the virtual GPU. The original performance parameters are used to reflect the operating status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on the common characteristics of different GPUs. The computing unit 604 is used to perform derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU, which are used to reflect the device performance of the virtual GPU.

[0087] In some embodiments, the target module includes a front-end processing module for instructing the processing of tasks to be processed within the virtual GPU; If the original performance parameters include at least the task clock cycles required to process the task to be processed, then the computing unit 604 is specifically used for: The original performance parameters are used to calculate the proportion of tasks to be processed, and a first performance parameter is obtained. The first performance parameter is used to reflect the proportion of the tasks to be processed to all tasks.

[0088] In some embodiments, the target module includes a front-end processing module for instructing the processing of tasks to be processed within the virtual GPU; If the original performance parameters include at least the clock cycles when there are tasks in the task queue, then the computing unit 604 is specifically used for: The non-empty percentage of the queue is calculated from the original performance parameters to obtain a second performance parameter, which reflects the non-empty percentage of the task queue.

[0089] In some embodiments, the target module includes a geometry pipeline module for instructing geometric preprocessing of the input image to be rendered, the preprocessing including at least one of the following: cropping, culling, viewport transformation, and chunking; the computing unit 604 is specifically used for: The proportion of the original performance parameters in the geometric stage is calculated to obtain a third performance parameter, which reflects the proportion of the original performance parameters in the geometric stage.

[0090] In some embodiments, when the original performance parameters include the clock cycle of the geometry pipeline module, the third performance parameter is used to reflect the proportion of time consumed by the geometry pipeline module in the geometry phase; or, when the original performance parameters include primitives killed in the viewport plane, the third performance parameter is used to reflect the proportion of primitives killed in the geometry phase.

[0091] In some embodiments, the target module includes a fragment pipeline module for instructing fragment processing of the input image data; the computing unit 604 is specifically used for: The original performance parameters are calculated as a percentage of the original performance parameters at the fragment stage to obtain a fourth performance parameter, which reflects the percentage of the original performance parameters at the fragment stage.

[0092] In some embodiments, when the original performance parameter includes the clock cycle of the fragment pipeline module, the fourth performance parameter is used to reflect the proportion of time consumed by the fragment pipeline module in the fragment stage; or, when the original performance parameter includes the number of Quads killed in the fragment processing, the fourth performance parameter is used to reflect the proportion of Quads killed in the fragment stage.

[0093] In some embodiments, the target module includes a shader module for instructing the input image data to be colored; If the original performance parameters include the number of warps in the target colored image, then the calculation unit 604 is specifically used for: The proportion of the target coloring thread is calculated on the original performance parameters to obtain the fifth performance parameter. The fifth performance parameter is used to reflect the proportion of the target coloring thread to all coloring threads. Each warp in the number of target coloring warps is colored using the target coloring thread.

[0094] In some embodiments, the target module includes a shader module for instructing the input image data to be colored; If the original performance parameters include the clock cycle of the shader module, then the calculation unit 604 is specifically used for: The original performance parameters are used to calculate the shading percentage, resulting in a sixth performance parameter, which reflects the percentage of time the shader module consumes on the virtual GPU.

[0095] In some embodiments, the target module includes a back-end processing module for instructing post-processing of the image data output by the fragment shader, the post-processing including at least one of the following: post-depth testing, pixel blending, block difference calculation, and frame buffer operation; the calculation unit 604 is specifically used for: The original performance parameters are used to calculate the proportion of later-stage fragments to obtain a seventh performance parameter, which reflects the proportion of the original performance parameters in the post-processing.

[0096] Please see also Figure 7 and Figure 8 As shown, Figure 7This diagram illustrates another virtual GPU performance counter provided in an embodiment of this application. Figure 7 The virtual GPU performance counter shown includes: a memory 701 storing executable program code; a graphics processing unit (GPU) 702 coupled to the memory 701; the GPU 702 calls the executable program code stored in the memory 701 to execute some or all of the contents as described in the above method embodiment.

[0097] Figure 8 This diagram illustrates the structure of an electronic device according to an embodiment of this application. Figure 8 The illustrated electronic device includes: a processor 801, a graphics processing unit (GPU) 802, and a memory 803 coupled together or separately to the processor 801 and the GPU 802. Wherein: The memory 803 can be used to store software programs and modules. The processor 801 executes various functional applications and data processing of the device by running the software programs and modules stored in the memory 803. The memory 803 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the device (such as audio data, image data, etc.). In addition, the memory 803 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0098] The processor 801 is the control center of the device, connecting various parts of the mobile phone through various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 803, and by calling data stored in the memory 803, thereby providing overall monitoring of the device. Optionally, the processor 801 may include one or more processing units; preferably, the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 801.

[0099] The graphics processing unit (GPU) 802 may include one or more virtual GPUs, which support calling executable program code stored in the memory 803 to execute some or all of the contents described in the method embodiments above.

[0100] This application also provides a computer storage medium that stores a computer program, wherein the computer program causes a computer to perform some or all of the contents described in the method embodiments above.

[0101] In this embodiment, a virtual GPU performance counter determines the original performance parameters of a target module within the virtual GPU. These original performance parameters reflect the operational status of the virtual GPU related to the target module. The target module is obtained by dividing the virtual GPU into modules based on common characteristics of different GPUs. Derivative calculations are then performed on the original performance parameters to obtain derived performance parameters of the virtual GPU, which reflect the device performance of the virtual GPU. This solution allows for the calculation of highly generalizable derived performance parameters based on the original performance parameters of the target module within the virtual GPU, thus more significantly reflecting the device performance of the virtual GPU. This solves the technical problems of limited collection and poor universality of GPU performance parameters in existing technologies.

[0102] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

Claims

1. A method for calculating the performance parameters of a virtual GPU, characterized in that, The method includes: The original performance parameters of the target module in the virtual GPU are determined. The original performance parameters are used to reflect the running status of the virtual GPU related to the target module. The virtual GPU is a virtual GPU proposed by functional partitioning based on the common characteristics of the unified shading model and block architecture of different GPUs. The target module is obtained by partitioning the virtual GPU into modules based on the common characteristics of different GPUs. The virtual GPU includes a front-end processing module, a geometry pipeline module, a fragment pipeline module, a shader module, and a back-end processing module. The target module includes one of the following modules: front-end processing module, geometry pipeline module, fragment pipeline module, shader module, and back-end processing module. The original performance parameters are used to perform derivative calculations to obtain the derived performance parameters of the virtual GPU, which are used to reflect the device performance of the virtual GPU. The target module includes a front-end processing module, which is used to instruct the processing of the task to be processed within the virtual GPU; If the original performance parameters include the task clock cycles required to process the task to be processed, then the derived performance parameters of the virtual GPU obtained by performing derivative calculations on the original performance parameters include: The original performance parameters are used to calculate the proportion of tasks to be processed, and a first performance parameter is obtained. The first performance parameter is used to reflect the proportion of the tasks to be processed to all tasks.

2. The method according to claim 1, characterized in that, The target module includes a front-end processing module, used to instruct the processing of the tasks to be processed within the virtual GPU; If the original performance parameters include the clock cycles when there are tasks in the task queue, then the derived performance parameters of the virtual GPU obtained by performing derivative calculations on the original performance parameters include: The non-empty percentage of the queue is calculated from the original performance parameters to obtain a second performance parameter, which reflects the non-empty percentage of the task queue.

3. The method according to claim 1, characterized in that, The target module includes a geometry pipeline module, which is used to instruct the input image to be rendered to undergo geometric preprocessing. The process of performing derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU includes: The proportion of the original performance parameters in the geometric stage is calculated to obtain a third performance parameter, which reflects the proportion of the characteristic performance indicated by the original performance parameters in the geometric stage.

4. The method according to claim 3, characterized in that, When the original performance parameters include the clock cycle of the geometry pipeline module, the third performance parameter is used to reflect the proportion of time consumed by the geometry pipeline module in the geometry phase; or, When the original performance parameters include primitives killed in the viewport plane, the third performance parameter is used to reflect the proportion of primitives killed in the geometric phase.

5. The method according to claim 1, characterized in that, The target module includes a fragment pipeline module, used to instruct the input image data to be processed into fragments; The process of performing derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU includes: The original performance parameters are calculated to account for a certain percentage at the fragment stage, resulting in a fourth performance parameter. This fourth performance parameter reflects the percentage of the characteristic performance indicated by the original performance parameters at the fragment stage.

6. The method according to claim 5, characterized in that, When the original performance parameters include the clock cycle of the fragment pipeline module, the fourth performance parameter is used to reflect the proportion of time consumed by the fragment pipeline module in the fragment stage. or, When the original performance parameters include the number of Quads killed in the fragment processing, the fourth performance parameter is used to reflect the proportion of Quads killed in the fragment stage.

7. The method according to claim 1, characterized in that, The target module includes a shader module for instructing the input image data to be colored. If the original performance parameters include the number of warps in the target shading image, then the derived performance parameters of the virtual GPU obtained by performing derivative calculations on the original performance parameters include: The proportion of the target coloring thread is calculated on the original performance parameters to obtain the fifth performance parameter. The fifth performance parameter is used to reflect the proportion of the target coloring thread to all coloring threads. Each warp in the number of target coloring image warps is colored using the target coloring thread.

8. The method according to claim 1, characterized in that, The target module includes a shader module for instructing the input image data to be colored. If the original performance parameters include the clock cycle of the shader module, then the derived performance parameters of the virtual GPU obtained by performing derivative calculations on the original performance parameters include: The original performance parameters are used to calculate the shading percentage, resulting in a sixth performance parameter, which reflects the percentage of time the shader module consumes on the virtual GPU.

9. The method according to claim 1, characterized in that, The target module includes a back-end processing module for instructing post-processing of the image data output by the fragment shader. The post-processing includes at least one of the following: post-depth testing, pixel blending, block difference calculation, and frame buffer operation. The process of performing derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU includes: The original performance parameters are used to calculate the proportion of later-stage fragments to obtain a seventh performance parameter, which reflects the proportion of the original performance parameters in the post-processing.

10. A device for calculating the performance parameters of a virtual GPU, characterized in that, It includes a determining unit and a calculating unit, wherein: The determining unit is used to determine the original performance parameters of the target module in the virtual GPU. The original performance parameters are used to reflect the operating status of the virtual GPU related to the target module. The virtual GPU is a virtual GPU proposed by functional partitioning based on the common characteristics of the unified shading model and block architecture of different GPUs. The target module is obtained by partitioning the virtual GPU into modules based on the common characteristics of different GPUs. The virtual GPU includes a front-end processing module, a geometry pipeline module, a fragment pipeline module, a shader module, and a back-end processing module. The target module includes one of the following modules: front-end processing module, geometry pipeline module, fragment pipeline module, shader module, and back-end processing module. The computing unit is used to perform derivative calculations on the original performance parameters to obtain the derived performance parameters of the virtual GPU, which are used to reflect the device performance of the virtual GPU. The target module includes a front-end processing module, which is used to instruct the processing of the task to be processed within the virtual GPU; If the original performance parameters include the task clock cycles required to process the task to be processed, then the computing unit is specifically used for: The original performance parameters are used to calculate the proportion of tasks to be processed, and a first performance parameter is obtained. The first performance parameter is used to reflect the proportion of the tasks to be processed to all tasks.

11. A virtual GPU performance counter, characterized in that, include: Memory containing executable program code; A graphics processing unit (GPU) coupled to the memory; The GPU invokes the executable program code stored in the memory to execute the method according to any one of claims 1-9.

12. An electronic device, characterized in that, include: processor; Graphics Processing Unit (GPU); A memory coupled together with or separately to the processor and the GPU is used to store executable code programs; The GPU invokes the executable program code stored in the memory to execute the method according to any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program causes a computer to perform the method of any one of claims 1-9.

Images