Performance analysis method and device, electronic equipment and storage medium

Abstract

The invention relates to a performance analysis method and device, electronic equipment and a storage medium, and the method comprises the steps that firmware scheduling overhead and / or hardware running overhead of each target task created by a target application program are / is obtained, the target application program runs in an operation system, and the target application program runs in the operation system; the firmware scheduling overhead represents the time from the time when a hardware queue of firmware of the target processor receives a target task to the time when the hardware queue sends the target task to the target processor, and the hardware operation overhead represents the time required by the target processor to execute the target task; and determining a performance analysis result of the target processor according to the firmware scheduling overhead and / or the hardware operation overhead of each target task. According to the embodiment of the invention, the performance of the target processor can be analyzed on the display card driver level, event details realized in the target processor driver can be known more clearly, and the accuracy of performance analysis can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a performance analysis method and apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of real-time rendering technology, graphics processing units (GPUs) have become an indispensable core hardware in fields such as game rendering, film special effects production, 3D modeling, augmented reality (AR), and virtual reality (VR) due to their powerful parallel computing capabilities and efficient graphics processing capabilities.

[0003] However, when running certain complex applications (such as large games) in an operating system, there are instances of unstable rendering frame rates and extremely low frames per second (FPS), which severely impact the user's immersive experience. Precise GPU performance analysis is needed to pinpoint the root cause of these problems. Summary of the Invention

[0004] This disclosure presents a performance analysis method and apparatus, electronic device and storage medium.

[0005] According to one aspect of this disclosure, a performance analysis method is provided, comprising: obtaining the firmware scheduling overhead and / or hardware runtime overhead of each target task created by a target application, wherein the target application runs in an operating system, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor until the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task; and determining the performance analysis result of the target processor based on the firmware scheduling overhead and / or the hardware runtime overhead of each target task.

[0006] In one possible implementation, obtaining the firmware scheduling overhead of each target task created by the target application includes: obtaining user-mode driver events and / or kernel-mode driver events and firmware scheduling events generated during the runtime of the target application; mapping the user-mode driver events and / or kernel-mode driver events and firmware scheduling events to obtain a first mapping relationship; and determining the firmware scheduling overhead of each target task based on the first mapping relationship. Obtaining the hardware runtime overhead of each target task created by the target application includes: obtaining user-mode driver events and / or kernel-mode driver events and hardware operation events generated during the runtime of the target application; mapping the user-mode driver events and / or kernel-mode driver events and hardware operation events to obtain a second mapping relationship; and determining the hardware runtime overhead of each target task based on the second mapping relationship.

[0007] In one possible implementation, before running the target application in the operating system, the method further includes: enabling a first event tracking mechanism for the user-mode driver, so that the user-mode driver writes user-mode driver events to a log through the first event tracking mechanism, wherein the user-mode driver events include at least one of process identifier, task type, task identifier, timestamp, and user-mode task information; and obtaining the user-mode driver events generated during the runtime of the target application, including obtaining the user-mode driver events generated during the runtime of the target application from the log.

[0008] In one possible implementation, before running the target application in the operating system, the method further includes: enabling a second event tracking mechanism for the kernel-mode driver, so that the kernel-mode driver writes kernel-mode driver events to a log through the second event tracking mechanism, wherein the kernel-mode driver events include at least one of process identifier, task identifier, synchronization identifier, timestamp, and kernel-mode task information; and obtaining the kernel-mode driver events generated during the runtime of the target application, including: obtaining the kernel-mode driver events generated during the runtime of the target application from the log.

[0009] In one possible implementation, obtaining the firmware scheduling event and the hardware working event generated during the runtime of the target application includes: reading the firmware scheduling event and the hardware working event generated during the runtime of the target application from a buffer register in kernel mode using a callback interface; wherein, the firmware scheduling event includes at least one of process identifier, task identifier, synchronization identifier, timestamp, and scheduling status information; the hardware working event includes at least one of process identifier, task identifier, synchronization identifier, parallel strategy information, timestamp, and computing core identifier.

[0010] In one possible implementation, the method further includes: grouping the hardware working events according to the computing core identifier to obtain grouping results; and displaying the grouping results through a visualization interface, wherein the grouping results are used to analyze the parallel working state of the target processor.

[0011] In one possible implementation, determining the firmware scheduling overhead of each target task based on the first mapping relationship includes: obtaining firmware scheduling events for each target task within the target process started by the target application based on the first mapping relationship; determining the firmware scheduling overhead of each target task based on the firmware scheduling events of each target task; and determining the hardware operating overhead of each target task based on the second mapping relationship includes: obtaining hardware working events for each target task within the target process started by the target application based on the second mapping relationship; and determining the hardware operating overhead of each target task based on the hardware working events of each target task.

[0012] In one possible implementation, determining the performance analysis result of the target processor based on the firmware scheduling overhead and the hardware runtime overhead of each target task includes: summing the firmware scheduling overhead of each target task within the target process started by the target application to obtain a first result, and summing the hardware runtime overhead of each target task within the target process started by the target application to obtain a second result; sorting the first result and the second result to obtain a sorting result; and determining the performance analysis result of the target processor based on the sorting result.

[0013] In one possible implementation, determining the performance analysis result of the target processor based on the sorting result includes: outputting a first prompt message as the performance analysis result of the target processor when the first result is ranked higher than the second result; and outputting a second prompt message as the performance analysis result of the target processor when the first result is ranked lower than the second result.

[0014] According to one aspect of this disclosure, a performance analysis apparatus is provided, comprising: an acquisition module, configured to acquire firmware scheduling overhead and / or hardware runtime overhead for each target task created by a target application, wherein the target application runs in an operating system, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor until the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task; and a determination module, configured to determine a performance analysis result of the target processor based on the firmware scheduling overhead and / or the hardware runtime overhead of each target task.

[0015] In one possible implementation, the acquisition module is configured to: acquire user-mode driver events and / or kernel-mode driver events and firmware scheduling events generated during the runtime of the target application; map the user-mode driver events and / or the kernel-mode driver events and the firmware scheduling events to obtain a first mapping relationship; and determine the firmware scheduling overhead of each target task based on the first mapping relationship. The acquisition module is further configured to: acquire user-mode driver events and / or kernel-mode driver events and hardware operation events generated during the runtime of the target application; map the user-mode driver events and / or the kernel-mode driver events and the hardware operation events to obtain a second mapping relationship; and determine the hardware operation overhead of each target task based on the second mapping relationship.

