Graphical processor (GPU) performs playback method, system and device of trajectory

Abstract

The present disclosure provides a method, system and device for playing back a GPU execution track, wherein the method comprises: for a plurality of playback tasks corresponding to a plurality of GPU execution tracks to be executed, creating a corresponding asynchronous execution unit for each playback task; performing a preprocessing operation of the playback task corresponding to each asynchronous execution unit in parallel, and in response to determining that the preprocessing operation of each asynchronous execution unit has been completed, starting an execution process of the plurality of playback tasks. This method makes full use of software and hardware resources, improves the test efficiency of a large number of track playback, and effectively guarantees the reproducibility of track playback.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a method for replaying the execution trajectory of a graphics processing unit (GPU), a system for replaying the execution trajectory of a GPU, a device for replaying the execution trajectory of a GPU, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the widespread application of GPUs (Graphics Processing Units) in graphics rendering and general computing, issues such as GPU driver anomalies and hardware compatibility defects are becoming increasingly common. GPU trajectory capture and playback are crucial testing methods for verifying GPU functionality and locating software and hardware anomalies. Current technologies mostly employ a serial playback mode for batch regression testing of multiple execution trajectory directories, where one playback task finishes before the next begins. While this approach is simple to implement in small-scale scenarios, it struggles to fully utilize multi-queue resources. Furthermore, when the playback system already possesses multi-queue capabilities, continuing with a serial approach prevents idle queues from receiving new playback tasks in a timely manner, meaning multi-queue resources cannot be utilized concurrently in a timely manner. Summary of the Invention

[0003] This disclosure provides a method, system, device, electronic device, computer-readable storage medium, and computer program product for replaying the execution trajectory of a graphics processing unit (GPU).

[0004] In a first aspect, embodiments of this disclosure propose a method for replaying the execution trajectory of a graphics processing unit (GPU), comprising: creating a corresponding asynchronous execution unit for each of the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed; executing the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit in parallel; and, in response to determining that the preprocessing operations of each asynchronous execution unit have been completed, initiating the execution process of the multiple replay tasks.

[0005] Secondly, this disclosure proposes a GPU execution trajectory replay system, comprising: a script layer and a scheduling layer. The script layer is used to traverse each GPU execution trajectory directory and filter out GPU execution trajectory files that meet preset conditions; generate a replay task for each GPU execution trajectory file and send the replay task to the scheduling layer; the scheduling layer is used to create a corresponding asynchronous execution unit for each replay task corresponding to the multiple GPU execution trajectories to be executed; execute the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit in parallel; and, in response to determining that the preprocessing operations of each asynchronous execution unit have been completed, start the execution process of multiple replay tasks.

[0006] Thirdly, embodiments of this disclosure provide a playback device for GPU execution trajectories, including a creation module and a task initiation module. The creation module is configured to create a corresponding asynchronous execution unit for each playback task corresponding to multiple GPU execution trajectories to be executed. The task initiation module is configured to execute preprocessing operations of the playback tasks corresponding to each asynchronous execution unit in parallel, and in response to determining that the preprocessing operations of each asynchronous execution unit have been completed, initiate the execution process of the multiple playback tasks.

[0007] Fourthly, embodiments of this disclosure provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method for replaying the execution trajectory of a graphics processing unit (GPU) as described in any implementation of the first aspect.

[0008] Fifthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that, when executed by a processor, enable a method for replaying the execution trajectory of a graphics processing unit (GPU) as described in any implementation of the first aspect.

[0009] In a sixth aspect, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the method for replaying the execution trajectory of a graphics processing unit (GPU) as described in any implementation of the first aspect.

[0010] According to the technical solution provided in the embodiments of this disclosure, for multiple playback tasks corresponding to multiple GPU execution trajectories to be executed, a corresponding asynchronous execution unit is created for each playback task; then, the preprocessing operations of the playback tasks corresponding to each asynchronous execution unit are executed in parallel, and in response to determining that the preprocessing operations of each asynchronous execution unit have been completed, the execution process of multiple playback tasks is started.

[0011] By configuring an asynchronous execution unit independently for each playback task, performing preprocessing in parallel, and waiting for all units to be ready before starting the execution process of each playback task, it is possible to achieve mutual isolation of multi-task preprocessing and prevent cross-contamination of hardware states; the unified triggering of task execution process ensures that the timing of multiple trajectory playbacks is controllable, making full use of hardware and software resources, thereby improving the testing efficiency of large-scale trajectory playback, while effectively ensuring the reproducibility of trajectory playback.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a method for replaying GPU execution trajectories provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating another method for replaying GPU execution trajectories provided in this embodiment of the disclosure; Figure 3 A flowchart illustrating yet another method for replaying GPU execution trajectories provided in this disclosure embodiment; Figure 4 A flowchart illustrating another method for replaying GPU execution trajectories provided in this embodiment of the disclosure; Figure 5 A structural block diagram of a GPU execution trajectory playback system provided in this disclosure embodiment; Figure 6 A structural block diagram of a GPU execution trajectory playback device provided in this embodiment of the present disclosure; Figure 7 This is a schematic diagram of the structure of an electronic device suitable for a method of replaying GPU execution trajectories, provided in an embodiment of this disclosure. Detailed Implementation

[0014] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0015] This disclosure relates to the field of computer technology, specifically to a method for replaying GPU execution trajectories, a system for replaying GPU execution trajectories, a device for replaying GPU execution trajectories, electronic devices, computer storage media, and program products. It is applicable to scenarios such as GPU driver regression testing, GPU hardware verification, continuous integration testing of graphics rendering engines, and reproduction of graphics application anomalies.

[0016] In graphics rendering systems, GPU trajectory capture and playback are important testing methods for verifying GPU functionality and locating software and hardware anomalies.

[0017] Currently, some trajectory replay solutions lack hierarchical scheduling capabilities in batch testing scenarios, making it difficult to automatically traverse multiple execution trajectory directories in batches. Furthermore, most solutions employ a serial replay approach, executing each trajectory sequentially, resulting in lengthy testing cycles and low efficiency. In other trajectory replay solutions, the few implementations supporting concurrent replay employ rudimentary scheduling strategies that fail to incorporate CPU (Central Processing Unit) computing power and GPU hardware queue resources for rate limiting. This leads to situations where a large number of replay tasks are created at once, preempting hardware and software resources, which can easily cause memory overflow, driver crashes, and task interference, resulting in poor system stability. Moreover, existing solutions lack robust resource isolation and state protection mechanisms; when multiple replay tasks are executed concurrently, the residual GPU pipeline states and register values ​​from previous tasks can easily contaminate subsequent tasks.

[0018] Therefore, existing trajectory playback solutions mainly suffer from problems such as the inability to utilize multi-queue resources concurrently in a timely manner and the lack of a controlled concurrency mechanism based on the number of queues in batch playback scenarios.

