Trace playback method, apparatus and electronic device

Abstract

This application discloses a method, apparatus, and electronic device for tracing trace replay. Applied to a master control unit, the master control unit controls trace replay in runtime environments of different agent types. The method includes: acquiring trace use cases; executing trace commands within the trace use cases to obtain replay data during GPU task execution, and analyzing GPU task performance metrics based on the replay data; wherein, when executing a target command within the trace command, the target command is encapsulated into a corresponding control request; the control request is sent to the scheduling execution unit in the target runtime environment currently performing trace replay, so that the scheduling execution unit parses the control request according to the scheduling requirements of the target runtime environment, and performs actual hardware access or task submission operations based on the parsing results; the control request is reused between runtime environments of different agent types.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of chip verification technology, and in particular to a method, apparatus, and electronic device for tracing and replaying traces. Background Technology

[0002] Chip verification is a crucial step in the chip development process, ensuring the correctness and reliability of the chip design. Related technologies utilize tracing mechanisms to collect instruction streams, data streams, and internal state information, and then use playback tools to reproduce fault scenarios offline for chip verification. Specifically, when reproducing fault scenarios offline using playback tools, the host machine can directly access hardware registers, allowing for register configuration, context recovery, and task submission.

[0003] However, when the operating environment is switched to a model simulation environment, a proxy firmware environment, or a production firmware environment, the host side cannot perform task submission and register access. If the fault is to be reproduced through the playback tool, it is necessary to develop corresponding playback entry points for different environments, or to stack a large number of environment judgment logics in the playback process, which makes the playback path complex, increases maintenance costs, and causes inconsistent playback behavior in different environments, resulting in a decrease in chip verification efficiency. Summary of the Invention

[0004] This application provides at least one method, apparatus, and electronic device for tracing and replaying traces.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a method for tracing and replaying traces. The method is applied to a master control unit, which controls trace replay in different agent-type runtime environments. The method includes: acquiring trace use cases; wherein the trace use cases include trace commands for executing graphics processing unit (GPU) tasks; executing the trace commands in the trace use cases to obtain replay data during GPU task execution, and analyzing the performance metrics of the GPU task based on the replay data; wherein, when executing a target command in the trace commands, the target command is encapsulated into a corresponding control request; the control request is sent to a scheduling execution unit in the target runtime environment currently performing trace replay, so that the scheduling execution unit parses the control request according to the scheduling requirements corresponding to the target runtime environment, and performs actual hardware access or task submission operations based on the parsing results; the target command is a trace command for executing hardware access or task submission operations; and the control request is reused between runtime environments of different agent types.

[0006] Secondly, embodiments of this application provide a Trace replay device, the device comprising: a unified replay entry point for acquiring Trace use cases; wherein the Trace use case includes a Trace command for executing a GPU task; by calling a unified proxy interface to execute the Trace command in the Trace use case, replay data during the execution of the GPU task is obtained, so as to analyze the performance indicators of the GPU task based on the replay data; wherein, when executing a target command in the Trace command, the target command is encapsulated into a corresponding control request through the unified proxy interface; the control request is sent to a scheduling execution unit in the target runtime environment currently performing Trace replay, so that the scheduling execution unit parses the control request according to the scheduling requirements corresponding to the target runtime environment, and performs actual hardware access or task submission operations based on the parsing result; the target command is a Trace command for executing hardware access or task submission operations; the control request is reused between runtime environments of different proxy types.

[0007] Thirdly, embodiments of this application provide an electronic device for executing the Trace playback method provided in embodiments of this application.

[0008] In this embodiment, on the one hand, by uniformly encapsulating the target command into a control request that can be reused in different operating environments through the main control terminal, only one set of Trace test case parsing and command encapsulation logic needs to be maintained. There is no need to develop separate playback entry points for model simulation environment, proxy firmware environment, and production firmware environment, which can reduce the workload of development and maintenance of playback tools. On the other hand, by sending the control requests reused in different operating environments to the scheduling execution unit, and having the scheduling execution unit complete the actual hardware access or task submission operation, the scheduling differences related to the operating environment can be pushed down to the scheduling execution unit, avoiding the stacking of a large number of environment judgment branches in the playback process, and ensuring that the playback logic behaves consistently in various operating environments; thereby improving chip verification efficiency.

[0009] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a trace playback method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a trace playback device provided in an embodiment of this application; Figure 3 This is a schematic diagram of another trace playback device provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a Trace playback method provided in an embodiment of this application. Figure 1 ; Figure 5 This is a flowchart illustrating a Trace playback method provided in an embodiment of this application. Figure 2 .

[0011] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0014] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0015] Currently, chip verification is a crucial step in the chip development process, ensuring the correctness and reliability of the chip design. Related technologies utilize tracing mechanisms to collect instruction streams, data streams, and internal state information, and then use playback tools to reproduce fault scenarios offline for chip verification. When reproducing fault scenarios offline using playback tools, the host machine can directly access hardware registers, allowing for register configuration, context recovery, and task submission.

[0016] Taking GPU (Graphics Processing Unit) as an example, existing trace playback systems typically employ a host-controlled playback path. First, the host-side playback tool reads the trace file, parsing the recorded GPU commands, register configurations, memory recovery information, and task submission information. Then, the host directly accesses the GPU's registers through memory-mapped MMIO (Memory-Mapped Input / Output) or PCIe (Peripheral Component Interconnect Express) configuration space to complete operations such as context initialization, virtual address space reconstruction, buffer filling, command submission, and result reading. In this mode, the host has full control over the underlying GPU hardware by default, without the need for firmware or driver intermediaries.

[0017] However, modern chip verification increasingly needs to be performed in a variety of heterogeneous operating environments, such as model simulation environments, proxy firmware environments, and production firmware environments.

[0018] In the model simulation environment, hardware registers are usually simulated as software interfaces. The host side cannot directly read or write them through physical addresses. Hardware behavior can only be triggered by calling through proxy firmware. If the host side direct control method is still used for register writing and task submission, it will not accurately reflect the actual hardware behavior, resulting in distorted playback results.

[0019] In a proxy firmware environment, the host side and the hardware device interact through a custom communication protocol. The proxy firmware can forward requests from the host side to the backend hardware, and the host side cannot bypass the proxy firmware to directly manipulate the registers.

[0020] In a production firmware environment, the actual firmware takes over all the underlying resources of the device, including register access permissions and task scheduling rights. The host side can only interact with the firmware indirectly through standard driver interfaces. Any direct register writes that bypass the firmware may trigger security protection mechanisms, violate firmware state machine constraints, or cause firmware crashes, rendering the firmware unusable in a normal production environment.