[0016] In one possible implementation, the apparatus further includes a writing module, configured to enable a first event tracking mechanism for the user-mode driver before running the target application in the operating system, so that the user-mode driver writes user-mode driver events to a log through the first event tracking mechanism, wherein the user-mode driver events include at least one of process identifier, task type, task identifier, timestamp, and user-mode task information; and to obtain the user-mode driver events generated during the runtime of the target application, comprising: obtaining the user-mode driver events generated during the runtime of the target application from the log.

[0017] In one possible implementation, the writing module is further configured to enable a second event tracking mechanism for the kernel-mode driver before running the target application in the operating system, so that the kernel-mode driver writes kernel-mode driver events to the log through the second event tracking mechanism. The kernel-mode driver events include at least one of process identifier, task identifier, synchronization identifier, timestamp, and kernel-mode task information. Obtaining the kernel-mode driver events generated during the runtime of the target application includes: obtaining the kernel-mode driver events generated during the runtime of the target application from the log.

[0018] In one possible implementation, obtaining the firmware scheduling event and the hardware working event generated during the runtime of the target application includes: reading the firmware scheduling event and the hardware working event generated during the runtime of the target application from a buffer register in kernel mode using a callback interface; wherein, the firmware scheduling event includes at least one of process identifier, task identifier, synchronization identifier, timestamp, and scheduling status information; the hardware working event includes at least one of process identifier, task identifier, synchronization identifier, parallel strategy information, timestamp, and computing core identifier.

[0019] In one possible implementation, the device further includes a grouping module, configured to: group the hardware working events according to the computing core identifier to obtain grouping results; and display the grouping results through a visualization interface, wherein the grouping results are used to analyze the parallel working state of the target processor.

[0020] In one possible implementation, determining the firmware scheduling overhead of each target task based on the first mapping relationship includes: obtaining firmware scheduling events for each target task within the target process started by the target application based on the first mapping relationship; determining the firmware scheduling overhead of each target task based on the firmware scheduling events of each target task; and determining the hardware operating overhead of each target task based on the second mapping relationship includes: obtaining hardware working events for each target task within the target process started by the target application based on the second mapping relationship; and determining the hardware operating overhead of each target task based on the hardware working events of each target task.

[0021] In one possible implementation, the determining module is configured to: add the firmware scheduling overhead of each target task within the target process started by the target application to obtain a first result, and add the hardware operation overhead of each target task within the target process started by the target application to obtain a second result; sort the first result and the second result to obtain a sorting result; and determine the performance analysis result of the target processor based on the sorting result.

[0022] In one possible implementation, determining the performance analysis result of the target processor based on the sorting result includes: outputting a first prompt message as the performance analysis result of the target processor when the first result is ranked higher than the second result; and outputting a second prompt message as the performance analysis result of the target processor when the first result is ranked lower than the second result.

[0023] According to one aspect of this disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the method described above.

[0024] According to one aspect of this disclosure, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the above-described method.

[0025] In this embodiment of the disclosure, the firmware scheduling overhead and / or hardware runtime overhead of each target task created by the target application can be obtained. The target application runs in an operating system. The firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor until the hardware queue sends the target task to the target processor. The hardware runtime overhead represents the time required for the target processor to execute the target task. Based on the firmware scheduling overhead and / or hardware runtime overhead of each target task, the performance analysis result of the target processor is determined.

[0026] In this way, by acquiring firmware scheduling overhead and / or hardware runtime overhead, the performance of the target processor can be analyzed at the graphics card driver level, providing a clearer understanding of the event details implemented internally by the target processor driver, which helps improve the accuracy of performance analysis.

[0027] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

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

[0029] Figure 1 A flowchart illustrating a performance analysis method according to an embodiment of the present disclosure is shown.

[0030] Figure 2 This diagram illustrates the workflow between user-mode drivers, kernel-mode drivers, graphics processor firmware, and graphics processor hardware according to embodiments of the present disclosure.

[0031] Figure 3 A block diagram of a performance analysis apparatus according to an embodiment of the present disclosure is shown.

[0032] Figure 4 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

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

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

[0035] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

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

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

[0038] In related technologies, the performance of the graphics processing unit (GPU) can be analyzed using internal tools of the operating system (Windows) itself (such as GPUView). Specifically, these internal tools can use Event Tracing for Windows (ETW) to globally capture events provided by event providers (ETW providers) such as the Windows Display Driver Model (WDDM), the DirectX 3D hardware acceleration interface (D3D), and the kernel across various processes. Based on ETW event analysis, the processing performance of the GPU and the central processing unit (CPU) in direct memory access (DMA) buffers, as well as the video processing performance on video hardware, can be assessed.

[0039] The operating system's Event Tracing (ETW) mechanism can be used to track events created by user-level applications and kernel-level drivers. ETW allows developers to insert events into applications, device drivers, and kernel components to collect detailed information about system behavior during application runtime. These ETW events can be used to diagnose performance problems, debug applications, monitor system activity, and more, providing developers with a fast, reliable, and scalable event tracing framework.

[0040] An event provider is an executable module, such as an application, device driver, or kernel component, that generates events and sends them to ETW. Event providers register with the system and can specify the type and structure of the events.

[0041] Performance analysis methods in related technologies rely solely on capturing ETW events from WDDM / D3D / Kernel. In essence, they indirectly analyze GPU performance based on events created by user-level applications running on the CPU and kernel-level drivers. They lack understanding of the task execution state inside the GPU driver and the task scheduling performance inside the GPU hardware, making it difficult to accurately pinpoint GPU performance bottlenecks.

[0042] In view of this, embodiments of the present disclosure provide a performance analysis method. This method can obtain the firmware scheduling overhead and / or hardware runtime overhead of each target task created by a target application, and determine the performance analysis result of the target processor (e.g., GPU) based on the firmware scheduling overhead and / or the hardware runtime overhead of each target task. Wherein, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the target processor's firmware until the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task.

[0043] In this way, by analyzing firmware scheduling overhead (the queuing time of the target task in the GPU hardware queue) and / or hardware runtime overhead (the actual execution time of the target task by the GPU), GPU performance can be analyzed at the graphics card driver level, providing a clearer understanding of the event details implemented internally by the GPU driver, which helps improve the accuracy of GPU performance analysis.