[0019] The following description of several optional embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0020] Please refer to Figure 1 , Figure 1 A flowchart of a method for replaying GPU execution trajectories provided in this disclosure embodiment is included, wherein process 100 includes the following steps: Step 101: For the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed, create a corresponding asynchronous execution unit for each replay task.

[0021] In this embodiment, the execution entity is the scheduling layer (also known as the scheduler), which is a software scheduling entity located downstream of the script layer and above the GPU hardware. It is implemented by software modules and does not correspond to independent hardware. It undertakes the replay tasks issued by the script layer and is responsible for core scheduling logic such as task queuing, resource evaluation, asynchronous execution unit creation, and task status management.

[0022] The scheduling layer continuously receives GPU execution trajectory replay tasks from the upper script layer or continuous integration layer. It should be noted that the GPU execution trajectory replay task is an independent scheduling unit built on a single execution trajectory file. It is used to restore the GPU instruction execution process during the trajectory capture phase. By restoring the hardware state saved in the trajectory file, the GPU instructions recorded in the trajectory are executed in sequence to reproduce the GPU's running behavior under the target business scenario.

[0023] When multiple replay tasks are received, the scheduling layer first performs a validity check on each task, eliminating invalid tasks with abnormal parameters, and then stores the valid replay tasks that pass the check into the set of tasks to be executed for queuing management. For each replay task in the set of tasks to be executed, the scheduling layer loads its corresponding execution trajectory file, extracts the GPU context snapshot, hardware register snapshot, and timing hardware command parameters retained during the capture phase, and uniquely binds the above snapshot information to the replay task as the baseline running environment for trajectory replay.

[0024] The scheduling layer then iterates through the GPU hardware queue resource pool, matching idle GPU hardware queues based on the trajectory type. Successfully matched queues are marked as occupied, and a binding relationship is established between the replay task and the corresponding queue. After resource matching and parameter binding are complete, the scheduling layer creates independent asynchronous execution units for each replay task. Each asynchronous execution unit corresponds one-to-one with a replay task, serving only the current single replay task and not being reused after the task ends. The scheduling layer loads the task identifier, bound context snapshot, register configuration, hardware command parameters, and GPU hardware queue handle into the corresponding asynchronous execution unit. All asynchronous execution units enter a ready state, awaiting the scheduling layer's start command to begin subsequent preprocessing in parallel.

[0025] Step 102: Execute the preprocessing operations of the playback tasks corresponding to each asynchronous execution unit in parallel. In response to the determination that the preprocessing operations of each asynchronous execution unit have been completed, start the execution process of multiple playback tasks.

[0026] In this embodiment of the disclosure, the scheduling layer sends a preprocessing start instruction to all ready asynchronous execution units. Multiple asynchronous execution units run on the CPU and execute the preprocessing operations corresponding to their respective bound playback tasks in parallel. The running spaces of each asynchronous execution unit are isolated from each other, and the execution processes do not interfere with each other.

[0027] Each asynchronous execution unit first performs a pre-wait operation, continuously monitoring the running status of the bound GPU hardware queue until the queue is completely empty, thereby avoiding interference from hardware states left over from previous tasks. After completing the wait, the asynchronous execution unit performs a task preparation operation, reading the GPU context snapshot and hardware register snapshot bound to the playback task, and calling the driver interface to complete the hardware state restoration, so that the GPU hardware running environment is aligned with the baseline state of the trajectory capture phase.

[0028] During the preprocessing process, the scheduling layer will poll and monitor the working status of all asynchronous execution units in real time, continuously collect the preprocessing completion signals of each unit, until all asynchronous execution units have completed the preprocessing operation, and uniformly trigger the batch instruction issuance process, thereby avoiding resource disorder and state pollution caused by the premature execution of a single task.

[0029] When the scheduling layer determines that all asynchronous execution units have returned a preprocessing completion flag, it means that the preprocessing work for each replay task has been completed, and processed data ready for submission has been generated. The scheduling layer then generates an execution trigger instruction and sends it to each asynchronous execution unit to start the execution process of each replay task, allowing each asynchronous execution unit to submit the corresponding data to the bound GPU hardware queue and trigger the replay execution on the GPU side.

[0030] According to the GPU execution trajectory replay method provided in this disclosure, for multiple replay tasks corresponding to multiple GPU execution trajectories to be executed, an asynchronous execution unit is first created for each replay task. Then, the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit are executed in parallel. In response to determining that the preprocessing operations of each asynchronous execution unit have been completed, the execution process of multiple replay tasks is started. In this way, by configuring asynchronous execution units independently for each replay task, performing preprocessing in parallel, and waiting for all units to be ready before starting the execution process of the replay task, the mutual isolation of multi-task preprocessing can be achieved, preventing cross-contamination of hardware states; unified triggering of instruction submission ensures the controllability of the replay sequence of multiple trajectories, and makes full use of hardware and software resources, thereby improving the testing efficiency of large-scale trajectory replay, while effectively ensuring the reproducibility of trajectory replay.

[0031] Please refer to Figure 2 , Figure 2 A flowchart of another method for replaying GPU execution trajectories provided in this disclosure embodiment, wherein process 200 includes the following steps: Step 201: For the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed, create a corresponding asynchronous execution unit for each replay task.

[0032] Step 202: Perform the preprocessing operations of the playback tasks corresponding to each asynchronous execution unit in parallel.

[0033] Steps 201-202 above and as follows Figure 1 The steps 101-102 shown are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0034] Step 203: Generate GPU instruction data corresponding to multiple playback tasks based on the preprocessing operation.

[0035] In this embodiment of the disclosure, the scheduling layer reads the original GPU execution trajectory information and the restored hardware environment parameters obtained from the preprocessing stage, parses and transforms the hardware operation events recorded in the trajectory, converts the operation semantics of the trajectory record into the underlying instruction format that the GPU can recognize, and encapsulates the GPU instruction data corresponding to the playback task so that the scheduling layer can subsequently deliver the GPU instruction data to the bound GPU hardware queue.

[0036] Step 204: In response to the determination that the preprocessing operations of each asynchronous execution unit have been completed, the GPU instruction data corresponding to the multiple playback tasks are sent to the GPU hardware queues bound to the multiple playback tasks respectively, so that the multiple GPU hardware queues can execute their respective bound playback tasks in parallel.