[0021] Therefore, to reproduce the fault using a playback tool in the aforementioned environments, one implementation approach is to develop separate playback entry points for different operating environments. Specifically, a playback tool based on the simulation API is developed for the model simulation environment, a playback tool based on a message channel is developed for the proxy firmware environment, and a playback tool based on a driver interface is developed for the production firmware environment. However, this approach suffers from inconsistent playback behavior across different environments due to the completely different underlying hardware interaction code, leading to increased maintenance costs and consequently reduced chip verification efficiency.

[0022] Another implementation approach involves stacking a large amount of environment-based decision-making logic within a single playback process. This means differentiating the current runtime environment through conditional branches within the same playback tool, and calling different register write functions or task submission functions based on the environment. However, with this approach, the number of conditional branches grows exponentially as the number of environments increases, leading to complex playback paths and decreased chip verification efficiency.

[0023] To address the aforementioned issues, this application proposes a method, apparatus, and electronic device for tracing and replaying traces.

[0024] On the one hand, by uniformly encapsulating target commands into reusable control requests in different operating environments through the main control terminal, only one set of Trace test case parsing and command encapsulation logic needs to be maintained. There is no need to develop separate playback entry points for model simulation environment, proxy firmware environment, and production firmware environment, which can reduce the workload of development and maintenance of playback tools. On the other hand, by sending reusable control requests in different operating environments to the scheduling execution unit, which completes the actual hardware access or task submission operation, the scheduling differences related to the operating environment can be pushed down to the scheduling execution unit, avoiding the stacking of a large number of environment judgment branches in the playback process, and ensuring that the playback logic behaves consistently in various operating environments; thereby improving chip verification efficiency.

[0025] Figure 1 This is a flowchart illustrating a trace playback method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method is applied to the master control end, which is used to control Trace replay in different agent types of runtime environments; the method includes the following steps.

[0026] Step S101: Obtain Trace test cases.

[0027] Among them, Trace use cases include Trace commands that execute GPU tasks.

[0028] In some embodiments, trace test cases can be pre-recorded hardware execution trajectory files, which may record instruction streams, data streams, register access sequences, memory operation information, and task submission events generated by the GPU during the execution of a specified task. Trace test cases can be read from local storage, network storage, or a cloud database by the host, or they can be captured and generated in real time by a test platform during chip testing.

[0029] Trace commands may include, but are not limited to, register write commands for configuring GPU running state, submit commands for starting or stopping tasks, interrupt or polling commands for synchronous waiting, and memory copy commands for restoring or saving context.

[0030] Step S102: Execute the Trace command in the Trace use case to obtain replay data during the execution of the GPU task, so as to analyze the performance indicators of the GPU task based on the replay data.

[0031] The replay data can be generated by the main control unit to reproduce the corresponding hardware operation or task scheduling behavior in the current running environment based on the type and semantics of each Trace command, thereby reflecting the execution status of the reproduced GPU task.

[0032] In this step, after the master control end obtains the Trace test case, the master control end can first reproduce the task-level initialization, scheduler startup and context preparation of the corresponding GPU task recorded by the Trace test case in the original execution process, so that the replay of the GPU task enters the executable state.

[0033] In some embodiments, the Trace use case may include an initialization class Trace command sequence preceding the execution main command. The host can parse the initialization class Trace command sequence preceding the execution main command from the Trace use case. This initialization class Trace command sequence is the configuration pipeline generated by the driver or firmware at the initial stage of task distribution when recording the GPU task. Furthermore, context preparation can be performed on the scheduling execution unit side of the current runtime environment, enabling the playback of the GPU task to enter an executable state.

[0034] In some embodiments, the Trace use case also includes operation log data of the GPU task execution. For one or more Trace use cases to be replayed, an execution unit corresponding to each Trace use case can be created; and within each execution unit, the execution context, virtual memory, and related buffers are restored based on the operation log data; finally, a unified replay entry point can be invoked to execute the Trace commands in the Trace use case. In this embodiment, after the playback of the GPU task enters the executable state, the main control terminal can create a corresponding execution unit based on each obtained Trace test case; wherein, the execution unit is a logical execution entity allocated by the main control terminal for a single Trace test case, which is used to perform state management and execution control of the Trace test case throughout the entire playback process.

[0035] After creating the corresponding execution unit, it can initialize and pre-configure itself based on the operation log data in the Trace use case. This operation log data may include, but is not limited to, initialization configuration data and context recovery data. The execution unit can then send the initialization configuration data and context recovery data to the scheduling execution unit in the current runtime environment to restore the execution context, virtual memory, and related buffers in the target runtime environment. After completing the initialization and data sending, it indicates that the GPU task execution context, virtual memory, and related buffers corresponding to the Trace use case have been fully restored in the target runtime environment, and subsequent main Trace commands can begin execution.

[0036] It should be noted that after the execution context, virtual memory, and related buffers corresponding to the Trace test case have been restored in the target runtime environment, the master control terminal can execute the Trace command for the subsequent main body by calling the unified replay entry.

[0037] The unified playback entry point can be a standardized execution interface provided by the main control terminal for all Trace use cases. This interface can shield the differences in the underlying operating environment, so that the main control terminal does not need to care about whether it is in the model simulation environment, the proxy firmware environment or the production firmware environment when executing the main Trace command.

[0038] During the execution of Trace commands through the unified playback entry point on the master control end, when non-target commands in the Trace commands are executed, they can be processed locally on the master control end and logged. When the target command in the Trace commands is executed, the target command can first be encapsulated into a corresponding control request. Then, the control request can be sent to the scheduling execution unit in the target runtime environment where Trace playback is currently being performed, so that the scheduling execution unit can parse the control request according to the scheduling requirements corresponding to the target runtime environment, and perform actual hardware access or task submission operations based on the parsing results.

[0039] The target command is the Trace command that performs hardware access or task submission operations; control requests are reused between runtime environments of different agent types.

[0040] In the implementation, the master control unit executes the Trace command by calling the unified playback entry point, without directly performing hardware access or task submission operations. When executing the target command, the unified playback entry point can call the unified proxy interface, which encapsulates the target command into an abstract control request that is independent of the specific environment. This control request only contains semantic information such as operation type, target address, and data payload, without any details related to the underlying hardware implementation. Therefore, its format is consistent across different proxy types, allowing the control request to be reused across different proxy types.

[0041] The actual hardware operations are performed by the scheduling and execution unit within the target runtime environment; the master control unit does not need to be aware of the implementation process. The scheduling and execution unit is an entity running within the target runtime environment, responsible for receiving control requests and executing the actual hardware operations.