[0044] Figure 1 A flowchart illustrating a performance analysis method according to an embodiment of this disclosure is shown. Figure 1 As shown, the method includes:

[0045] In step S11, the firmware scheduling overhead and / or hardware runtime overhead of each target task created by the target application are obtained, wherein the target application runs in an operating system, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor until the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task; the target task may be a computational task or a rendering task in the graphics processing process;

[0046] In step S12, the performance analysis results of the target processor are determined based on the firmware scheduling overhead and / or hardware operation overhead of each target task.

[0047] In one possible implementation, the performance analysis method of this disclosure embodiment can be executed by an electronic device such as a terminal device or a server. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. The performance analysis method can be implemented by a processor calling computer-readable instructions stored in memory. Alternatively, the method can be executed by a server.

[0048] In one possible implementation, the software product developed using the performance analysis method of this disclosure can be deployed in a client or server management system as a functional module of the management system. The management system can be a standalone application, a public account, a mini-program, or a standalone webpage; no specific limitations are made here.

[0049] In one possible implementation, the method is used to analyze the performance of a target processor on an operating system. The operating system manages the target processor through a driver, and may include desktop operating systems, mobile operating systems, server operating systems, embedded operating systems, etc. The embodiments of this disclosure do not limit the type of operating system.

[0050] The target processor can function as an acceleration component, working in conjunction with the Central Processing Unit (CPU) to perform computational tasks. For example, the CPU can handle logical operations and task scheduling, while the target processor focuses on specialized computations (such as large-scale parallel graphics computing). The target processor may include a Graphics Processing Unit (GPU), a General Purpose Computing on Graphics Processing Units (GPGPU), a Tensor Processing Unit (TPU), a Neural Network Processing Unit (NPU), etc. The embodiments of this disclosure do not limit the type of target processor.

[0051] To clearly illustrate the performance analysis method of this disclosure embodiment, the specific process of the operating system driving the GPU device is described below. The GPU device driver in the operating system (e.g., Windows) needs to be implemented according to the Windows Display Driver Model (WDDM). This architecture may include a user-mode driver (UMD), a kernel-mode driver (KMD), and the firmware of the graphics processing unit (GPU). The user-mode driver and kernel-mode driver run on the CPU, while the GPU firmware runs on the GPU.

[0052] Figure 2 The diagram illustrates the workflow between user-mode drivers, kernel-mode drivers, graphics processor firmware, and graphics processor hardware according to embodiments of the present disclosure, such as... Figure 2 As shown, the user-mode driver runs in user space and can create target tasks of drawing or computation classes. These target tasks are then submitted to the kernel-mode driver. Upon receiving the target task from the user-mode driver, the kernel-mode driver can submit it to the graphics processor's hardware queue via the graphics processor firmware. The graphics processor firmware, upon receiving the target task from the kernel-mode driver, can configure the registers of the graphics processor's hardware queue, triggering different types of execution units within the graphics processor hardware to begin work. When a graphics processor hardware execution unit completes its task, the graphics processor firmware can notify the kernel-mode driver via an interrupt. The kernel-mode driver then notifies the user-mode driver of the task completion status through a synchronization mechanism.

[0053] In one possible implementation, the target application to be analyzed can be launched in the operating system to collect data on the operation of the target processor (e.g., GPU) under real load. The target application may include applications that require rendering, such as games, video processing, film special effects production, and 3D modeling. This disclosure does not specifically limit the type of target application.

[0054] When the target application starts executing, the operating system creates a corresponding process for it and schedules resources for each target task created by the process for the target application. After the target application has been running in the operating system for a period of time, the firmware scheduling overhead and hardware operation overhead of each target task created by the target application can be obtained.

[0055] For example, the firmware's hardware queue can receive target tasks from kernel-mode drivers, record the timestamp when the hardware queue receives the target task, and the timestamp when the hardware queue sends the target task to the target processor, and obtain the firmware scheduling overhead of the target task based on the difference between these two timestamps.

[0056] The firmware can communicate with the kernel-mode driver and, according to the kernel-mode driver's instructions, control the target processor's pipeline, that is, the order in which target tasks are arranged in the hardware queue. The firmware's hardware queue is used to manage the target processor's workflow and is responsible for coordinating the execution order of target tasks. In the hardware queue, the target task at the head of the queue represents the work that is currently being executed, and the target tasks after it represent the work that is waiting. The target processor can execute target tasks sequentially from the head to the tail of the queue.

[0057] For example, in response to receiving a target task from a hardware queue, the target processor can record the timestamp of receiving the target task and the timestamp of completing the target task and returning the execution result of the target task to the target processor firmware. The hardware operating overhead of the target task can be obtained based on the difference between these two timestamps.

[0058] By obtaining the firmware scheduling overhead and / or hardware operating overhead of each target task, the performance analysis results of the target processor can be determined based on the firmware scheduling overhead and / or hardware operating overhead of each target task.

[0059] In the examples, to better analyze the performance of the target processor during the scheduling phase, only the firmware scheduling overhead of each target task can be obtained, and the performance analysis result of the target processor can be determined based on the firmware scheduling overhead of each target task. Alternatively, to better analyze the performance of the target processor during the execution phase, only the hardware runtime overhead of each target task can be obtained, and the performance analysis result of the target processor can be determined based on the hardware runtime overhead of each target task. Or, to analyze the performance of the target processor more comprehensively, both the firmware scheduling overhead and the hardware runtime overhead of each target task can be obtained simultaneously, and the performance analysis result of the target processor can be determined based on both the firmware scheduling overhead and the hardware runtime overhead of each target task. The embodiments of this disclosure do not impose limitations on these methods.

[0060] For example, suppose the target application executes N target tasks in its created process, such as target task 1 to target task N. The firmware scheduling overhead and hardware runtime overhead corresponding to each of these N target tasks can be obtained. For example, the firmware scheduling overhead 1 and hardware runtime overhead 1 corresponding to target task 1, the firmware scheduling overhead 2 and hardware runtime overhead 2 corresponding to target task 2, and so on, up to the firmware scheduling overhead N and hardware runtime overhead N corresponding to target task N.

[0061] Optionally, N firmware scheduling overheads and N hardware operation overheads can be input into a pre-trained neural network model, and the neural network model can be used to determine the performance analysis results of the target processor.