[0037] In this embodiment, if it is determined that the preprocessing operations of each asynchronous execution unit have been completed, the scheduling layer will perform a targeted instruction distribution operation, accurately pushing each set of GPU instruction data to the dedicated GPU hardware queue pre-bound to the playback task. The instruction data of different playback tasks are distributed independently and are not mixed with each other. Each GPU hardware queue receives the matching instruction data in real time and, based on its own hardware scheduling logic, queues and executes the corresponding GPU instructions in the original time sequence. Multiple GPU hardware queues start working simultaneously relying on GPU parallel computing resources, each independently executing the entire instruction flow of the bound playback task, realizing hardware-level parallel playback execution of multi-track playback tasks, completely reproducing the GPU rendering and computing behavior of each track capture stage, maintaining execution isolation of each hardware queue throughout the process, and eliminating state interference and data crosstalk during the concurrent execution of multiple tasks.

[0038] According to the GPU execution trajectory replay method provided in this disclosure, independent asynchronous execution units are configured for multiple replay tasks to perform preprocessing work in parallel and generate corresponding GPU instruction data. After all preprocessing is completed, the generated GPU instruction data is uniformly distributed to the corresponding GPU hardware queues for execution. This achieves task decoupling, ensures isolation between multiple replay tasks, and enables hardware-level parallel replay by relying on GPU hardware queues. This improves the processing efficiency of large-scale GPU execution trajectory replay while ensuring the consistency of trajectory replay timing and execution environment, and reducing mutual interference caused by multi-task concurrency.

[0039] Please refer to Figure 3 , Figure 3 A flowchart of another GPU execution trajectory playback method provided in this disclosure embodiment, wherein process 300 includes the following steps: Step 301: For the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed, add the replay tasks to the set of tasks to be executed, and determine the concurrent scheduling threshold of the set of tasks to be executed based on the GPU hardware queue information and system resource information.

[0040] In this embodiment, the scheduling layer receives batches of GPU execution trajectory replay tasks, iterates through all replay tasks, and adds them to the set of tasks to be executed for unified maintenance. The scheduling layer also records basic information such as the trajectory file path and estimated resource overhead associated with each replay task. Furthermore, the scheduling layer collects system hardware resource information in real time, including the total number of available GPU hardware queues, the current load of each queue, the remaining video memory capacity, and the CPU and memory usage on the host side. Simultaneously, it reads the estimated resource consumption indicators for each replay task. Then, considering both the hardware queue capacity and the system resource availability, it dynamically calculates and determines the concurrent scheduling threshold (which can also be called the concurrent window or concurrent window size) for the set of tasks to be executed, thereby limiting the number of replay tasks executed concurrently in a single run. This prevents resource contention and queue congestion caused by exceeding the concurrency limit, providing controllable constraints for subsequent batch scheduling of replay tasks.

[0041] In some optional implementations of the embodiments of this disclosure, step 301 above may be performed as follows: determining the total capacity of the hardware queue based on the type of GPU hardware queue and the available number of each queue; determining system resource information based on the available memory information, video memory balance and CPU core count of the current device; and determining the concurrent scheduling threshold of the set of tasks to be executed based on the total capacity and system resource information.

[0042] In this implementation, the scheduling layer identifies GPU hardware queues of different functional types and counts the number of queue instances in idle and allocable states for each type, summing up the total hardware queue capacity as the upper limit of the hardware channel for task concurrency. Simultaneously, the scheduling layer collects runtime metrics in real time, reading available physical memory on the host, remaining memory capacity of each GPU card, and the number of idle CPU cores, integrating these to generate system resource information. Then, the scheduling layer compares the total hardware queue capacity with the remaining system resources to identify the most critical resource bottleneck and comprehensively calculates and determines the concurrent scheduling threshold for the set of tasks to be executed, constraining the upper limit of a single parallel replay task. This combined approach of hardware queue capacity and system resources determines the concurrency threshold, locks in resource bottlenecks, and reasonably controls the number of parallel tasks, preventing resource contention, queue blocking, and replay failures caused by multi-task concurrency, while also avoiding resource overload and ensuring stable replay execution.

[0043] Step 302: Create a corresponding asynchronous execution unit for each playback task.

[0044] Step 303: Perform the preprocessing operations of the playback tasks corresponding to each asynchronous execution unit in parallel, and generate GPU instruction data corresponding to multiple playback tasks based on the preprocessing operations.

[0045] Steps 302-303 above are similar to... Figure 2 The steps 201-203 shown are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0046] Step 304: In response to determining that the preprocessing operations of each asynchronous execution unit have been completed and the number of replay tasks in the set of tasks to be executed has reached the concurrent scheduling threshold, the GPU instruction data corresponding to the multiple replay tasks are sent to their respective bound GPU hardware queues so that the multiple GPU hardware queues can execute their respective bound replay tasks in parallel.

[0047] The scheduling layer continuously monitors the running status of all asynchronous execution units within this batch, continuously receiving preprocessing completion signals reported by each asynchronous execution unit to confirm that all asynchronous execution units have completed preprocessing work such as hardware state restoration and GPU instruction encapsulation. Simultaneously, it continuously counts the number of ready replay tasks in the set of tasks to be executed and compares it with the pre-calculated concurrent scheduling threshold. When it is confirmed that all preprocessing by each asynchronous execution unit is complete and the number of ready replay tasks reaches the concurrent scheduling threshold, the scheduling layer executes a batch instruction distribution operation. Based on the binding mapping relationship between each replay task and the GPU hardware queue, it pushes the GPU instruction data corresponding to each replay task to its dedicated bound GPU hardware queue. After receiving the instruction data, each GPU hardware queue independently schedules hardware resources to execute the instructions. Multiple GPU hardware queues operate simultaneously, executing their respective bound replay tasks in parallel.

[0048] This allows for the determination of concurrent scheduling thresholds based on hardware queues and system resources, reasonable control of task concurrency scale, and the issuance of instructions after all asynchronous execution units are ready for preprocessing and the number of tasks reaches the target. This enables the orderly initiation of parallel playback, preventing resource overload and improving the stability of batch playback and the utilization rate of hardware resources.

[0049] Step 305: Insert a synchronization fence after the GPU instruction data in the GPU hardware queue.

[0050] After submitting the GPU instruction data for the corresponding playback task to the GPU hardware queue, a synchronization barrier is then inserted at the end of the instruction stream of the queue. The synchronization barrier is a synchronization marker instruction inserted into the GPU hardware instruction stream and is deployed at the end of all GPU instructions in a single batch of playback tasks. The GPU hardware queue executes instructions sequentially, and the synchronization barrier is only set to the completed state and outputs a feedback signal after the queue has executed all GPU instructions before the barrier.

[0051] After the queue has completed the operation of all instructions in this batch, the synchronization barrier triggers a completion signal, which can be used by the next batch of asynchronous execution units for polling and judgment. This achieves execution isolation between batches and prevents state crosstalk between replay tasks of different batches.

[0052] Step 306: Determine the execution status of the playback task based on the feedback signal from the synchronization barrier and the drive exception information.