[0042] In some embodiments, the scheduling execution unit may have pre-configured request parsing logic and hardware driver interface that match the current agent type. When the scheduling execution unit receives a control request through the scheduling agent control path, it can first extract semantic information such as operation type, target address, and data payload from the request; then, the scheduling execution unit can map the above semantic information into environment-specific hardware operation instructions or task submission descriptors according to the scheduling requirements of the current target runtime environment.

[0043] For example, mapping methods for different proxy types include: In the meta-agent environment included in the model simulation environment, the scheduling execution unit can receive requests through the IPC processing thread inside the meta-agent firmware, map the operation type to the register configuration sequence under the meta-agent scenario, and complete hardware access through the internal scheduler.

[0044] In the RISC proxy environment included in the proxy firmware environment, the scheduling execution unit converts the target address and data payload into register write instructions or task submission descriptors that can be recognized by the RISC side through the shared cache read request of the RISC proxy firmware, and triggers the execution of the RISC computing core.

[0045] In the production firmware environment, the scheduling execution unit directly calls the internal interface provided by the production firmware ring to transform the control request into a task submission control operation in the production environment.

[0046] Once the mapping is complete, the scheduling execution unit can perform the corresponding actual hardware access or task submission operation.

[0047] In this way, the unified replay entry point is only used to execute the scheduling execution unit that receives Trace commands, determines the command type, encapsulates control requests, and sends the control requests to the target runtime environment. The unified replay entry point does not contain any environment-related conditional branches, nor is it aware of the specific type of the current runtime environment. Therefore, no matter how the target runtime environment changes, the code logic of the unified replay entry point remains unchanged, which can decouple the main control end replay logic from the underlying runtime environment. This allows the unified replay entry point to shield the differences between the model simulation environment, the proxy firmware environment, and the production firmware environment.

[0048] In some embodiments, the target command can first be parsed to extract the operation parameters carried in the target command; then the operation parameters can be filled into the corresponding fields in the preset control request structure to generate a control request.

[0049] The operation parameters include at least one of operation type, register address, write value, and data width.

[0050] In this embodiment, the preset control request structure is defined by a unified proxy interface, which is used to unify different types of hardware access or task submission operations into an abstract request format that is independent of the specific environment.

[0051] The default control request structure includes at least the following fields: operation type, target address, write value, data width, multi-core mask, and timeout flag. The operation type identifies the specific type of request, including but not limited to GPU register write, command engine register write, multi-core register write, and task submission; the target address indicates the address of the register to be accessed or the submission queue identifier; the write value carries the data to be written to the register; the data width indicates the bit width of the register access; and the multi-core mask specifies the target core set in a multi-core write scenario.

[0052] In some embodiments, when parsing a target command, the host terminal can first identify the operation type to which the target command belongs.

[0053] For example, if the target command is a GPU register write command, the register address, write value, and data width can be extracted; if the target command is a multi-core register write command, the multi-core mask can also be extracted; if the target command is a task submission command, parameters such as the submission queue identifier and command descriptor address can be extracted. Subsequently, the master control terminal fills the extracted operation parameters into the corresponding positions according to the field definitions of the preset control request structure, thus completing the encapsulation of the control request.

[0054] After encapsulation, the control request contains only semantic information such as operation type, target address, and data payload, without any details related to the underlying hardware implementation. The master control unit can send the control request to the scheduling execution unit through the control path corresponding to the current target runtime environment. The scheduling execution unit then performs the actual hardware access or task submission operation within the target runtime environment.

[0055] By using the above method, different types of hardware operations can be unified into the same request encapsulation process through a unified proxy interface. This allows the upper-layer unified playback entry point to not need to care about the specific implementation of the underlying operations, further decoupling the playback logic from the runtime environment.

[0056] By adopting the above technical solution, on the one hand, by uniformly encapsulating the target command into a control request that can be reused in different operating environments through the main control terminal, only one set of Trace test case parsing and command encapsulation logic needs to be maintained. There is no need to develop separate playback entry points for model simulation environment, proxy firmware environment, and production firmware environment, which can reduce the workload of development and maintenance of playback tools. On the other hand, by sending the control request that can be reused in different operating environments to the scheduling execution unit, and having the scheduling execution unit complete the actual hardware access or task submission operation, the scheduling differences related to the operating environment can be pushed down to the scheduling execution unit, avoiding the stacking of a large number of environment judgment branches in the playback process, ensuring that the playback logic behaves consistently in various operating environments; thereby improving chip verification efficiency.

[0057] In some embodiments, the master control terminal and the scheduling execution unit communicate through a control path; the control path is established according to the agent type of the target operating environment; the control request is sent to the scheduling execution unit through the communication method provided by the control path that matches the agent type, so as to realize the communication between the master control terminal and the scheduling execution unit.

[0058] Among them, the communication methods that match the agent type can include, but are not limited to, shared memory communication, inter-process communication (IPC), and firmware interface calls.

[0059] For example, when the agent type is a meta-agent, the control path can use inter-process communication (IPC); when the agent type is a Reduced Instruction Set Computing (RISC-V) agent, the control path can use shared memory combined with IPC; when the agent type is a production firmware environment, the control path uses firmware interface calls.

[0060] In this embodiment, the control path can provide different communication methods according to the agent type to adapt to the communication requirements of different scheduling execution units. After the control request reused in the runtime environment of different agent types is sent to the scheduling execution unit through the control path, the scheduling execution unit can parse the control request according to its own agent type and perform the corresponding actual hardware access or task submission operation.

[0061] During execution, the master control unit can determine whether each Trace command in the Trace test case is a target command requiring hardware access or task submission. If the current command is determined to be a target command, the master control unit can extract the operation type, operation object, and operation parameters of that target command and encapsulate them into a control request according to a preset unified format.

[0062] After encapsulation, the master control unit does not directly perform hardware access or task submission. Instead, it submits the control request to the currently established control path. The control path, based on the agent type of the current target operating environment, uses the corresponding communication method to send the control request to the scheduling execution unit.

[0063] After receiving a control request, the scheduling execution unit parses the various fields in the control request in a unified format and executes the corresponding actual operation based on the parsing results.

[0064] Using the above technical solution, the main control unit employs the same encapsulation logic and control request format throughout the entire playback process, adapting to different underlying communication methods only through the control path. In this way, the main trace playback process of the main control unit can remain consistent and reusable across different agent types of runtime environments.

[0065] Existing trace playback systems differ in model simulation environments, proxy firmware environments, and production firmware environments due to variations in communication methods, shared buffers, logging mechanisms, and submission control methods between the master control unit and the firmware. In this solution, the master control unit can execute trace commands through a unified playback entry point. However, when sending control requests to the scheduling execution unit, a communication channel matching the current target operating environment is required to ensure that the control requests can be correctly received, parsed, and executed by the scheduling execution unit.