[0062] Optionally, the performance analysis results of the target processor can be comprehensively analyzed based on the statistical results (such as mean, maximum, summation, sorting, etc.) of firmware scheduling overhead 1 to firmware scheduling overhead N and hardware operation overhead 1 to hardware operation overhead N.

[0063] For example, the firmware scheduling overhead and hardware runtime overhead of each target task can be summed to obtain N sums. Based on these N sums, the target tasks affecting the target processor's performance can be identified. For instance, the target task with the highest sum (i.e., the most heavily loaded target task) can be considered the one affecting the target processor's performance; alternatively, the target tasks corresponding to sums exceeding a preset threshold can also be considered the ones affecting the target processor's performance. Then, the performance bottlenecks of the target processor can be analyzed by combining the content of these selected target tasks.

[0064] For example, the performance of the target processor's firmware scheduling strategy can be determined by comparing the maximum value (average or sum) of firmware scheduling costs 1 to N with a preset threshold. For instance, if the maximum value of firmware scheduling costs 1 to N is greater than the preset threshold, the target processor's firmware scheduling strategy will affect its performance; if the maximum value is less than or equal to the preset threshold, the target processor's firmware scheduling strategy will not affect its performance.

[0065] For example, the performance of the target processor can be determined by comparing the maximum value (mean or sum) of hardware overhead 1 to hardware overhead N with a preset threshold. For instance, if the maximum value among hardware overhead 1 to hardware overhead N is greater than the preset threshold, it indicates that the target processor's hardware execution strategy affects its performance; if the maximum value among hardware overhead 1 to hardware overhead N is less than or equal to the preset threshold, it indicates that the target processor's hardware execution strategy does not affect its performance.

[0066] As can be seen, compared with related technologies that indirectly analyze GPU performance based on events created by user-level applications and kernel-level drivers running on the CPU, the embodiments of this disclosure can directly analyze GPU performance at the graphics card driver level through firmware scheduling overhead (queue time of the target task in the GPU hardware queue) and / or hardware runtime overhead (actual execution time of the target task by the GPU). This provides a clearer understanding of the event details implemented internally by the GPU driver and helps improve the accuracy of GPU performance analysis.

[0067] The performance analysis method of this disclosure embodiment will be described in detail below.

[0068] In one possible implementation, user-mode driver events, kernel-mode driver events, firmware scheduling events, and hardware operation events generated during the runtime of the target application can be obtained; the user-mode driver events, kernel-mode driver events, firmware scheduling events, and hardware operation events can be mapped to obtain a mapping relationship; and the firmware scheduling overhead and hardware operation overhead of each target task can be determined based on the mapping relationship.

[0069] The mapping relationship can intuitively display the event path of each level (such as user mode, kernel mode, firmware scheduling, and hardware execution) during the execution of the target task, which is conducive to efficiently locating the performance bottleneck of the target processor.

[0070] User-mode driver events and kernel-mode driver events can be obtained based on the operating system's event tracing mechanism (Event Tracing for Windows, ETW). These events are defined by a set of attributes determined by the ETW provider. User-mode driver events are provided by the user-mode driver, and kernel-mode driver events are provided by the kernel-mode driver. The ETW Application Programming Interface (API) provides a set of functions that can be used by both user-mode and kernel-mode drivers. Driver developers can use these functions to register user-mode and kernel-mode drivers as ETW providers. ETW providers can raise user-mode and kernel-mode driver events and publish them to the operating system's event log. They can also write user-mode and kernel-mode driver events to an ETW session, which will then write to a trace file or transmit them to a real-time consumer (i.e., the application or file receiving the event tracing session).

[0071] In one possible implementation, to obtain user-mode driver events generated during the runtime of the target application, a first event tracking mechanism for the user-mode driver is enabled before running the target application to be analyzed in the operating system. This mechanism allows the user-mode driver to write user-mode driver events to a log. These user-mode driver events include at least one of process identifier, task type, task identifier, timestamp, and user-mode task information. After enabling the first event tracking mechanism, the target application to be analyzed can be started. After running for a period of time, the user-mode driver events generated during the runtime of the target application can be obtained from the log.

[0072] For example, as an independent event provider, a user-mode driver needs to define the user-mode events to be generated in order to obtain user-mode driver events generated by the target application at runtime. The user-mode driver events may include at least one of the following: process identifier, task type, task identifier, timestamp, and user-mode task information.

[0073] In this context, a process is an instance of a running application. Whenever a user launches an application, the operating system automatically creates a process for that application. A process identifier is used to identify the process running in the operating system. A process can perform different target tasks at specific times or under specific conditions based on the user's interaction with the application to achieve certain functions of the application. Task types can include drawing tasks and computation tasks in graphics processing. Task identifiers are used to identify different target tasks, and each process can correspond to multiple different tasks. A timestamp is used to record the time point when the target task is triggered, such as the time point when the user-mode driver submits the target task to the kernel-mode driver. User-mode task information can include data information related to the target task. For example, for a drawing task, user-mode task information can include the number of vertices drawn, data structures, position information, etc. For a computation task, user-mode task information can include the degree of parallelism of the split, coordinate information, etc.

[0074] After defining a user-mode driver event, in order for the first event tracing mechanism to recognize it, the user-mode driver event needs to be written to the operating system, thereby enabling the first event tracing mechanism for user-mode drivers. In this way, when the application to be analyzed is run subsequently, the user-mode driver can write user-mode driver events to the log through the first event tracing mechanism, thus capturing the application's user-mode driver events from the log.

[0075] By enabling the user-mode driven first event tracking mechanism, user-mode driven events can be customized. These events can include at least one of the following: process identifier, task type, task identifier, timestamp, and user-mode task information. Different user-mode driven events can be defined according to specific application scenarios, which helps to improve the flexibility and scalability of performance analysis methods.

[0076] In one possible implementation, before running the target application to be analyzed in the operating system, the method further includes: enabling a second event tracking mechanism for the kernel-mode driver, so that the kernel-mode driver writes kernel-mode driver events to a log through the second event tracking mechanism. The kernel-mode driver events include at least one of a process identifier, a task identifier, a synchronization identifier, a timestamp, and kernel-mode task information. After enabling the second event tracking mechanism for the kernel-mode driver, the target application to be analyzed can be started, and after running for a period of time, the kernel-mode driver events generated during the runtime of the target application can be obtained from the log.