[0053] The scheduling layer continuously collects feedback signals from the synchronization fence output within the GPU hardware queue, and simultaneously receives various abnormal information reported by the GPU driver, namely driver abnormal information. Here, driver abnormal information is reported by the GPU driver program and is used to characterize various abnormal states generated during the operation of the GPU hardware, including memory access errors, instruction execution failures, hardware queue timeouts, computing unit errors, resource out-of-bounds errors, and other operational abnormality indicators.

[0054] The scheduling layer combines two pieces of information to determine the execution status of the replay task: if the synchronization barrier returns a completion signal and there is no driver exception, the replay task is determined to have been executed normally; if the synchronization barrier does not return a completion signal for a long time, or receives driver error, video memory access exception, or other information, the task execution is determined to have timed out or run abnormally, which facilitates subsequent handling operations such as task retry and resource reclamation.

[0055] By inserting synchronization barriers at the end of GPU instructions, the execution progress of hardware instructions can be accurately obtained; this, combined with driver exception information that characterizes hardware anomalies, is used to determine the task status. Thus, it can both identify whether instructions have been completed and capture hardware malfunctions, avoiding misjudgments caused by a single signal and improving the accuracy of task playback result determination.

[0056] In some optional implementations of the embodiments of this disclosure, step 306 above may be performed as follows: in response to determining that the feedback signal is a completion signal and no driver exception information is received, the execution status of the playback task is determined to be successful; or in response to not receiving a feedback signal and not receiving driver exception information, the execution status of the playback task is determined to be timeout; or in response to not receiving a feedback signal and receiving driver exception information, the execution status of the playback task is determined to be failed.

[0057] In this implementation, the scheduling layer continuously collects feedback signals from the synchronization barrier and driver exception information pushed by the GPU driver, and performs logical judgments. Specifically, if the synchronization barrier feedback signal is a completion signal and no driver exception information is captured, the replay task execution status is determined to be successful; if no synchronization barrier completion signal is obtained for a long time, and no driver exception information is found, the replay task execution status is determined to be timed out; if neither a synchronization barrier completion signal nor driver exception information indicating a GPU hardware failure is received, the replay task execution status is determined to be failed. This allows the scheduling layer to perform subsequent processing such as resource reclamation and task retry based on different statuses. Thus, by distinguishing between the three task statuses of success, timeout, and failure through multi-dimensional conditions, the judgment logic is clear, accurately identifying various operating conditions, and facilitating differentiated subsequent handling by the scheduling layer.

[0058] Step 307: In response to determining that the execution status of any one of the multiple replay tasks is timed out or failed, determine that the execution result of the multiple replay tasks is failed.

[0059] In this implementation, the scheduling layer continuously monitors the execution status of each replay task across multiple replay tasks. Once any replay task is identified as having timed out or failed, the overall execution result of all concurrent replay tasks is determined to be a failure, triggering corresponding handling procedures. These procedures include terminating remaining tasks, reclaiming occupied GPU hardware queue resources, and outputting batch replay failure logs, thus uniformly handling the exception. By determining the entire batch execution as failed based on any timeout or failure of any task within multiple replay tasks, batch replay anomalies can be detected promptly, resource reclamation and exception handling can be quickly triggered, ensuring the controllability of the scheduling process and avoiding the unnecessary and continuous occupation of hardware resources.

[0060] Step 308: In response to determining that the execution status of all replay tasks is successful, and the execution result of multiple replay tasks is successful; release the binding relationship between multiple replay tasks and the GPU hardware queue, release the resources occupied by each asynchronous execution unit, and clear the set of tasks to be executed.

[0061] In this implementation, the scheduling layer iterates through the execution status of all replay tasks one by one, performing integrity checks. When it is confirmed that the execution status of all replay tasks is successful, the overall execution result of the current batch of concurrent replay tasks is considered successful. At this point, the scheduling layer initiates a batch resource cleanup process, which involves sequentially unbinding the mapping relationship between each replay task and its bound GPU hardware queue, releasing the hardware queue's occupied permissions; reclaiming the memory resources such as task context and cached data held by each asynchronous execution unit, and destroying the running instances of the asynchronous execution units; simultaneously clearing the set of tasks to be executed corresponding to this round, removing the task records in the set, completing the entire process of this batch, releasing all hardware and software resources, and supporting the normal scheduling of the next batch of replay tasks. After all tasks in the batch have been successfully executed, resource release and data cleanup are carried out uniformly, unbinding tasks from hardware queues, reclaiming asynchronous execution unit resources, and clearing the task set. This achieves efficient resource reuse and prevents leaks caused by continuous occupation of memory and hardware resources.

[0062] According to the GPU execution trajectory replay method provided in this disclosure, the scale of parallel tasks is reasonably controlled by combining the GPU hardware queue and system resources to calculate the concurrent scheduling threshold. The replay task preprocessing is completed in parallel using asynchronous execution units to generate GPU instruction data. Once all preprocessing is complete and the number of tasks meets the threshold, instructions are batch-issued to the bound GPU hardware queue, thereby achieving hardware parallel replay. Furthermore, by inserting a synchronization fence at the end of the instruction and combining the fence feedback signal with driver anomaly information to accurately determine the execution status of a single task, the entire process achieves layered decoupling between preprocessing and hardware execution, orderly scheduling of GPU hardware resources, and timely identification of various operational anomalies. This improves the concurrency efficiency, timing controllability, and operational stability of batch trajectory replay, effectively avoiding resource overload and status misjudgment problems.

[0063] Please refer to Figure 4 , Figure 4 A flowchart of another method for replaying GPU execution trajectories provided in this disclosure embodiment, wherein process 400 includes the following steps: Step 401: For the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed, assign a task identifier to each replay task and extract runtime environment data from the GPU execution trajectory file corresponding to the replay task.

[0064] In this embodiment, after receiving multiple GPU execution trajectory replay tasks, the scheduling layer assigns a unique task identifier to each replay task for full lifecycle tracking and result tracing. The scheduling layer locates the corresponding execution trajectory file based on the task's associated path, parses and extracts the runtime environment data stored during the capture phase, including at least a GPU context snapshot, a hardware register configuration snapshot, and timing-based hardware command parameters. Then, the scheduling layer binds the aforementioned runtime environment data and the task identifier to the replay task, providing baseline data support for subsequent preprocessing, instruction assembly, and hardware replay.

[0065] Step 402: Create a corresponding asynchronous execution unit for the replay task, and load the task identifier, runtime environment data, and handle of the GPU hardware queue bound to the replay task into the asynchronous execution unit.

[0066] After the scheduling layer completes the allocation of unique identifiers for replay tasks, extraction of trajectory file runtime environment data, matching of idle GPU hardware queues, and establishment of binding relationships between replay tasks and GPU hardware queues, it will create a dedicated asynchronous execution unit for the current replay task. There is a one-to-one correspondence between replay tasks and asynchronous execution units, and each asynchronous execution unit is isolated from each other and only serves this replay task.