[0066] If the communication channel is not pre-established according to the operating environment, the unified playback entry cannot reuse the same set of logic in different environments. It is still necessary to introduce an environment judgment branch in the playback process, or to implement different request sending logic for different environments, which results in the inability to decouple the playback logic of the main control end from the underlying operating environment.

[0067] Therefore, in some embodiments, the method further includes the steps S103 and S104.

[0068] Step S103: Obtain playback configuration.

[0069] The replay configuration specifies the target runtime environment and corresponding agent type for the current Trace replay. The replay configuration can be user-inputted information via command-line parameters, configuration files, or a graphical interface; it includes at least the following: target runtime environment identifier, agent type, firmware file path, log output parameters, and agent control interface type.

[0070] In this step, the master control terminal can obtain the playback configuration before starting the playback process and parse the playback configuration to extract the proxy type.

[0071] In some embodiments, replay configuration can be obtained through a unified configuration entry point.

[0072] In some embodiments, the unified configuration entry point can refer to the configuration location used to read scheduling agent-related parameters before or during playback. The unified configuration entry point neither directly executes playback nor directly accesses the firmware; instead, it provides information on which scheduling mode should be used for this playback. At the start of playback, the master control unit can first read the unified configuration entry point to obtain the scheduling agent-related parameters required for this playback.

[0073] The replay configuration includes, but is not limited to, whether to enable the scheduling agent, agent type, firmware file path, firmware log dictionary path, log mask, loader timeout parameters, and log polling parameters. Among them, the agent type is used to indicate the target runtime environment for the current trace replay, including but not limited to the model simulation environment, agent firmware environment, or production firmware environment. The agent firmware environment is, for example, a meta-agent or a Reduced Instruction Set Architecture (RISC-V) agent.

[0074] In actual execution, the master control terminal can determine whether a scheduling agent is enabled by reading the scheduling agent option in the unified configuration entry. If enabled, it can further identify the current agent type. Based on the identified agent type, the master control terminal can determine the firmware file path, log parameters, and corresponding communication method to be loaded.

[0075] Step S104: Based on the agent type in the playback configuration, construct the control path between the master control terminal and the scheduling execution unit.

[0076] This is because in model simulation environments, proxy firmware environments, and production firmware environments, the main control terminal cannot directly access the underlying hardware and must indirectly complete hardware operations through firmware or proxy firmware. The communication methods between the main control terminal and the firmware differ in different operating environments. Therefore, it is necessary to establish a control path between the main control terminal and the firmware that matches the current target operating environment, and this path corresponds to the proxy type of the current target operating environment.

[0077] By adopting the above technical solution, the proxy type in the playback configuration is obtained during the playback startup phase, and a control path matching the current operating environment is constructed accordingly. Communication differences between different operating environments are handled before the main playback loop. This allows the unified playback entry point to transparently send control requests through the constructed control path without being aware of underlying environment differences. Furthermore, it eliminates the need to develop separate playback entry points for each operating environment and avoids stacking numerous environment judgment branches in the playback process. When adding a new operating environment, only the corresponding proxy type and path construction logic need to be added to the configuration; the main playback process remains unchanged. This enables the playback system to flexibly adapt to different firmware scheduling modes.

[0078] In some embodiments, the corresponding scheduling execution unit can first be loaded based on the agent type in the playback configuration; then a control path can be constructed between the master control unit and the scheduling execution unit.

[0079] In this embodiment, since the construction of the control path requires the establishment of information based on the scheduling execution unit, the corresponding scheduling execution unit can be loaded first based on the proxy type in the playback configuration; then the control path between the master control terminal and the scheduling execution unit can be constructed.

[0080] In some embodiments, the firmware and firmware loading methods included in the scheduling execution unit differ in runtime environments of different agent types. For model simulation environments, the scheduling execution unit can be a simulation model or a proxy firmware; for proxy firmware environments, the scheduling execution unit is the proxy firmware itself; for production firmware environments, the scheduling execution unit is the actual firmware.

[0081] Therefore, the master control unit can determine the image file path, load address, startup parameters, and other information of the scheduling execution unit based on the agent type by looking up a table or searching other files with mapping relationships. After loading the image or module of the scheduling execution unit into the memory space of the target runtime environment, the scheduling execution unit can be triggered to start running.

[0082] Once the scheduling execution unit is loaded, an entity capable of receiving control requests will exist in the target runtime environment. At this point, the control path between the master control unit and the scheduling execution unit can be constructed.

[0083] By adopting the above technical solution, by first loading the scheduling execution unit, the main control terminal can obtain the communication information exposed by the scheduling execution unit after startup. The main control terminal can accurately match each component of the control path based on this communication information. Moreover, after the control path is constructed, the main control terminal can send control requests through a unified playback entry point without needing to know whether the scheduling execution unit is running in a model simulation environment, a proxy firmware environment, or a production firmware environment, thus ensuring the consistency of the main playback process.

[0084] In some embodiments, the communication method between the master control terminal and the scheduling execution unit can be determined according to the agent type; and a control path between the master control terminal and the scheduling execution unit can be constructed according to the communication method.

[0085] The communication methods include at least one of the following: inter-process communication (IPC), direct access to hardware registers, and system call interface.

[0086] In this embodiment, when the proxy type indicates that the current running environment is a model simulation environment or a proxy firmware environment, the communication method adopts IPC inter-process communication; when the proxy type indicates that the current running environment is a production firmware environment and the main control terminal has direct access to the hardware, the communication method adopts direct access to hardware registers; when the proxy type indicates that the current running environment is a production firmware environment and the main control terminal and the firmware run in the same operating system kernel space, the communication method adopts system call interface.

[0087] In some embodiments, the control path may refer to the runtime communication path established between the master control unit and the scheduling execution unit. This runtime communication path may be a runtime communication environment composed of or dependent on shared memory regions, IPC communication objects, firmware interface information, register access request formats, task submission control paths, and firmware log output paths.

[0088] In actual execution, the shared memory region is a shared storage space used by the master control terminal and the scheduling execution unit to exchange control requests, status information or execution results. This shared memory region is jointly mapped by the master control terminal and the scheduling execution unit after the firmware is loaded.

[0089] IPC communication objects are communication entities used to send control requests between the master control unit and the scheduling execution unit. Control requests include register access requests, task submission requests, etc.

[0090] Firmware interface information is a set of information used to determine how the master control terminal communicates with the current firmware, including but not limited to communication address, interface handle, available operation types, etc.

[0091] The register access request format is the same as the format used when encapsulating requests in the unified proxy interface. The request can carry information such as register address, write value, data width, operation type, and multi-core mask.

[0092] The task submission control path is the communication path through which task submission requests are sent from the master control unit to the scheduling execution unit, and the scheduling execution unit performs scheduling or submission control.