[0077] For example, a kernel-mode driver, as another independent event provider, can accept target tasks submitted by user-mode drivers and submit them to the hardware queue of the target processor (e.g., GPU). In order to obtain kernel-mode driver events generated during the runtime of the target application, it is necessary to define the kernel-mode driver events to be generated by the kernel-mode driver. The kernel-mode driver events may include at least one of the following: process identifier, task identifier, synchronization identifier (Fence ID), timestamp, and kernel-mode task information.

[0078] In this context, a process is an instance of a running application. Whenever a user launches an application, the operating system automatically creates a process for that application. A process identifier is used to identify the process running in the operating system. A process can execute different target tasks at specific times or under specific conditions based on user interaction with the application to achieve certain functions of the application. A task identifier is used to identify different target tasks; each process can correspond to multiple different tasks. A synchronization identifier is used to mark the completion status of a target task. When a kernel-mode driver submits a target task to the hardware queue of the target processor (e.g., GPU), it associates it with a target identifier. Subsequently, it can wait for the target processor to return the synchronization identifier via firmware through polling or blocking, ensuring that the result is processed only after the target task is completed. A timestamp is used to record the time point when the target task is triggered, such as the time point when the kernel-mode driver submits the target task to the hardware queue of the target processor (e.g., GPU). Kernel-mode task information can include data information related to the target task. For example, for a drawing task, kernel-mode task information can include the number of vertices drawn, data structures, position information, etc.; for a computation task, kernel-mode task information can include the degree of parallelism of the split, coordinate information, etc.

[0079] After defining kernel-mode driver events, in order for the second event tracing mechanism to recognize these events, they need to be written to the operating system, thereby enabling the second event tracing mechanism for kernel-mode drivers. In this way, when the application to be analyzed is run subsequently, the kernel-mode driver can write kernel-mode driver events to the log through the second event tracing mechanism, thus capturing the application's kernel-mode driver events from the log.

[0080] By enabling the second event tracking mechanism of the kernel-mode driver, custom kernel-mode driver events can be defined. These events can include at least one of the following: process identifier, task identifier, synchronization identifier, timestamp, and kernel-mode task information. Different kernel-mode driver events can be defined according to specific application scenarios, which helps to improve the flexibility and scalability of performance analysis methods.

[0081] In one possible implementation, obtaining the firmware scheduling event and the hardware working event generated during the runtime of the target application includes: reading the firmware scheduling event and the hardware working event generated during the runtime of the target application from a buffer register in kernel mode using a callback interface; wherein, the firmware scheduling event includes at least one of process identifier, task identifier, synchronization identifier, timestamp, and scheduling status information; the hardware working event includes at least one of process identifier, task identifier, synchronization identifier, parallel strategy information, timestamp, and computing core identifier.

[0082] For example, a kernel-mode driver can allocate two buffer registers, such as buffer register 1 and buffer register 2. After the target processor's (e.g., GPU) firmware receives the target task from the kernel-mode driver, it can parse the process identifier, task identifier, and synchronization identifier (Fence ID) carried in the target task submitted by the kernel-mode driver. During task scheduling, the firmware records the scheduling time and scheduling status information, and writes these events (including process identifier, task identifier, and synchronization identifier) ​​to buffer register 1. After the firmware scheduling is complete, it begins configuring the registers of the target processor's (e.g., GPU) hardware queue and triggers the target processor's hardware to start working. At this time, it can write the target processor hardware start event (including process identifier, task identifier, and synchronization identifier). After the target task is completed, it writes the task completion event (including process identifier, task identifier, and synchronization identifier), and records all these events in buffer register 1. When the number of events in buffer register 1 reaches a certain level, an interrupt is triggered, notifying the kernel-mode driver to copy the events from buffer register 1 to buffer register 2. In this case, the operating system's callback interface (such as the D3D ESCAPE CALL interface) can be used to read the firmware scheduling events and hardware operation events generated by the target application during runtime from the kernel-mode buffer register 2.

[0083] For example, a firmware scheduling event may include at least one of the following: process identifier, task identifier, synchronization identifier, timestamp, and scheduling status information. The process identifier is used to identify the process running in the operating system; the task identifier is used to identify different target tasks, and each process may correspond to multiple different tasks; the synchronization identifier is used to mark the completion status of the target task. When the kernel-mode driver submits a target task to the hardware queue of the target processor (e.g., GPU), it associates a synchronization identifier. Subsequently, it can wait for the target processor to return the synchronization identifier via firmware through polling or blocking, ensuring that other target tasks are processed only after the target task is completed. This allows the CPU and GPU to coordinate task progress and avoid data competition and resource conflicts; the timestamp is used to record the time point when the target processor (e.g., GPU) hardware queue receives the target task submitted by the kernel-mode driver, and the time point when the target processor's hardware queue completes scheduling and sends the target task to the execution unit of the target processor hardware; the scheduling status information is used to indicate the priority order of the target tasks.

[0084] For example, a hardware task event may include at least one of the following: process identifier, task identifier, synchronization identifier, parallel strategy information, timestamp, and compute core identifier. The process identifier is used to identify the process running in the operating system; the task identifier is used to identify different target tasks; the synchronization identifier is used to mark the completion status of the target task, ensuring that other target tasks are processed only after the target task is completed; the parallel strategy information may include at least one of data parallelism, pipelining parallelism, or tensor parallelism; the timestamp is used to record the time point when the target task is triggered, such as the time point when the target processor (e.g., GPU) receives the target task and the time point when the target processor completes the execution of the target task; and the compute core identifier is used to identify different compute cores in the target processor.

[0085] In this way, firmware scheduling events and hardware operation events generated during the runtime of the target application can be obtained efficiently, which helps to better understand the task execution status inside the target processor driver and the task scheduling performance inside the target processor hardware.

[0086] In one possible implementation, the hardware working events are grouped according to the computing core identifier to obtain grouping results; the grouping results are displayed through a visualization interface, and the grouping results are used to analyze the parallel working state of the target processor.

[0087] In this way, hardware working events can also be grouped according to computing core identifiers. By displaying the grouping information of computing core identifiers on the front end, the parallel working state of the target processor can be determined, and the performance optimization strategy of the target processor can be further analyzed.