[0067] The scheduling layer loads the unique task identifier of the replay task, the GPU context snapshot obtained from the execution trajectory file, the hardware register configuration, hardware command parameters, and other runtime environment data, as well as the GPU hardware queue handle bound to the replay task, into the internal cache of the asynchronous execution unit. The asynchronous execution unit saves all configuration information, completes its own initialization, and then enters a ready-to-go state, waiting for the scheduling layer to issue a start command to perform preprocessing operations.

[0068] Assigning a unique identifier to each playback task facilitates full-process traceability; extracting the fixed operating environment data within the trajectory file ensures a unified playback benchmark; furthermore, creating asynchronous execution units one-to-one achieves task isolation, loading various parameters into the unit, enabling each task's preprocessing process to execute independently, avoiding mutual interference between tasks, and improving the reproducibility of trajectory playback.

[0069] Step 403: Perform the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit in parallel, and generate GPU instruction data corresponding to multiple replay tasks based on the preprocessing operations.

[0070] The above steps 403 and as follows Figure 2 Steps 202-203 shown are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0071] In some optional implementations of the embodiments of this disclosure, the above preprocessing operation includes: for each asynchronous execution unit, configuring the current GPU hardware state according to the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit.

[0072] In this implementation, after the scheduling layer issues the start command, each asynchronous execution unit begins to execute preprocessing operations in parallel. For each asynchronous execution unit, it retrieves the playback task data from the internal cache, reads the corresponding GPU context and hardware register configuration information, calls the driver interface, and sequentially configures environmental parameters such as rendering pipeline binding relationships, frame buffer parameters, texture and shader association states, depth testing, and color blending methods. It also sets the values ​​of each register one by one, restoring the hardware state corresponding to the bound GPU hardware queue to the baseline state of the trajectory capture stage.

[0073] Furthermore, the step 403 above, which generates GPU instruction data corresponding to multiple playback tasks based on the preprocessing operation, can be executed as follows: generate GPU instruction data corresponding to the playback task based on the hardware command parameters of the playback task corresponding to the asynchronous execution unit.

[0074] In other words, the asynchronous execution unit reads the loaded timed hardware command parameters, performs parsing, verification and encapsulation according to the original execution order of the captured scene, and then assembles and generates complete GPU instruction data that matches the current playback task. After preprocessing, it sends a ready signal back to the scheduling layer.

[0075] The asynchronous execution unit restores the hardware state based on the GPU context and register configuration saved in the trajectory, ensuring that the playback environment replicates the captured scene; and generates GPU instruction data based on hardware command parameters, strictly following the original execution sequence; each unit completes processing independently, avoiding state interference between multiple tasks, effectively improving the consistency and reproducibility of trajectory playback.

[0076] In some optional implementations of the embodiments of this disclosure, the above-described GPU execution trajectory replay method further includes: for each asynchronous execution unit, determining whether the state of the GPU hardware queue to which the replay task corresponding to the asynchronous execution unit is bound is idle, and polling the feedback signal of the synchronization barrier of the preceding replay task.

[0077] In this implementation, after each asynchronous execution unit initiates the preprocessing flow, it first executes the pre-waiting logic. Specifically, the asynchronous execution unit continuously reads the running flag of the GPU hardware queue, and determines in real time whether the hardware queue has completed all instructions in the previous round and whether there are any unfinished operations. If so, it confirms that the hardware queue has entered a stable idle state. At the same time, the asynchronous execution unit continuously polls the synchronization barrier corresponding to the previous batch of concurrent replay tasks, continuously listens for the barrier's feedback signal, and waits for the synchronization barrier to report that all tasks in the previous batch have been completed.

[0078] It's important to note that the synchronization barrier is a signaling mechanism used for synchronizing execution between multiple tasks. In scenarios where multiple GPU trajectory playback tasks are executed concurrently in batches, the synchronization barrier is used to mark whether all playback tasks in a batch have been completed. The asynchronous execution unit confirms the completion of all task instructions in the previous batch by polling the feedback signal of the synchronization barrier, preventing overlapping execution of new and old batches of tasks, avoiding interference from residual GPU hardware states, and ensuring orderly switching between batches.

[0079] The asynchronous execution unit only ends its waiting process and continues with GPU hardware state configuration operations when both conditions are met simultaneously: the GPU hardware queue is idle and a synchronization barrier completion signal is received. This effectively isolates tasks from preceding and following batches, avoiding replay anomalies caused by residual hardware state.

[0080] In some optional implementations of the embodiments of this disclosure, configuring the current GPU hardware state based on the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit can be performed as follows: in response to determining that the state of the GPU hardware queue bound to the playback task corresponding to the asynchronous execution unit is idle and the feedback signal of the synchronization barrier of the preceding playback task is a completion signal, the current GPU hardware state is configured based on the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit.

[0081] In this implementation, when the asynchronous execution unit detects that its bound GPU hardware queue is completely idle, with no incomplete instructions or residual hardware states, and polls to obtain the synchronization fence feedback signal corresponding to the preceding (also known as the previous batch) concurrent playback task as a task completion signal, it determines that the current hardware execution environment is clean and the batch switching conditions are ready. The asynchronous execution unit immediately loads the locally cached GPU context data and complete hardware register configuration information corresponding to the current playback task, and restores the GPU rendering pipeline state, resource binding relationships, shader state, frame buffer configuration, and register values ​​of each functional module one by one, that is, restores the current GPU hardware state to the baseline state recorded in the trajectory capture stage. This accurately restores the GPU hardware queue's operating environment to the original hardware state in the trajectory capture stage, eliminates the state deviation caused by batch switching, and provides a standard and consistent hardware execution foundation for subsequent accurate reproduction of the GPU instruction execution process.

[0082] Step 404: In response to the determination that the preprocessing operations of each asynchronous execution unit have been completed, the GPU instruction data corresponding to the multiple playback tasks are sent to the GPU hardware queues bound to the multiple playback tasks respectively, so that the multiple GPU hardware queues can execute their respective bound playback tasks in parallel.

[0083] The above steps 404 and as follows Figure 2 The steps shown in step 204 are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0084] According to the GPU execution trajectory replay method provided in this disclosure, each replay task is assigned an independent identifier to facilitate full-process tracking and tracing, and runtime environment data is extracted from the trajectory file to provide a baseline for replay. Task logic isolation is achieved by creating asynchronous execution units one-to-one, and multiple units perform preprocessing in parallel to generate GPU instruction data. After all preprocessing is completed, instructions are uniformly distributed to the corresponding GPU hardware queue, realizing hardware-level parallel replay of multiple trajectories. This effectively avoids mutual interference between multiple tasks, ensures accurate restoration of the GPU runtime environment, improves the consistency and reproducibility of trajectory replay, and fully utilizes hardware resources, thereby improving the execution efficiency of batch trajectory replay.