[0093] The firmware log output path is used to obtain firmware-side logs at the end of playback or during execution, to help confirm the firmware-side execution status and troubleshoot problems.

[0094] It should be noted that the specific implementations of shared memory regions, IPC communication objects, firmware interface information, register access request formats, task submission control paths, and firmware log output paths differ under different communication methods. The control path can encapsulate the communication differences under different operating environments in its internal implementation and provide a consistent call view to the upper layer.

[0095] By adopting the above technical solution, the determination of the communication method is separated from the main playback process, so that environmental differences are only processed in the control path construction stage. The subsequent unified playback entry and unified proxy interface do not need to be aware of the changes in the underlying communication method, thereby ensuring the uniformity of the main playback process.

[0096] It should be noted that the control path may also include a firmware log output path. Therefore, if the replay data during the execution of the GPU task is obtained, the firmware log can be obtained through the firmware log output path in the control path, and the firmware operation can be stopped.

[0097] In some embodiments, during or after playback execution, the master control terminal can obtain firmware runtime logs from the scheduling execution unit via the firmware log output path in the control path. After obtaining the firmware logs, the master control terminal can confirm the execution status of the firmware, verify the correctness of the playback results, and troubleshoot any abnormal issues that occur during playback. Simultaneously, after playback ends, the master control terminal can also send a stop command to the scheduling execution unit via the control path to control the firmware or proxy firmware to stop running, release the system resources it occupies, and complete the final stages of the entire playback process.

[0098] By using the above method, firmware log output and playback data acquisition can be integrated into the same control loop, so that host-side playback data and firmware-side execution logs can be obtained simultaneously after playback, providing chip verification personnel with a more complete basis for troubleshooting.

[0099] In some embodiments, where the communication method includes inter-process communication (IPC), the scheduling execution unit includes proxy firmware. Therefore, when a control request is sent to the scheduling execution unit in the target runtime environment through the control path corresponding to the target runtime environment currently performing Trace playback, the IPC buffer address allocated by the proxy firmware can be obtained first, and the IPC channel can be initialized based on the IPC buffer address; then, the control request can be encapsulated into an IPC message; and then, the IPC message can be sent to the proxy firmware through the IPC channel.

[0100] In this embodiment, after the proxy firmware is loaded, it can provide the host terminal with the buffer address required for its IPC communication. After the host terminal obtains the buffer address, it can initialize the IPC channel, which may include, but is not limited to, mapping shared memory regions, setting message formats, and initializing synchronization mechanisms.

[0101] After initialization, the master control unit can further encapsulate the control requests packaged by the unified proxy interface into message formats conforming to the IPC protocol, and send them to the proxy firmware through the established IPC channel. Upon receiving the IPC message, the proxy firmware can parse the control request from the IPC message to perform the actual register access or task submission operation, and return the execution result to the master control unit through the same IPC channel.

[0102] For example, in a meta-proxy scenario, after the master control terminal loads the meta-proxy firmware, the firmware allocates an IPC buffer during startup and provides the address of this IPC buffer to the master control terminal. After obtaining this address, the master control terminal initializes the meta-proxy IPC channel, including mapping shared memory regions, setting message formats, and establishing synchronization mechanisms. After initialization, when the master control terminal needs to perform register access or task submission operations, the unified proxy interface first encapsulates the operation into a unified format control request. Then, the master control terminal further encapsulates this control request into a message format conforming to the meta-proxy IPC protocol and sends it to the meta-proxy firmware through the established IPC channel. Upon receiving the IPC message, the meta-proxy firmware parses the control request, performs the actual register access or task submission operation, and returns the execution result to the master control terminal through the same IPC channel.

[0103] Using the above technical solution, the specific type of proxy firmware and the differences in IPC protocol are encapsulated in the internal implementation of the control path, and the unified playback entry and unified proxy interface of the master control end do not need to be aware of these differences.

[0104] In some embodiments, where the communication method includes inter-process communication (IPC), the scheduling execution unit includes RISC-V firmware. When a control request is sent to the scheduling execution unit in the target runtime environment via the control path corresponding to the target runtime environment currently performing Trace playback, a shared buffer can be allocated first; then, a RISC-V proxy IPC channel can be initialized based on the shared buffer; next, register access requests and scheduling control requests can be encapsulated into IPC messages; finally, the IPC messages can be sent to the RISC-V firmware via the RISC-V proxy IPC channel.

[0105] In this embodiment, before performing Trace playback, the master control unit can first allocate a shared buffer in the target runtime environment. This shared buffer is used for exchanging control requests, status information, and execution results between the master control unit and the RISC-V firmware. After the shared buffer is allocated, the master control unit can initialize the RISC-V proxy IPC channel based on this shared buffer, which may include, but is not limited to, setting message formats, synchronization mechanisms, and communication protocols.

[0106] After initialization, when the master control unit needs to perform register access or task submission operations, it can first encapsulate the operation into a control request that can be reused across different agent types of runtime environments through the unified agent interface. Then, the master control unit further encapsulates the control request into a message format conforming to the RISC-V agent IPC protocol and sends it to the RISC-V firmware through the initialized RISC-V agent IPC channel. After receiving the IPC message, the RISC-V firmware parses the control request, performs the actual register access or scheduling control operation, and returns the execution result to the master control unit through the same IPC channel.

[0107] For example, in a RISC-V Proxy scenario, the master controller first allocates a shared buffer, loads the RISC-V firmware, and then initializes the RISC-V Proxy IPC channel. Afterward, register access and scheduling control requests are sent via this RISC-V Proxy IPC channel. Similarly, the master controller first encapsulates the operations into a unified format control request, then encapsulates it into a message format conforming to the RISC-V Proxy IPC protocol, and sends it to the RISC-V firmware through the initialized IPC channel. The RISC-V firmware then performs the actual hardware operations and returns the results.

[0108] Using the above technical solution, the specific type of proxy firmware and the differences in IPC protocol are encapsulated in the internal implementation of the control path, and the unified playback entry and unified proxy interface of the master control end do not need to be aware of these differences.

[0109] The description of the above device-side embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0110] Figure 2 This is a schematic diagram of the structure of a trace playback device provided in an embodiment of this application, as shown below. Figure 2 As shown, the Trace playback device 200 includes a unified playback entry point 201 and a unified proxy interface 202. In this embodiment, the playback device 200 includes a host-side device for executing the control program for Trace playback.