[0088] It should be understood that when capturing firmware scheduling events and hardware operation events of the target processor, the clock frequency of the target processor should be kept fixed in order to improve the accuracy of the timestamps of events (firmware scheduling events and hardware operation events) related to the target processor.

[0089] In one possible implementation, some or all of the user-mode driver events, kernel-mode driver events, firmware scheduling events, and hardware operation events generated during the runtime of the target application can be obtained; these obtained events can be mapped to obtain a first mapping relationship and a second mapping relationship.

[0090] For example, user-mode driver events and / or kernel-mode driver events and firmware scheduling events generated during the runtime of the target application can be obtained; the user-mode driver events and / or the kernel-mode driver events and firmware scheduling events can be mapped to obtain a first mapping relationship; based on the first mapping relationship, the firmware scheduling overhead of each target task can be determined. The first mapping relationship can be between user-mode driver events, kernel-mode driver events, and firmware scheduling events; it can also be between user-mode driver events and firmware scheduling events; or it can be between kernel-mode driver events and firmware scheduling events. The choice can be made according to the specific application scenario, and the embodiments of this disclosure do not limit this.

[0091] In this embodiment, different levels of granularity in the first mapping relationship can be obtained through process identifiers, task identifiers, and synchronization identifiers. The first mapping relationship between events can be established using only one of these three identifiers; alternatively, all three can be used simultaneously. This disclosure does not impose any limitations on this approach. The first mapping relationship established using process identifiers, task identifiers, and synchronization identifiers provides finer granularity, which is beneficial for more accurately locating the performance bottleneck of the target processor during the scheduling phase.

[0092] Similarly, user-mode driver events and / or kernel-mode driver events, and hardware operation events generated during the runtime of the target application can be obtained; the user-mode driver events and / or the kernel-mode driver events and the hardware operation events can be mapped to obtain a second mapping relationship; based on the second mapping relationship, the hardware runtime overhead of each target task can be determined. The second mapping relationship can be between user-mode driver events, kernel-mode driver events, and hardware operation events, or between user-mode driver events and hardware operation events, or between kernel-mode driver events and hardware operation events, and can be selected according to the specific application scenario. The embodiments of this disclosure do not limit this.

[0093] In this embodiment, second mapping relationships at different granularities can be obtained through process identifiers, task identifiers, and synchronization identifiers. The second mapping relationship between events can be established using only one of these three identifiers; alternatively, all three can be used simultaneously. This disclosure does not impose any limitations on this approach. The second mapping relationship established using process identifiers, task identifiers, and synchronization identifiers provides finer granularity, which is beneficial for more accurately locating performance bottlenecks in the target processor during the execution phase.

[0094] For example, the process ID of a target application (e.g., a game) can be obtained. The target user-mode driver event corresponding to this process ID can be found from user-mode driver events. This target user-mode driver event contains the process ID and task ID. The target kernel-mode driver event, i.e., the user-mode driver event with the same process ID and task ID, can be found from kernel-mode driver events. Since the target kernel-mode driver event contains a synchronization identifier, this synchronization identifier can be considered globally unique for a given process. Then, events with the same process ID, task ID, and synchronization identifier are found in firmware scheduling events and hardware operation events. This completes the mapping of user-mode driver events, kernel-mode driver events, firmware scheduling events, and hardware operation events, resulting in a first mapping relationship and a second mapping relationship. This allows for precise tracking of the execution path of the target processor's related operations when any application is executed, providing a complete event trajectory for performance analysis and debugging. Based on the first and second mapping relationships, the firmware scheduling overhead and hardware operation overhead of each target task can be determined.

[0095] In one possible implementation, the firmware scheduling event of each target task within the target process started by the target application can be obtained according to the first mapping relationship; and the firmware scheduling overhead of each target task can be determined according to the firmware scheduling event of each target task.

[0096] For example, a first mapping table containing process identifiers, task identifiers, and synchronization identifiers can be created based on the first mapping relationship. This first mapping table can serve as a key index for querying firmware scheduling events. Then, the firmware scheduling events of each target task in the first mapping table can be traversed task by task. Firmware scheduling events with the same process identifier, task identifier, and synchronization identifier belong to the same target task. Based on the timestamp of each target task's firmware scheduling event, the first moment when the hardware queue of the target processor receives the target task (i.e., the time when the target processor firmware schedules the target processor to start executing the task) and the second moment when the hardware queue sends the target task to the target processor (the time when the target processor firmware begins scheduling) are obtained. The difference between the first moment and the second moment is taken as the firmware scheduling cost of the target task. In this way, the firmware scheduling cost of each target task can be accurately determined.

[0097] In one possible implementation, the hardware operation events of each target task within the target process started by the target application can be obtained according to the second mapping relationship; and the hardware operation overhead of each target task can be determined according to the hardware operation events of each target task.

[0098] For example, a second mapping table containing process identifiers, task identifiers, and synchronization identifiers can be created based on the second mapping relationship. This second mapping table can serve as a key index for querying hardware working events. Then, the hardware working events of each target task in the second mapping table can be traversed task by task. Hardware working events with the same process identifier, task identifier, and synchronization identifier belong to the same target task. Based on the timestamp of each target task's hardware working event, the end time and start time of the target processor executing the target task can be obtained. The difference between the end time and the start time is taken as the hardware working cost of the target task. In this way, the hardware working cost of each target task can be accurately determined.

[0099] In step S11, the firmware scheduling overhead and hardware operation overhead of each target task created by the target application are obtained. In step S12, the performance analysis result of the target processor can be determined based on the firmware scheduling overhead and hardware operation overhead of each target task.

[0100] In one possible implementation, step S12 may include: summing the firmware scheduling overhead of each target task within the target process started by the target application to obtain a first result, and summing the hardware operation overhead of each target task within the target process started by the target application to obtain a second result; sorting the first result and the second result to obtain a sorting result; and determining the performance analysis result of the target processor based on the sorting result.

[0101] For example, in an operating system, a target application can be broken down into multiple target processes to execute different tasks or subtasks. The firmware scheduling overhead of processes with the same process ID but different task IDs can be added together to obtain a first result, and the hardware runtime overhead of processes with the same process ID but different task IDs can be added together to obtain a second result. Thus, each target process can correspond to one first result and one second result.