[0085] In some optional implementations of the embodiments of this disclosure, the above-mentioned creation of corresponding asynchronous execution units for each playback task can be performed as follows: for each playback task, a worker thread corresponding to the playback task is created, and the task identifier, runtime environment data, and handle of the GPU hardware queue bound to the playback task are stored in the thread-local storage area of ​​the worker thread, and the worker thread is used as the asynchronous execution unit to carry the playback task.

[0086] In this implementation, after receiving a replay task to be processed, the scheduling layer creates a dedicated worker thread for each replay task. This worker thread serves as the asynchronous execution unit for that replay task. The scheduling layer writes the task identifier of the replay task, the runtime environment data extracted from the GPU execution trajectory file, and the handle of the GPU hardware queue to which the replay task is bound to the thread-local storage area corresponding to the worker thread. The data in the thread-local storage area can only be accessed by that worker thread, thereby isolating the data related to each replay task and avoiding data mixing between multiple threads. After completing the initialization configuration of the worker thread, the worker thread waits for the preprocessing start instruction issued by the scheduling layer.

[0087] By using worker threads as asynchronous execution units and isolating the task identifiers, runtime environments, and hardware queue handles of each playback task through thread-local storage areas, task data is isolated from each other, avoiding data interference between multiple tasks, ensuring the independent execution of each playback task, and improving the reliability of multi-task concurrent processing.

[0088] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a GPU execution trajectory playback system, which is similar to... Figure 1 The method embodiments shown correspond to those described.

[0089] like Figure 5 As shown, the GPU execution trajectory playback system 500 of this embodiment may include: a script layer 501 and a scheduling layer 502.

[0090] The script layer 501 traverses all GPU execution trajectory directories, filters out GPU execution trajectory files that meet preset conditions, generates a replay task for each GPU execution trajectory file, and sends the replay task to the scheduling layer 502. Specifically, after starting, the script layer 501 traverses all GPU execution trajectory directories specified in the configuration, reads the metadata of the trajectory files in the directories, and performs verification and filtering based on preset conditions such as file integrity and hardware version matching rules, eliminating corrupt or incompatible trajectory files. The script layer 501 generates an independent replay task for each filtered GPU execution trajectory file. The task encapsulates information such as the trajectory file path, replay configuration, and task identifier. The generated replay tasks are then batch-sent to the scheduling layer 502, which handles subsequent task scheduling and GPU replay execution.

[0091] In one implementation, the script layer and the CI (Continuous Integration) layer work together to build a controlled concurrent replay process around multiple Trace (i.e., GPU execution trace) directories. Specifically, Trace files are distributed across different directories (traces collected from different test cases, different versions, and different devices are archived separately). The script layer and the CI layer work together to automatically scan each directory, filter valid traces, generate replay tasks, and submit them to the scheduling layer, forming a complete automated chain. Here, a concurrency limit is set (based on CPU computing power, the number of GPU hardware queues, and video memory resources). A maximum of N replays are allowed to execute in parallel at the same time. Tasks exceeding the limit are queued to avoid resource exhaustion, driver crashes, and task timeouts caused by a large number of traces starting simultaneously.

[0092] The scheduling layer 502 is used to create a corresponding asynchronous execution unit for each of the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed; to execute the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit in parallel; and to start the execution process of multiple replay tasks in response to determining that the preprocessing operations of each asynchronous execution unit have been completed.

[0093] The scheduling layer 502 receives several GPU execution trajectory replay tasks from the script layer 501. For each replay task to be executed, it creates an independent asynchronous execution unit. The scheduling layer 502 schedules multiple asynchronous execution units to run simultaneously. Each asynchronous execution unit executes its own bound replay task's preprocessing process in parallel, completing tasks such as parsing the GPU execution trajectory file and restoring instructions. The scheduling layer 502 continuously polls the running status of each asynchronous execution unit. After confirming that all asynchronous execution units have completed their preprocessing operations, it generates an execution trigger instruction and sends it to each asynchronous execution unit to start the execution process of each replay task.

[0094] The aforementioned GPU execution trajectory replay system can concurrently utilize multiple queue resources in multi-queue scenarios to improve replay throughput; it can integrate task distribution, execution, and completion detection into a unified scheduling loop to reduce concurrent state mismatch; and it can also form a controlled concurrency mechanism in large-scale trace scenarios, balancing efficiency and stability.

[0095] In the GPU execution trajectory playback system 500 of this disclosure embodiment: the specific processing of the script layer 501 and the scheduling layer 502 and the resulting technical effects can be referred to respectively. Figure 1 The relevant descriptions of steps 101-102 in the corresponding embodiments will not be repeated here.

[0096] This embodiment exists as a system 500 embodiment corresponding to the above method embodiment. The key steps or equivalent technical means that can be implemented by each component in the GPU execution trajectory playback system 500 embodiment provided in this embodiment, as well as the technical effects brought about by the system embodiment, can be referred to the relevant descriptions in the above method embodiment, and will not be repeated here.

[0097] Further reference Figure 6 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a GPU execution trajectory playback device, which is similar to... Figure 1 The example shown corresponds to the method embodiment for replaying the GPU execution trajectory.

[0098] like Figure 6 As shown, the GPU execution trajectory replay device 600 of this embodiment may include a creation module 601 and a task initiation module 602. The creation module 601 is configured to create a corresponding asynchronous execution unit for each of the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed. The task initiation module 602 is configured to execute the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit in parallel, and in response to determining that the preprocessing operations of each asynchronous execution unit have been completed, initiate the execution process of the multiple replay tasks.

[0099] In some optional implementations of the embodiments of this disclosure, the specific processing of the creation module 601 and the task initiation module 602 and the resulting technical effects can be referred to respectively. Figure 1 The relevant descriptions of steps 101-102 in the corresponding embodiments will not be repeated here.

[0100] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: an instruction data generation module, configured to generate GPU instruction data corresponding to multiple playback tasks according to a preprocessing operation; and a task startup module 602 including: a task execution submodule, configured to send the GPU instruction data corresponding to multiple playback tasks to GPU hardware queues bound to multiple playback tasks respectively, so that multiple GPU hardware queues execute their respective bound playback tasks in parallel.

[0101] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: a threshold determination module, configured to add the playback task to the set of tasks to be executed, and determine the concurrent scheduling threshold of the set of tasks to be executed based on GPU hardware queue information and system resource information; and a task execution submodule further configured to: in response to determining that the number of playback tasks in the set of tasks to be executed has reached the concurrent scheduling threshold, send the GPU instruction data corresponding to the multiple playback tasks to their respective bound GPU hardware queues.