[0111] The unified replay entry point 201 is used to obtain Trace use cases; among them, Trace use cases include Trace commands that execute graphics processing unit (GPU) tasks; by executing the Trace commands in the Trace use cases, replay data during the execution of the GPU task is obtained, so as to analyze the performance indicators of the GPU task based on the replay data; When the target command in the Trace command is executed, the unified replay entry 201 encapsulates the target command into a corresponding control request through the unified proxy interface 202; and sends the control request to the scheduling execution unit in the target running environment where Trace replay is currently being performed, so that the scheduling execution unit can parse the control request according to the scheduling requirements of the target running environment, and perform actual hardware access or task submission operations based on the parsing results. The target command is the Trace command that performs hardware access or task submission operations; the control request has a consistent format across different agent types.

[0112] In some embodiments, such as Figure 3 As shown, the device also includes a unified configuration entry 203 and an initialization module 204; wherein, the unified configuration entry 203 is used to obtain the playback configuration; wherein, the playback configuration is used to indicate the target runtime environment and the corresponding agent type for the current Trace playback; the initialization module 204 is used to load the corresponding scheduling execution unit based on the agent type in the playback configuration; and to construct the control path between the playback device and the scheduling execution unit.

[0113] The following describes the application of the Trace playback method provided in this application in a real-world scenario, mainly involving a GPU playback control method that combines firmware scheduling.

[0114] Existing trace replay systems typically employ a single host-based replay path. The basic execution method is as follows: the host-side replay tool reads the trace file, parses the commands, register configurations, memory recovery information, and task submission information; then, the host directly performs context initialization, virtual memory recovery, register writing, task submission, and result reading. In other words, in traditional trace replay systems, the host-side tool usually assumes it can directly control the GPU's register configuration and task submission process.

[0115] The single path discussed here refers to the existing trace playback system process, which mainly relies on the host side directly controlling the hardware or model side interface. That is, trace parsing, register access, and task submission are all organized around the host-controlled path. This path is suitable for simple replay scenarios, but problems arise when the runtime environment changes. In model environments, proxy firmware environments, or production firmware environments, task submission and register access cannot always be directly completed by the host side.

[0116] In model simulation environments, proxy firmware is needed to simulate or take over some scheduling behaviors; in production firmware scenarios, task submission and scheduling paths need to be as close as possible to the actual hardware operation mode and cannot completely bypass the firmware; under different firmware types, the communication methods, shared buffers, logging mechanisms and submission control methods between the host and the firmware are also different.

[0117] If the host-controlled single path described above is still used, one of the following two situations will occur: First, it is necessary to develop independent playback entry points for different operating environments, such as host direct control playback, meta-proxy firmware playback, production firmware playback, RISC-V proxy firmware playback, etc.; Second, a large number of environment judgment branches are stacked in the same playback process, resulting in the logic of register access, task submission, log output, etc. being scattered in different branches, making it difficult to guarantee the consistency of behavior in different environments.

[0118] Therefore, the deficiency of the existing technology is not that it "cannot replay traces", but that when trace playback needs to adapt to different firmware scheduling environments, there is a lack of a control method to converge the environmental differences to the scheduling agent layer while keeping the upper trace playback main process consistent.

[0119] The difference between the embodiments proposed in this application and related technologies is that the embodiments proposed in this application do not maintain a complete replay path for each operating environment, but select the corresponding firmware scheduling mode according to the configuration during the replay startup phase, and continue to reuse the unified trace parsing, context preparation, command processing and execution process after the firmware or scheduling agent initialization is completed.

[0120] Figure 4 This is a flowchart illustrating a Trace playback method provided in an embodiment of this application. Figure 1 ,like Figure 4 As shown, the method may include: a differentiated firmware initialization layer and a unified trace playback main link.

[0121] For the first layer, the differentiated firmware initialization layer.

[0122] Step S301: Read the scheduling agent options in the unified configuration entry.

[0123] When playback starts, the master control unit first reads the trace playback configuration and finds the relevant configuration area of ​​the scheduling agent in the configuration.

[0124] Step S302: Determine if the firmware scheduling agent is enabled, and obtain the agent type. The agent type includes, but is not limited to, meta agent, RISC-V agent, production firmware, etc.

[0125] Step S303: Based on the identified agent type, read or select the corresponding firmware file path, log parameters, and communication method.

[0126] The firmware file path comes from the path field corresponding to the agent type in the configuration and is used to locate the firmware file to be loaded; the log parameters come from the log path, log switch, log level or log polling parameters in the configuration; the communication method is selected by the system according to the agent type to implement the corresponding internal communication, such as inter-process communication, shared buffer communication, firmware interface call, etc.

[0127] Step S304: Load the corresponding firmware or agent module.

[0128] In some embodiments, the corresponding type of firmware or agent module is loaded into the runtime environment.

[0129] Step S305: Establish a control path between the host-side playback tool and the firmware or proxy firmware. This layer allows for differences in operating environments, and all environment-related initialization logic is completed at this layer.

[0130] In some embodiments, a communication channel (such as an IPC channel or a shared buffer) is established between the master control terminal and the firmware for subsequent sending of control requests and receiving of logs.

[0131] For the second layer, a unified trace playback main link is used.

[0132] Step S306: Read the trace test cases to be replayed.

[0133] In some embodiments, the host device reads the Trace file to be replayed.

[0134] Step S307: Create a trace execution unit.

[0135] In some embodiments, an independent execution unit is created for each Trace use case to achieve isolation between use cases.

[0136] Step S308: Initialize the context.

[0137] In some embodiments, the execution context of a GPU task is initialized within the execution unit.

[0138] Step S309: Restore virtual memory and buffers.

[0139] In some embodiments, the virtual address mapping and related buffer contents are restored based on the operation record data in the Trace.

[0140] Step S310: Create a command processor.

[0141] In some embodiments, processing logic is established for parsing and executing Trace commands.

[0142] Step S311: Execute the tracking command.

[0143] In some embodiments, Trace commands are parsed and executed sequentially; if a command involves hardware access or task submission, the process proceeds to S312.

[0144] Step S312: Complete register access and task submission through the unified proxy interface.

[0145] In some embodiments, requests such as register access and task submission are encapsulated into control requests in a unified format and sent to the firmware via the control path established by S305, so that the firmware can complete the actual hardware operation.

[0146] Step S313: Output the log and close the loop after the playback is complete.

[0147] In some embodiments, after playback ends, firmware logs are collected and output uniformly, resources are released, and firmware operation is stopped.

[0148] Through the two-layer architecture described above, this embodiment does not require all operating environments to be completely identical. Instead, the differences are limited to the firmware loading and proxy communication initialization phases. Once the trace execution phase begins, the upper-layer replay process still uses the same main link. Thus, register access, task submission, and log output under different operating environments are all completed through a unified proxy interface. There is no need to maintain a separate replay entry point for each environment, nor is it necessary to stack environment judgment branches in the main replay process.