[0102] For example, the first and second results corresponding to each target process can be sorted to obtain a sorting result. Based on the sorting result, the performance bottleneck of the target processor for each target process can be determined. If the first result of a target process is greater than the second result, it indicates that the performance bottleneck of the target processor for that target process lies in the firmware scheduling policy; if the first result of a target process is less than the second result, it indicates that the performance bottleneck of the target processor for that target process lies in the hardware execution policy.

[0103] For example, all the first and second results can be sorted to obtain a sorting result, and based on the sorting result, the performance bottleneck of the target processor for the target application can be determined. If the first result is ranked first, it means that the performance bottleneck of the target processor for the target application is in the firmware scheduling policy; if the second result is ranked first, it means that the performance bottleneck of the target processor for the target application is in the hardware execution policy.

[0104] In this way, the performance bottleneck of the target processor can be accurately and quickly located.

[0105] In one possible implementation, if the first result is ranked higher than the second result, a first prompt message is output as the performance analysis result of the target processor; if the first result is ranked lower than the second result, a second prompt message is output as the performance analysis result of the target processor.

[0106] The first prompt information describes the performance bottleneck of the target processor for the target process due to the firmware scheduling strategy, while the second prompt information describes the performance bottleneck of the target processor for the target process due to the hardware execution strategy. It should be understood that the first and second prompt information can be composed of at least one of the following: graphics, tables, text, special symbols, and letters. The embodiments of this disclosure do not limit the specific form of the first and second prompt information.

[0107] In this way, users can quickly understand the performance level of the target processor through concise and clear prompts, making it more user-friendly.

[0108] In summary, the embodiments of this disclosure provide a performance analysis method. This method can obtain the firmware scheduling overhead and / or hardware runtime overhead of each target task created by a target application, and determine the performance analysis result of the target processor (e.g., GPU) based on the firmware scheduling overhead and / or hardware runtime overhead of each target task. The firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the target processor's firmware until the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task. Therefore, by using the firmware scheduling overhead (the queuing time of the target task in the GPU hardware queue) and / or the hardware runtime overhead (the actual execution time of the target task by the GPU), GPU performance can be analyzed at the graphics card driver level, providing a clearer understanding of the event details implemented internally by the GPU driver, which helps improve the accuracy of GPU performance analysis.

[0109] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0110] In addition, this disclosure also provides performance analysis apparatus, electronic equipment, computer-readable storage medium, and program, all of which can be used to implement any of the performance analysis methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding section of the method and will not be repeated here.

[0111] Figure 3 A block diagram of a performance analysis apparatus according to an embodiment of the present disclosure is shown, such as Figure 3 As shown, the device includes:

[0112] The acquisition module 31 is used to acquire the firmware scheduling overhead and / or hardware running overhead of each target task created by the target application, wherein the target application runs in an operating system, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor to when the hardware queue sends the target task to the target processor, and the hardware running overhead represents the time required for the target processor to execute the target task.

[0113] The determination module 32 is used to determine the performance analysis results of the target processor based on the firmware scheduling overhead and / or the hardware operation overhead of each target task.

[0114] In one possible implementation, the acquisition module 31 is configured to: acquire user-mode driver events and / or kernel-mode driver events and firmware scheduling events generated during the runtime of the target application; map the user-mode driver events and / or the kernel-mode driver events and the firmware scheduling events to obtain a first mapping relationship; and determine the firmware scheduling overhead of each target task based on the first mapping relationship. The acquisition module 31 is further configured to: acquire user-mode driver events and / or kernel-mode driver events and hardware operation events generated during the runtime of the target application; map the user-mode driver events and / or the kernel-mode driver events and the hardware operation events to obtain a second mapping relationship; and determine the hardware operation overhead of each target task based on the second mapping relationship.

[0115] In one possible implementation, the apparatus further includes a writing module, configured to enable a first event tracking mechanism for the user-mode driver before running the target application in the operating system, so that the user-mode driver writes user-mode driver events to a log through the first event tracking mechanism, wherein the user-mode driver events include at least one of process identifier, task type, task identifier, timestamp, and user-mode task information; and to obtain the user-mode driver events generated during the runtime of the target application, comprising: obtaining the user-mode driver events generated during the runtime of the target application from the log.

[0116] In one possible implementation, the writing module is further configured to enable a second event tracking mechanism for the kernel-mode driver before running the target application in the operating system, so that the kernel-mode driver writes kernel-mode driver events to the log through the second event tracking mechanism. The kernel-mode driver events include at least one of process identifier, task identifier, synchronization identifier, timestamp, and kernel-mode task information. Obtaining the kernel-mode driver events generated during the runtime of the target application includes: obtaining the kernel-mode driver events generated during the runtime of the target application from the log.

[0117] In one possible implementation, obtaining the firmware scheduling event and the hardware working event generated during the runtime of the target application includes: reading the firmware scheduling event and the hardware working event generated during the runtime of the target application from a buffer register in kernel mode using a callback interface; wherein, the firmware scheduling event includes at least one of process identifier, task identifier, synchronization identifier, timestamp, and scheduling status information; the hardware working event includes at least one of process identifier, task identifier, synchronization identifier, parallel strategy information, timestamp, and computing core identifier.

[0118] In one possible implementation, the device further includes a grouping module, configured to: group the hardware working events according to the computing core identifier to obtain grouping results; and display the grouping results through a visualization interface, wherein the grouping results are used to analyze the parallel working state of the target processor.

[0119] In one possible implementation, determining the firmware scheduling overhead of each target task based on the first mapping relationship includes: obtaining firmware scheduling events for each target task within the target process started by the target application based on the first mapping relationship; determining the firmware scheduling overhead of each target task based on the firmware scheduling events of each target task; and determining the hardware operating overhead of each target task based on the second mapping relationship includes: obtaining hardware working events for each target task within the target process started by the target application based on the second mapping relationship; and determining the hardware operating overhead of each target task based on the hardware working events of each target task.

[0120] In one possible implementation, the determining module 32 is configured to: add the firmware scheduling overhead of each target task within the target process started by the target application to obtain a first result, and add the hardware operation overhead of each target task within the target process started by the target application to obtain a second result; sort the first result and the second result to obtain a sorting result; and determine the performance analysis result of the target processor based on the sorting result.

[0121] In one possible implementation, determining the performance analysis result of the target processor based on the sorting result includes: outputting a first prompt message as the performance analysis result of the target processor when the first result is ranked higher than the second result; and outputting a second prompt message as the performance analysis result of the target processor when the first result is ranked lower than the second result.