[0102] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: a fence insertion module, configured to insert a synchronization fence after the GPU instruction data on the GPU hardware queue; and an execution state determination module, configured to determine the execution state of the playback task based on the feedback signal of the synchronization fence and the driver exception information, wherein the driver exception information is used to characterize the abnormal state of the GPU hardware.

[0103] In some optional implementations of the embodiments of this disclosure, the execution status determination module is further configured to: determine the execution status of the playback task as successful in response to determining that the feedback signal is a completion signal and no driver exception information is received; or determine the execution status of the playback task as timeout in response to not receiving a feedback signal and not receiving driver exception information; or determine the execution status of the playback task as failure in response to not receiving a feedback signal and receiving driver exception information.

[0104] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: a first result determination module, configured to determine the execution result of the plurality of playback tasks as failure in response to determining that the execution status of any one of the plurality of playback tasks is timed out or failed.

[0105] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: a second result determination module, configured to determine that the execution status of all playback tasks is successful, determine that the execution result of multiple playback tasks is successful; release the binding relationship between multiple playback tasks and the GPU hardware queue, release the resources occupied by each asynchronous execution unit, and clear the set of tasks to be executed.

[0106] In some optional implementations of the embodiments of this disclosure, the threshold determination module is further configured to: determine the total capacity of the hardware queue based on the type of the GPU hardware queue and the available number of each queue; determine system resource information based on the available memory information, video memory balance, and number of CPU cores of the current device; and determine the concurrent scheduling threshold of the set of tasks to be executed based on the total capacity and system resource information.

[0107] In some optional implementations of the embodiments of this disclosure, the GPU execution trajectory playback device further includes: an identifier allocation module configured to assign a task identifier to each playback task; and a creation module further configured to: for each playback task, extract runtime environment data from the GPU execution trajectory file corresponding to the playback task, wherein the runtime environment data includes at least: GPU context, hardware register configuration information, and hardware command parameters; create a corresponding asynchronous execution unit for the playback task, and load the task identifier, runtime environment data, and handle of the GPU hardware queue bound to the playback task into the asynchronous execution unit.

[0108] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: a preprocessing module configured to configure the current GPU hardware state for each asynchronous execution unit based on the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit; and an instruction data generation module including: a data generation submodule configured to generate GPU instruction data corresponding to the playback task based on the hardware command parameters of the playback task corresponding to the asynchronous execution unit.

[0109] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory playback device further includes: a state determination module, configured to determine, for each asynchronous execution unit, whether the state of the GPU hardware queue bound to the playback task corresponding to the asynchronous execution unit is idle, and poll the feedback signal of the synchronization barrier of the preceding playback task; and a preprocessing module is further configured to: in response to determining that the state of the GPU hardware queue bound to the playback task corresponding to the asynchronous execution unit is idle and the feedback signal of the synchronization barrier of the preceding playback task is a completion signal, configure the current GPU hardware state according to the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit.

[0110] In some optional implementations of the embodiments of this disclosure, the above-mentioned creation module is further configured to: for each playback task, create a worker thread corresponding to the playback task, store the task identifier of the playback task, runtime environment data, and handle of the GPU hardware queue bound to the playback task into the thread-local storage area of ​​the worker thread, and use the worker thread as an asynchronous execution unit to carry the playback task.

[0111] This embodiment exists as a device 600 embodiment corresponding to the above method embodiment. The key steps or equivalent technical means that can be implemented by each component of the GPU execution trajectory playback device 600 embodiment provided in this embodiment, as well as the technical effects brought about by this device embodiment, can be referred to the relevant descriptions in the above method embodiment, and will not be repeated here.

[0112] According to embodiments of the present disclosure, the present disclosure also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a GPU execution trajectory playback method as described in any implementation of the first aspect.

[0113] According to embodiments of this disclosure, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, can implement the GPU execution trajectory playback method described in any of the above embodiments.

[0114] For example, the computer instructions corresponding to a GPU execution trajectory playback method in this embodiment of the present disclosure can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the computer instructions corresponding to the GPU execution trajectory playback method in the storage media are read or executed by a computer, the GPU execution trajectory playback method as described in any of the above embodiments can be implemented.

[0115] According to embodiments of this disclosure, this disclosure also provides a computer program product including a computer program that, when executed by a processor, can implement the GPU execution trajectory playback method described in any of the above embodiments.

[0116] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device 700 proposed in the embodiments of the present disclosure includes a processor 701 and a memory 702 storing an executable computer program. The processor 701 is configured to implement the GPU execution trajectory playback method provided in the embodiments of the present disclosure when executing the executable computer program stored in the memory 702.

[0117] In some optional implementations of the embodiments of this disclosure, the electronic device 700 may further include a communication interface 703 and a bus 704 for connecting the processor 701, the memory 702 and the communication interface 703.

[0118] In some optional implementations of the embodiments of this disclosure, bus 704 is used to connect communication interface 703, processor 701 and memory 702 to realize mutual communication between these devices.

[0119] In some optional implementations of the embodiments of this disclosure, the processor 701 may be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that, for different devices, the electronic device used to implement the function of the processor 701 may also be other, and the embodiments of this disclosure do not specifically limit it.

[0120] The aforementioned memory 702 is used to store executable computer programs and data. The executable computer program includes computer operation instructions. Memory 702 may include high-speed RAM and may also include non-volatile memory, such as at least two disk drives. In practical applications, the aforementioned memory 702 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provides executable computer programs and data to the processor.

[0121] Furthermore, the functional modules in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0122] If the integrated units described above are implemented as software functional modules and not sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, 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.) or processor to execute all or part of the steps of the method of this disclosure embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0123] According to the technical solution of this disclosure, by independently configuring an asynchronous execution unit for each playback task, performing preprocessing in parallel, and uniformly waiting for all units to be ready before starting the execution process of multiple playback tasks, it is possible to achieve mutual isolation of multi-task preprocessing and prevent cross-contamination of hardware states; the unified triggering of task execution process ensures that the playback sequence of multiple trajectories is controllable, making full use of hardware and software resources, thereby improving the testing efficiency of large-scale trajectory playback, and effectively ensuring the reproducibility of trajectory playback.

[0124] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0125] It should also be understood that expressions such as "comprising," "including," "having," "containing," and / or "comprising" are open-ended rather than closed-ended expressions in this disclosure, indicating the presence of the stated features, elements, and / or components, but not excluding the presence of one or more other features, elements, components, and / or combinations thereof. Furthermore, when expressions such as "at least one of..." appear after a list of listed features, they modify the entire list of features, not just individual elements in the list. Additionally, when describing embodiments of this disclosure, the word "may" is used to mean "one or more embodiments of this disclosure." And the term "exemplary" is intended to refer to an example or illustration.