[0149] This application embodiment includes a unified configuration entry point, a scheduling agent control path, a unified agent interface, and a unified playback entry point. This application embodiment implements a GPU trace playback control method combined with firmware scheduling through the unified configuration entry point, scheduling agent control path, unified agent interface, and unified playback entry point.

[0150] In this embodiment, the unified configuration entry point refers to the configuration location used to read relevant parameters of the scheduling agent before or during playback. This configuration entry point is the playback configuration file, which does not directly execute playback or directly access the firmware, but provides information on which scheduling mode should be used for this playback.

[0151] The unified configuration entry should include at least the following information: whether the scheduling agent is enabled, agent type, firmware file path, firmware log dictionary path, log mask, loader timeout parameters, and log polling parameters.

[0152] For example, when the scheduling agent is enabled in the configuration and the agent type is specified as meta agent, the system enters the loading and initialization process of the meta agent firmware; when the agent type is RISC-V agent, the system enters the loading and initialization process of the RISC-V agent firmware.

[0153] In this embodiment, the scheduling agent control path refers to the runtime communication path established between the host-side playback tool and the firmware or agent firmware. This control path is formed after configuration identification and firmware loading, and is used to carry control request and response interactions between the host and the firmware.

[0154] It should be noted that the scheduling agent control path does not store all information in a single data structure. Rather, it refers to the fact that the control path is composed of or depends on the following elements during its establishment and operation: 1. Shared memory area after firmware loading: used for exchanging control requests, status information or execution results between the host-side playback tool and the firmware or proxy firmware.

[0155] 2. Inter-process communication objects: Used to send control requests between the host side and the firmware or proxy firmware, such as register access requests, task submission requests, etc.

[0156] 3. Firmware interface information: Used to determine how the host communicates with the current firmware, such as communication address, interface handle, available operation types, etc.

[0157] 4. Register access request format: This is the format used when encapsulating requests in the unified proxy interface. The request can carry information such as register address, write value, data width, operation type, and multi-core mask.

[0158] 5. Task Submission Control Path: This refers to the communication path from the host-side playback tool to the firmware or proxy firmware, and from which the firmware or proxy firmware performs scheduling or submission control.

[0159] 6. Firmware log output path: Used to obtain firmware-side logs at the end of playback or during execution, to help confirm the firmware-side execution status and troubleshoot problems.

[0160] For example, in the meta-proxy scenario, after loading the meta-proxy firmware, the system obtains the inter-process communication buffer address and initializes the meta-proxy inter-process communication channel. Then, the host-side playback tool sends register access requests to the proxy firmware through this inter-process communication channel. In the RISC-V proxy scenario, the system first allocates a shared buffer, loads the RISC-V firmware, and then initializes the RISC-V proxy inter-process communication channel. Afterward, register access and scheduling control requests are sent via this RISC-V proxy inter-process communication channel.

[0161] It's important to note that the host-side replay tool doesn't bypass the interface to directly send control requests to the proxy firmware. Instead, when the host-side replay main process requires register access or task submission, it first calls the unified proxy interface. The unified proxy interface encapsulates the operation into a unified control request. Then, the unified proxy interface sends this control request to the proxy firmware through the inter-process communication path or scheduling proxy control path corresponding to the current proxy type. Upon receiving the request, the proxy firmware performs the actual register access or scheduling control and returns the result. Therefore, the inter-process communication path is the underlying communication path, and the unified proxy interface is the upper-level call entry point; they are hierarchical, not replacements.

[0162] In this embodiment, the unified proxy interface is an access interface used to shield communication differences between different firmware during playback. It is neither the playback entry point nor the configuration entry point, but rather an interface used during playback execution to initiate register access, command engine register access, multi-core register writes, and commit control.

[0163] The unified proxy interface can shield the differences between different firmware by using a unified upper-layer calling format and an underlying distribution based on proxy type. In some embodiments, for the upper-layer trace playback process, the same unified proxy interface is called regardless of the firmware currently used. After receiving requests such as register access, task submission, and multi-core write, this interface first encapsulates these operations into control requests that can be reused between runtime environments of different proxy types. The control requests include information such as access address, write value, data width, operation type, and multi-core mask. Then, based on the proxy type determined at the start of playback, the corresponding underlying control path is selected. Differences in communication methods, shared buffers, inter-process communication objects, log paths, etc., between different firmware are all handled in the underlying control path, and the upper-layer trace playback process does not need to be adapted to different firmware.

[0164] Therefore, masking differences does not mean that all firmware implementations are the same, but rather that the upper-layer playback process sees the same interface and the same request semantics; the communication details of different firmware are handled by the proxy type distribution and control path under the unified proxy interface.

[0165] In this embodiment, the unified replay entry point refers to the upper-level main replay process entry point used to execute trace test cases after firmware initialization. It is responsible for trace test case traversal, context initialization, memory recovery, command processing, and trace execution.

[0166] In summary, the unified configuration entry point is used to select the agent type and determine which scheduling mode to use for this replay; the scheduling agent control path is used to establish the communication path between the host and the firmware and to carry the transmission of control requests; the unified agent interface is used to shield the differences in register access and submission control between different firmware and to provide a consistent calling interface to the upper layer; and the unified replay entry point is used to execute the main process of trace replay and is responsible for parsing and executing trace test cases.

[0167] By adopting the above technical solution, the embodiments of this application, through the above layered design, can identify the agent type and load the corresponding firmware through a unified configuration entry point during the playback startup phase, and establish a scheduling agent control path; during the playback execution phase, the communication differences between different firmware are shielded through a unified agent interface, so that the unified playback entry point can reuse the same set of playback main processes under different agent types, without having to develop a separate playback entry point for each environment, and without having to stack environment judgment branches in the playback main process.

[0168] Figure 5 This is a flowchart illustrating a Trace playback method provided in an embodiment of this application. Figure 2 ,like Figure 5 As shown, the method may include the following steps.

[0169] Step 401: Identify the scheduling agent type.

[0170] In this step, the master control unit can read the playback configuration to identify the agent type corresponding to the target runtime environment currently performing Trace playback; wherein, the agent type includes at least one of the following: model simulation environment, meta agent firmware environment, RISC-V agent firmware environment, or production firmware environment.

[0171] Step 402: Determine the firmware path and control interface.

[0172] In this step, the master control terminal can determine the corresponding firmware file path, log parameters, and communication method between the master control terminal and the scheduling execution unit based on the identified agent type; the communication method includes at least one of inter-process communication (IPC), direct access to hardware registers, and system call interface.

[0173] Step 403: Load firmware or agent module.

[0174] In this step, the master control unit can load the corresponding scheduling execution unit based on the agent type; the scheduling execution unit includes agent firmware or RISC-V firmware, and after loading, the scheduling execution unit becomes an entity that can receive control requests.