[0122] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0123] This disclosure also proposes a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the above-described method. The computer-readable storage medium can be volatile or non-volatile.

[0124] This disclosure also proposes an electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to execute the above-described method.

[0125] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0126] Electronic devices can be provided as terminals, servers, or other forms of devices.

[0127] Figure 4 A block diagram of an electronic device 1900 according to an embodiment of the present disclosure is shown. For example, the electronic device 1900 may be provided as a server or a terminal device. (Refer to...) Figure 4 The electronic device 1900 includes a processing component 1922, which further includes one or more processors, and memory resources represented by memory 1932 for storing instructions, such as application programs, that can be executed by the processing component 1922. The application programs stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1922 is configured to execute instructions to perform the methods described above.

[0128] Electronic device 1900 may also include a power supply component 1926 configured to perform power management of electronic device 1900, a wired or wireless network interface 1950 configured to connect electronic device 1900 to a network, and an input / output interface 1958. Electronic device 1900 can operate on an operating system stored in memory 1932, such as a server operating system or a graphical user interface-based operating system (OS X). TM ), a multi-user, multi-process computer operating system (Unix) TM Linux is a free and open-source Unix-like operating system. TM), an open-source Unix-like operating system (FreeBSD) TM (or similar.)

[0129] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions that can be executed by a processing component 1922 of an electronic device 1900 to perform the above-described method.

[0130] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0131] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, (but not limited to) electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0132] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0133] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0134] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0135] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0136] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

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

[0138] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0139] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0140] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0141] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

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

Claims

1. A performance analysis method, characterized in that, The method includes: Obtain the firmware scheduling overhead and / or hardware runtime overhead for each target task created by the target application, wherein the target application runs in an operating system, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor until the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task; The performance analysis results of the target processor are determined based on the firmware scheduling overhead and / or hardware operating overhead of each target task.

2. The method according to claim 1, characterized in that, Obtain the firmware scheduling overhead for each target task created by the target application, including: Acquire user-mode driver events and / or kernel-mode driver events, firmware scheduling events generated during the runtime of the target application; Map the user-mode driver events and / or the kernel-mode driver events and the firmware scheduling events to obtain a first mapping relationship; Based on the first mapping relationship, determine the firmware scheduling overhead for each target task; Obtain the hardware runtime overhead of each target task created by the target application, including: Acquire user-mode driver events and / or kernel-mode driver events, and hardware operation events generated during the runtime of the target application; The user-mode driver events and / or the kernel-mode driver events and the hardware working events are mapped to obtain a second mapping relationship; Based on the second mapping relationship, the hardware operating overhead of each target task is determined.

3. The method according to claim 2, characterized in that, Before running the target application in the operating system, the method further includes: Enable the first event tracking mechanism of the user-mode driver so that the user-mode driver writes the user-mode driver event to the log through the first event tracking mechanism. The user-mode driver event includes at least one of process identifier, task type, task identifier, timestamp, and user-mode task information. Acquiring the user-mode driven events generated during the runtime of the target application includes: Obtain the user-mode driven events generated by the target application during runtime from the logs.

4. The method according to claim 2, characterized in that, Before running the target application in the operating system, the method further includes: Enable the second event tracking mechanism for the kernel-mode driver, so that the kernel-mode driver writes kernel-mode driver events to the log through the second event tracking mechanism. The kernel-mode driver events include at least one of process identifier, task identifier, synchronization identifier, timestamp, and kernel-mode task information. Acquiring the kernel-mode driver events generated during the runtime of the target application includes: Obtain the kernel-mode driver events generated during the runtime of the target application from the logs.

5. The method according to claim 2, characterized in that, Acquiring the firmware scheduling event and the hardware operation event generated during the runtime of the target application, including: The firmware scheduling events and hardware operation events generated during the runtime of the target application are read from the kernel-mode buffer register using the callback interface. The firmware scheduling event includes at least one of process identifier, task identifier, synchronization identifier, timestamp, and scheduling status information; the hardware working event includes at least one of process identifier, task identifier, synchronization identifier, parallel strategy information, timestamp, and computing core identifier.

6. The method according to claim 5, characterized in that, The method further includes: The hardware operating events are grouped according to the computing core identifier to obtain the grouping results; The grouping results are displayed through a visual interface, and the grouping results shown are used to analyze the parallel working state of the target processor.

7. The method according to any one of claims 2 to 5, characterized in that, Based on the first mapping relationship, the firmware scheduling overhead for each target task is determined, including: Based on the first mapping relationship, obtain the firmware scheduling event of each target task within the target process started by the target application; Based on the firmware scheduling event of each target task, determine the firmware scheduling overhead of each target task; Based on the second mapping relationship, the hardware operating overhead of each target task is determined, including: Based on the second mapping relationship, obtain the hardware operation events of each target task within the target process started by the target application; The hardware operating overhead for each target task is determined based on the hardware operating events for each target task.

8. The method according to any one of claims 2 to 5, characterized in that, Based on the firmware scheduling overhead and hardware runtime overhead of each target task, the performance analysis results of the target processor are determined, including: The firmware scheduling overhead of each target task within the target process started by the target application is added together to obtain a first result, and, The hardware overhead of each target task within the target process started by the target application is added together to obtain a second result; Sort the first result and the second result to obtain the sorted result; Based on the sorting results, the performance analysis results of the target processor are determined.

9. The method according to claim 8, characterized in that, Based on the sorting results, the performance analysis results of the target processor are determined, including: If the first result is ranked higher than the second result, a first prompt message is output as the performance analysis result of the target processor. If the first result is ranked lower than the second result, a second prompt message is output as the performance analysis result of the target processor.

10. A performance analysis device, characterized in that, include: The acquisition module is used to acquire the firmware scheduling overhead and / or hardware runtime overhead of each target task created by the target application, wherein the target application runs in an operating system, the firmware scheduling overhead represents the time from when the target task is received from the hardware queue of the firmware of the target processor to when the hardware queue sends the target task to the target processor, and the hardware runtime overhead represents the time required for the target processor to execute the target task. The determination module is used to determine the performance analysis results of the target processor based on the firmware scheduling overhead and / or the hardware operation overhead of each target task.

11. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 9.

Images