[0126] Unless otherwise specified, all terms used herein (including engineering and technical terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It should also be understood that, unless expressly stated in this disclosure, terms as defined in common dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not as having an idealized or overly formalized meaning.

[0127] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for replaying the execution trajectory of a graphics processing unit (GPU), characterized in that, The method includes: For multiple replay tasks corresponding to multiple GPU execution trajectories to be executed, a corresponding asynchronous execution unit is created for each of the replay tasks; The preprocessing operations of the playback tasks corresponding to each asynchronous execution unit are executed in parallel. In response to determining that the preprocessing operations of each asynchronous execution unit have been completed, the execution flow of the multiple playback tasks is started.

2. The method according to claim 1, characterized in that, The method further includes: The preprocessing operation generates GPU instruction data corresponding to the plurality of playback tasks; and The execution process for initiating the multiple playback tasks includes: The GPU instruction data corresponding to the multiple playback tasks are sent to the GPU hardware queues bound to the multiple playback tasks respectively, so that the multiple GPU hardware queues can execute their respective bound playback tasks in parallel.

3. The method according to claim 2, characterized in that, The method further includes: The replay task is added to the set of tasks to be executed, and the concurrent scheduling threshold of the set of tasks to be executed is determined based on GPU hardware queue information and system resource information; and The step of sending the GPU instruction data corresponding to the plurality of playback tasks to the GPU hardware queues bound to the plurality of playback tasks includes: In response to determining that the number of replay tasks in the set of tasks to be executed has reached the concurrent scheduling threshold, the GPU instruction data corresponding to the multiple replay tasks are sent to their respective bound GPU hardware queues.

4. The method according to claim 3, characterized in that, The method further includes: A synchronization barrier is inserted after the GPU instruction data in the GPU hardware queue; The execution status of the playback task is determined based on the feedback signal of the synchronization fence and the driver anomaly information, wherein the driver anomaly information is used to characterize the abnormal state of the GPU hardware.

5. The method according to claim 4, characterized in that, Determining the execution status of the playback task based on the feedback signal from the synchronization fence and the drive anomaly information includes: In response to determining that the feedback signal is a completion signal and no driver exception information is received, the execution status of the playback task is determined to be successful; or In response to the absence of the feedback signal and the driver exception information, the execution status of the playback task is determined to be timed out; or In response to the absence of the feedback signal and the receipt of the driver exception information, the execution status of the playback task is determined to be failed.

6. The method according to claim 5, characterized in that, The method further includes: In response to determining that the execution status of any one of the plurality of replay tasks is the timeout or the failure, the execution result of the plurality of replay tasks is determined to be failure.

7. The method according to claim 5, characterized in that, The method further includes: In response to determining that the execution status of all replay tasks is successful, the execution result of the plurality of replay tasks is determined to be successful; The binding relationship between the multiple playback tasks and the GPU hardware queue is released, the resources occupied by each asynchronous execution unit are released, and the set of tasks to be executed is cleared.

8. The method according to claim 3, characterized in that, The step of determining the concurrent scheduling threshold of the set of tasks to be executed based on GPU hardware queue information and system resource information includes: The total capacity of the hardware queues is determined based on the type of GPU hardware queues and the number of available queues. The system resource information is determined based on the available memory, remaining video memory, and number of CPU cores of the current device. Based on the total capacity and the system resource information, the concurrent scheduling threshold of the set of tasks to be executed is determined.

9. The method according to claim 2, characterized in that, The method further includes: Assign a task identifier to each playback task; and The step of creating a corresponding asynchronous execution unit for each of the playback tasks includes: For each replay task, runtime environment data is extracted from the GPU execution trajectory file corresponding to the replay task, wherein the runtime environment data includes at least: GPU context, hardware register configuration information, and hardware command parameters; An asynchronous execution unit is created for the playback task, and the task identifier of the playback task, the runtime environment data, and the handle of the GPU hardware queue bound to the playback task are loaded into the asynchronous execution unit.

10. The method according to claim 9, characterized in that, The preprocessing operations include: For each asynchronous execution unit, configure the current GPU hardware state based on the GPU context and hardware register configuration information of the replay task corresponding to the asynchronous execution unit; and The step of generating GPU instruction data corresponding to the plurality of playback tasks according to the preprocessing operation includes: Based on the hardware command parameters of the playback task corresponding to the asynchronous execution unit, the GPU instruction data corresponding to the playback task is generated.

11. The method according to claim 10, characterized in that, The method further includes: For each asynchronous execution unit, determine whether the state of the GPU hardware queue to which the playback task corresponding to the asynchronous execution unit is bound is idle, and poll the feedback signal of the synchronization barrier of the preceding playback task; and The step of configuring the current GPU hardware state based on the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit includes: In response to determining that the state of the GPU hardware queue bound to the playback task corresponding to the asynchronous execution unit is the idle state and the feedback signal of the synchronization barrier of the preceding playback task is a completion signal, the current GPU hardware state is configured according to the GPU context and hardware register configuration information of the playback task corresponding to the asynchronous execution unit.

12. The method according to claim 9, characterized in that, The step of creating a corresponding asynchronous execution unit for each of the playback tasks further includes: For each playback task, create a worker thread corresponding to the playback task; The task identifier of the playback task, the runtime environment data, and the handle of the GPU hardware queue bound to the playback task are stored in the thread-local storage area of ​​the worker thread, and the worker thread is used as an asynchronous execution unit to carry the playback task.

13. A system for replaying the execution trajectory of a graphics processing unit (GPU), characterized in that, The system includes a script layer and a scheduling layer. The script layer is used to traverse each GPU execution trajectory directory, filter out GPU execution trajectory files that meet preset conditions, generate a replay task for each GPU execution trajectory file, and send the replay task to the scheduling layer. The scheduling layer is used to create a corresponding asynchronous execution unit for each of the multiple replay tasks corresponding to the multiple GPU execution trajectories to be executed; to execute the preprocessing operations of the replay tasks corresponding to each asynchronous execution unit in parallel; and to start the execution process of the multiple replay tasks in response to determining that the preprocessing operations of each asynchronous execution unit have been completed.

14. A device for replaying the execution trajectory of a graphics processing unit (GPU), characterized in that, The device includes: The module is configured to create a corresponding asynchronous execution unit for each of the multiple GPU execution trajectories to be executed, for each of the multiple replay tasks. The task initiation module is configured to execute the preprocessing operations of the playback tasks corresponding to each asynchronous execution unit in parallel. In response to determining that the preprocessing operations of each asynchronous execution unit have been completed, the execution flow of the multiple playback tasks is initiated.

15. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method for replaying the execution trajectory of a graphics processing unit (GPU) according to any one of claims 1-12.

16. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the processor to execute the method for replaying the execution trajectory of the graphics processing unit (GPU) as described in any one of claims 1-12.

17. A computer program product, characterized in that, The method includes a computer program that, when executed by a processor, implements a method for replaying the execution trajectory of a graphics processing unit (GPU) according to any one of claims 1-12.

Images