[0175] Step 404: Complete GPU initialization, scheduler startup, and context preparation.

[0176] In this step, the host completes the GPU initialization configuration and starts the scheduler in the target runtime environment. It also restores the execution context, virtual memory and related buffers based on the operation record data in the Trace test case, so that the Trace playback can enter the executable state.

[0177] Step 405: Perform trace playback one by one.

[0178] In this step, the master control unit executes the Trace commands in the Trace test cases one by one through the unified playback entry point to obtain the playback data during the execution of the GPU task; when the target command is executed, the target command is encapsulated into the corresponding control request.

[0179] Step 406: Complete register access and commit control through the unified proxy interface, and output firmware log and stop firmware after completion.

[0180] In this step, the master control unit encapsulates register access requests and task submission requests into control requests that can be reused between different proxy types of runtime environments through a unified proxy interface, and sends them to the scheduling execution unit through the control path corresponding to the current target runtime environment. The scheduling execution unit then performs the actual hardware access or task submission operation. If playback data is obtained, the firmware log is obtained through the firmware log output path in the control path, and the firmware operation is stopped.

[0181] Through the above scheme, the embodiments of this application can firstly reduce maintenance complexity by switching different firmware scheduling paths through a unified configuration entry point; secondly, the same replay main chain can be reused under different agent types to enhance trace replay consistency; and thirdly, register access, commit control and firmware log output can be uniformly incorporated into the same control closed loop to improve troubleshooting capabilities.

[0182] This application also proposes an electronic device for performing the Trace playback method in the above embodiments.

[0183] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0184] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0185] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0186] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0187] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0188] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0189] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0190] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for tracing and replaying traces, characterized in that, The method is applied to a master control terminal, which is used to control trace playback in different agent type runtime environments; the method includes: Obtain Trace use cases; wherein, the Trace use cases include Trace commands that execute graphics processing unit (GPU) tasks; Execute the Trace command in the Trace use case to obtain replay data during the execution of the GPU task, and analyze the performance indicators of the GPU task based on the replay data; Specifically, when the target command in the Trace command is executed, the target command is encapsulated into a corresponding control request; the control request is sent to the scheduling execution unit in the target running environment where Trace playback is currently being performed, so that the scheduling execution unit parses the control request according to the scheduling requirements corresponding to the target running environment, and performs actual hardware access or task submission operations based on the parsing results; The target commands include Trace commands that perform hardware access or task submission operations; the control requests are reused between runtime environments of different agent types.

2. The method according to claim 1, characterized in that, The master control terminal and the scheduling execution unit communicate through a control path; the control path is established according to the agent type of the target operating environment; the control request is sent to the scheduling execution unit through a communication method provided by the control path that matches the agent type.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the replay configuration; wherein, the replay configuration is used to indicate the target runtime environment and the corresponding proxy type for the current Trace replay. Based on the agent type in the playback configuration, a control path is constructed between the master control terminal and the scheduling execution unit.

4. The method according to claim 3, characterized in that, The construction of the control path between the master control terminal and the scheduling execution unit based on the proxy type in the playback configuration includes: The corresponding scheduling execution unit is loaded based on the agent type in the replay configuration; Establish a control path between the main control terminal and the scheduling execution unit.

5. The method according to claim 4, characterized in that, The construction of the control path between the main control terminal and the scheduling execution unit includes: Based on the agent type, the communication method between the master control terminal and the scheduling execution unit is determined; wherein, the communication method includes at least one of inter-process communication (IPC), direct access to hardware registers, and system call interface; A control path is constructed between the master control terminal and the scheduling execution unit according to the communication method.

6. The method according to claim 5, characterized in that, The method further includes: If the replay data during the GPU task execution is obtained, the firmware log is acquired through the firmware log output path in the control path, and the firmware operation is stopped.

7. The method according to claim 5, characterized in that, When the communication method includes inter-process communication (IPC), the scheduling execution unit includes proxy firmware; sending the control request to the scheduling execution unit in the target runtime environment currently performing Trace playback includes: Obtain the IPC buffer address allocated by the proxy firmware, and initialize the IPC channel based on the IPC buffer address; The control request is encapsulated as an IPC message; The IPC message is sent to the proxy firmware via the IPC channel.

8. The method according to claim 5, characterized in that, When the communication method includes IPC, the scheduling execution unit includes Reduced Instruction Set Architecture (RISC-V) firmware; sending the control request to the scheduling execution unit in the target runtime environment currently performing Trace playback includes: Allocate a shared buffer; Initialize the RISC-V proxy IPC channel based on the shared buffer; Encapsulate register access requests and scheduling control requests into IPC messages; The IPC message is sent to the RISC-V firmware through the RISC-V proxy IPC channel.

9. The method according to any one of claims 1 to 7, characterized in that, The Trace use case also includes operation log data of GPU task execution; the method also includes: For one or more Trace test cases to be replayed, create an execution unit corresponding to each Trace test case; In each execution unit, the execution context, virtual memory, and related buffers are restored based on the operation record data, and a unified replay entry is invoked to execute the Trace command in the Trace use case within the context of the execution unit.

10. The method according to any one of claims 1 to 7, characterized in that, The step of encapsulating the target command into a corresponding control request includes: The target command is parsed to extract the operation parameters carried in the target command; wherein, the operation parameters include at least one of operation type, register address, write value, and data width; The operation parameters are filled into the corresponding fields in the preset control request structure to generate the control request.

11. A trace playback device, characterized in that, The device includes: A unified replay entry point is used to obtain Trace use cases; wherein, the Trace use case includes a Trace command for executing a graphics processing unit (GPU) task; the Trace command in the Trace use case is executed to obtain replay data during the execution of the GPU task, so as to analyze the performance indicators of the GPU task based on the replay data; When the target command in the Trace command is executed, the unified replay entry encapsulates the target command into a corresponding control request through a unified proxy interface; the control request is sent to the scheduling execution unit in the target running environment where Trace replay is currently being performed, so that the scheduling execution unit parses the control request according to the scheduling requirements corresponding to the target running environment, and performs actual hardware access or task submission operations based on the parsing results; The target command is a Trace command that performs hardware access or task submission operations; the control request is reused between runtime environments of different agent types.

12. The trace playback device according to claim 11, characterized in that, The device also includes a unified configuration entry point and an initialization module; wherein... The unified configuration entry is used to obtain the replay configuration; wherein, the replay configuration is used to indicate the target runtime environment and the corresponding proxy type for the current Trace replay. The initialization module is used to load the corresponding scheduling execution unit based on the proxy type in the playback configuration; and to construct a control path between the playback device and the scheduling execution unit.

13. An electronic device, characterized in that, The electronic device is used to perform the method according to any one of claims 1 to 10.

Images