Method, device, equipment, medium and program product for GPU to perform playback of trajectory

Abstract

The present disclosure provides a GPU execution trajectory playback method, device, equipment, medium and program product, wherein the playback method comprises: structuring the associated information of the waiting semaphore of the to-be-executed task in the GPU execution trajectory file to obtain the structured semaphore data corresponding to the waiting semaphore; and determining the ready state of the waiting object associated with the waiting semaphore according to the structured semaphore data; in response to the ready state of all the waiting objects associated with the to-be-executed task being ready, sending the GPU instruction data corresponding to the to-be-executed task to the GPU hardware queue to enable the GPU hardware queue to execute the to-be-executed task. The method reduces the occurrence of synchronization semantic loss, accurately restores the original task synchronization timing, and improves the reliability and fault reproduction capability in the GPU debugging and testing process.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a method, apparatus, device, medium, and program product for replaying GPU execution trajectories. Background Technology

[0002] With the widespread application of GPUs (Graphics Processing Units) in general computing, graphics rendering, and other fields, GPU-based task scheduling relies heavily on semaphore synchronization mechanisms. Multi-GPU tasks depend on waiting for and notifying semaphores to control the execution sequence, ensuring orderly data reading and writing and avoiding resource access conflicts. To verify the correctness of GPU program execution and reproduce anomalies, a trajectory capture and replay scheme is typically used. This involves recording the GPU task execution process in a capture environment and then replaying the task flow in a replay environment to reproduce the original synchronization behavior.

[0003] Traditional trajectory playback schemes only collect raw semaphore information during the acquisition phase and complete basic data processing during the conversion phase to support real-time playback. However, existing schemes rely solely on discrete semaphore data to drive playback scheduling, making it difficult to guarantee the consistency between the synchronization timing of tasks during playback and the original execution behavior. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, medium, and program product for replaying GPU execution trajectories. The GPU execution trajectory replay method provided in this embodiment reduces the occurrence of synchronization semantic loss, accurately restores the original task synchronization timing, and improves the reliability and fault reproducibility during GPU debugging and testing.

[0005] In a first aspect, embodiments of this disclosure propose a method for replaying a GPU execution trajectory, comprising: performing structured processing on the association information of waiting semaphores of a task to be executed in a GPU execution trajectory file to obtain structured semaphore data corresponding to the waiting semaphores; and determining the ready state of the waiting objects associated with the waiting semaphores based on the structured semaphore data; and in response to the fact that the ready state of all waiting objects associated with the task to be executed is ready, sending GPU instruction data corresponding to the task to be executed to a GPU hardware queue so that the GPU hardware queue executes the task to be executed.

[0006] Secondly, embodiments of this disclosure provide a GPU execution trajectory playback device, including: a data generation module, a state determination module, and a data transmission module. The data generation module is configured to perform structured processing on the association information of waiting semaphores for a task to be executed in the GPU execution trajectory file to obtain structured semaphore data corresponding to the waiting semaphores; the state determination module is configured to determine the ready state of the waiting objects associated with the waiting semaphores based on the structured semaphore data; and the data transmission module is configured to, in response to all waiting objects associated with the task to be executed being in a ready state, send GPU instruction data corresponding to the task to be executed to the GPU hardware queue, so that the GPU hardware queue executes the task to be executed.

[0007] Thirdly, 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 GPU execution trajectory playback method as described in any implementation of the first aspect.

[0008] Fourthly, 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 GPU execution trajectories as described in any implementation of the first aspect.

[0009] Fifthly, embodiments of this disclosure provide 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 implementation of the first aspect.

[0010] According to the technical solution provided in this disclosure, the associated information of the waiting semaphores of the tasks to be executed in the GPU execution trajectory file is processed in a structured manner to obtain structured semaphore data corresponding to the waiting semaphores. Then, the ready state of the waiting objects associated with the waiting semaphores is determined based on the structured semaphore data. Finally, in response to the ready state of all waiting objects associated with the tasks to be executed being ready, the GPU instruction data corresponding to the tasks to be executed is sent to the GPU hardware queue so that the GPU hardware queue can execute the tasks to be executed. By continuously utilizing the semaphore information retained in the capture phase during the playback phase, the occurrence of synchronization semantic loss is reduced. Through the unified synchronization judgment logic of standardized semaphore data, the original task synchronization sequence is accurately restored, ensuring the consistency between the playback behavior and the capture scene. Task scheduling is automated, avoiding timing errors, stably reproducing the GPU running scene, and improving the reliability and fault reproduction capability during GPU debugging and testing.

[0011] 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

[0012] 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 device provided in this embodiment of the present disclosure; Figure 6 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

[0013] 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.

[0014] This disclosure relates to the field of computer technology, specifically to a method for replaying GPU execution trajectories, a device for replaying GPU execution trajectories, an electronic device, a computer storage medium, and a program product, 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.

[0015] GPU tasks typically use wait semaphores and notification semaphores to synchronize execution timing, and trajectory capture and playback technology is often used to reproduce GPU malfunctions.

[0016] Existing trajectory replay schemes record basic semaphore information during the capture phase and organize the data during the conversion phase, relying on semaphore information to achieve task readiness judgment and replay scheduling. However, existing schemes have significant drawbacks: they only save scattered semaphore records and do not fully deduce the synchronization dependencies between tasks based on waiting and notification semaphores. As a result, they cannot better utilize the semaphore information captured during the capture phase in subsequent replay or analysis phases, reducing the accuracy of reproduction during replay. Moreover, when replay encounters anomalies such as blocking or data inconsistency, only independent task logs can be viewed, making it difficult to trace the abnormal task, synchronization signal, and corresponding data resources along the synchronization link.

[0017] In other words, existing GPU trajectory playback solutions mainly suffer from problems such as the stable retention of semaphore information during the capture phase and the coordinated utilization of this information in the subsequent conversion and playback phases.

[0018] 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.

[0019] 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: Perform structured processing on the association information of the waiting semaphores of the task to be executed in the GPU execution trajectory file to obtain the structured semaphore data corresponding to the waiting semaphores.

[0020] In this embodiment, the GPU execution trajectory file acquired during the capture phase is first loaded and parsed to extract the association information of the waiting semaphores corresponding to each task to be executed. The association information of the waiting semaphores includes at least: the original address of the waiting semaphore in the capture environment, the waiting target value, or the identifier of the task to be executed (associated object) that initiated the semaphore waiting operation, etc., wherein the waiting target value is a pre-agreed count value for triggering readiness on the waiting semaphore, which is the comparison benchmark for judging whether the waiting object meets the conditions.

[0021] As an example, suppose a raw operation is parsed from the GPU execution trajectory file: Task_002 performs a sem_wait wait operation. The associated information of the corresponding waiting semaphore includes the following details: Semaphore capture side original address: 0xffff80001A200400 (uniquely identifies this semaphore instance); Operation type: waiting for semaphore sem_wait; Waiting target value: 5 (the wait is released when the semaphore count value reaches 5).

[0022] Then, it iterates through all waiting semaphore operation records in the GPU execution trajectory file, using the original address of the semaphore's capture side as the unique index key. Multiple operation records for the same waiting semaphore are merged, organized, and structurally encapsulated to generate structured semaphore data. The resulting single structured semaphore data field includes: semaphore type (waiting semaphore), original address of the semaphore's capture side, target value, and may also include associated objects (identifier of the task to be executed).

[0023] After all recording processing is completed, structured semaphore data is output for subsequent conversion stages to be regularized and written to intermediate files.

[0024] Optionally, notification semaphore association information corresponding to the same task to be executed can also be extracted. This association information includes the original address of the notification semaphore and the identifier of the task to be executed that triggered the notification. Based on the matching relationship between waiting semaphores and notification semaphores, tasks to be executed that have direct or indirect synchronization dependencies are identified and assigned a unified group identifier. This group identifier is then encapsulated into structured semaphore data.

[0025] It should be noted that a complete GPU Trace (i.e., GPU execution trajectory) toolchain includes a capture phase and a playback phase. The capture phase records the complete operation of the GPU to obtain a Trace file (i.e., GPU execution trajectory file). The playback phase separates from the original application, loads the saved Trace file, and resubmits all the recorded GPU instructions and queue operations to the GPU to fully reproduce the independent execution phase of the original rendering and computing behavior.

[0026] Wait semaphores and notification semaphores are paired synchronization primitives used to manage the execution order of multiple GPU tasks, preventing data read / write conflicts caused by unordered concurrency. A wait semaphore is the semaphore record corresponding to a blocking wait operation initiated by a task; the task remains blocked until the semaphore count reaches a target value. A notification semaphore is the semaphore record corresponding to a count increment operation initiated after a task completes execution; it is used to increment the semaphore count, triggering the waiting task to unblock. The same semaphore instance can be used for notification operations by multiple tasks, or for waiting operations by one or more tasks.

[0027] Step 102: Determine the ready state of the waiting object associated with the waiting semaphore based on the structured semaphore data.

[0028] During replay initialization, a global semaphore count table is established, using the original address of the semaphore capture environment as an index, and the current count value of each semaphore instance is initialized to 0. The replay scheduling process continuously traverses all pending tasks in a blocked state, reads the structured semaphore data corresponding to the waiting semaphore associated with the pending task, and obtains the waiting target value and the original address of the semaphore.

[0029] Then, the current count value of the waiting semaphore is obtained, and the current count value is compared with the waiting target value recorded in the structured semaphore data. If the current count value is less than the waiting target value, it is determined that the waiting object associated with the waiting semaphore is not ready, and the corresponding task to be executed remains blocked; if the current count value is greater than or equal to the waiting target value, it is determined that the waiting object associated with the waiting semaphore is ready.

[0030] It should be noted that the waiting object is a logical encapsulation entity specifically constructed by the replay scheduling layer for a semaphore waiting condition. For each waiting semaphore, a corresponding waiting object is created; this waiting object is bound to the waiting semaphore and carries all the scheduling parameters and static conditions required for this waiting.

[0031] For example, in the structured semaphore data corresponding to the waiting semaphore for Task_002, the original address of the semaphore is 0xffff80001A200400, and the target value is 5. During replay, the preceding tasks, such as Task_001, Task_003, and Task_005, sequentially execute notification operations, and the semaphore count value gradually accumulates. When the count value reaches 5, the waiting object is determined to be ready, and Task_002 ends its blocking and starts execution. For scenarios where multiple tasks are waiting for the same semaphore instance, each task waiting to be executed performs its readiness determination based on its own independent target value in its structured semaphore data, without affecting each other, accurately reproducing the multi-task synchronization behavior in the capture environment.

[0032] Step 103: In response to the fact that all waiting objects associated with the task to be executed are in the ready state, the GPU instruction data corresponding to the task to be executed is sent to the GPU hardware queue so that the GPU hardware queue can execute the task to be executed.

[0033] In the GPU trajectory playback scheduling process, the readiness status of all waiting objects bound to each task to be executed is continuously monitored. When it is determined that all waiting objects corresponding to the task to be executed are in a ready state, the instruction generation and submission process is triggered. That is, the GPU instruction data corresponding to the task to be executed is sent to the GPU hardware queue so that the GPU hardware queue can execute the task to be executed. The GPU instruction data corresponding to the task to be executed is a set of hardware instructions pre-captured and saved during the trajectory playback stage, which is an instruction message that can be directly submitted to the GPU hardware queue for parsing and execution.

[0034] After the GPU instruction data is constructed, it is pushed to the GPU hardware queue. The GPU hardware queue schedules hardware resources according to the enqueue order, parses and executes each GPU instruction in the command buffer in turn, and fully reproduces all the operation behaviors of the task to be executed in the capture environment.

[0035] For example, the task to be executed, Task_002, is associated with two waiting semaphores. The count values ​​of both waiting semaphores meet their respective target thresholds, and the ready status is "ready". Then, the GPU instruction data corresponding to Task_002 is submitted to the GPU hardware queue, and the GPU hardware executes a series of operations and resource access operations corresponding to Task_002.

[0036] In addition, if there are multiple waiting semaphores for the task to be executed, as long as any one of the waiting semaphores has not reached the ready condition, the generation of GPU instruction data will be temporarily suspended, the task will remain blocked, and the replay timing will be kept consistent with the original execution logic.

[0037] According to the GPU execution trajectory replay method provided in this disclosure, the associated information of the waiting semaphores of the task to be executed in the GPU execution trajectory file is processed in a structured manner to obtain structured semaphore data corresponding to the waiting semaphores. Then, the ready state of the waiting objects associated with the waiting semaphores is determined based on the structured semaphore data. Finally, in response to the ready state of all waiting objects associated with the task to be executed being ready, the GPU instruction data corresponding to the task to be executed is sent to the GPU hardware queue so that the GPU hardware queue executes the task to be executed. In this way, by continuously utilizing the semaphore information retained in the capture phase during the replay phase, the occurrence of synchronization semantic loss is reduced; by standardizing the unified synchronization judgment logic of the semaphore data, the original task synchronization sequence is accurately restored, ensuring the consistency between the replay behavior and the capture scene; and the task scheduling is automated, avoiding timing disorder, stably reproducing the GPU running scene, and improving the reliability and fault reproduction capability in the GPU debugging and testing process.

[0038] Please refer to Figure 2 , Figure 2A flowchart of another method for replaying GPU execution trajectories provided in this disclosure embodiment, wherein process 200 includes the following steps: Step 201: Determine the target threshold corresponding to the count value of the waiting semaphore from the associated information of the waiting semaphores of the task to be executed.

[0039] In this embodiment, the GPU execution trajectory file is loaded and the associated information of the waiting semaphores corresponding to the tasks to be executed is parsed one by one. The associated information includes the original log field of the waiting operation, which records the count value condition required to be achieved in this waiting operation. The original record corresponding to the waiting operation initiated by the current task to be executed is retrieved, and a preset threshold is extracted from it as the target threshold corresponding to the waiting semaphore count value.

[0040] It should be noted that the same semaphore instance can be waited for by multiple tasks, and different tasks can configure their own independent target thresholds. The threshold parameters are not shared between tasks. The extracted target thresholds are stored in the structured semaphore data corresponding to the waiting semaphore.

[0041] For example, if the associated information of the waiting semaphore for Task_002 is obtained by parsing, and the waiting condition is read as the semaphore count reaches 5, then the target threshold is determined to be 5.

[0042] Step 202: Integrate the original address of the waiting semaphore in the capture environment with the target threshold into structured semaphore data.

[0043] The original address and target threshold in the capture environment are associated and bound together, and then integrated and encapsulated to form structured semaphore data. The structured semaphore data also synchronously writes associated object identifiers, group identifiers, and other supporting information. The capture environment refers to the runtime environment that collects GPU execution trajectory files and records various semaphore operation logs. For example, the original address of the waiting semaphore capture, 0xffff80001A200400, and the target threshold, 5, are extracted and stored together in the same structured semaphore data entry. This structured semaphore data is uniformly stored in an intermediate file. During the playback stage, semaphore instances can be matched based on the original address, and a ready state determination can be performed in conjunction with the target threshold.

[0044] The target threshold is extracted from the associated information and integrated with the original address of the semaphore in the capture environment into structured semaphore data. This achieves standardized encapsulation of key synchronization parameters and establishes a binding relationship between semaphore instances and waiting conditions, facilitating rapid retrieval during the playback phase.

[0045] Step 203: Determine the valid address in the playback environment corresponding to the original address of the waiting semaphore in the capture environment.

[0046] During the replay initialization phase, an address mapping table is constructed, using the original address of the semaphore waiting in the capture environment as the lookup index. In the replay environment, a corresponding semaphore instance is created and assigned a valid address for that environment. A one-to-one mapping relationship between the original capture address and the valid replay address is then established and stored in the mapping table. During replay scheduling, the original capture address is first read from the structured semaphore data, and then the corresponding valid replay environment address is obtained by querying the mapping table.

[0047] Step 204: Read the current count value of the waiting semaphore from the valid address.

[0048] During the replay scheduling process, the pre-built address mapping table is queried based on the original address captured in the structured semaphore data to obtain the valid address corresponding to the waiting semaphore in the replay environment. Then, the underlying interface is called to access the memory region of the semaphore instance pointed to by the valid address, and the current count value stored in the waiting semaphore is read in real time.

[0049] Step 205: Determine the ready status of the waiting object based on the current count value and the target threshold.

[0050] The current count value is compared with the target threshold in the structured semaphore data to determine whether the waiting object is ready. If the current count value is less than the target threshold, the waiting object is considered not ready, and the corresponding task to be executed remains blocked. If the current count value is greater than or equal to the target threshold, the waiting object is considered ready. For example: if the current count value is 4 and the target threshold is 5, the waiting object is considered not ready; when the count value is updated to 5, the threshold condition is met, the waiting object is considered ready, and subsequent task blocking is allowed to be released.

[0051] By converting the capture address to the playback address through address mapping, reading the real-time count value based on the valid address, and determining the ready state in combination with the target threshold, the differences in addressing of semaphore resources in different environments are eliminated, ensuring that the synchronization logic of the playback process is consistent with the original execution behavior, and achieving precise task blocking and wake-up control.

[0052] In some optional implementations of the embodiments of this disclosure, step 205 can be executed as follows: In response to the current count value being not less than a target threshold, the ready state of the waiting object is determined to be ready. That is, when it is determined that the current count value is greater than or equal to the target threshold, the ready state corresponding to the waiting object associated with the waiting semaphore is marked as ready. For example, if the target threshold is set to 5, and the current count value of the semaphore is read as 5, then the condition is met, the ready state is set to ready, and it participates in the wake-up condition verification of subsequent tasks to be executed.

[0053] In some optional implementations of the embodiments of this disclosure, step 205 above may be performed as follows: in response to the current count value being less than the target threshold, the ready state of the waiting object is determined to be not ready; the new current count value of the waiting semaphore is continuously read at a preset polling period, and the ready state of the waiting object is determined according to the new current count value and the target threshold.

[0054] In this implementation, the current count value of the waiting semaphore read from the valid address of the playback environment is compared with the target threshold in the structured semaphore data. If the current count value is less than the target threshold, the ready state is marked as not ready, and the corresponding task to be executed remains blocked. At this time, the valid address is repeatedly accessed according to a preset polling cycle, continuously reading the current count value after the waiting semaphore is updated. After each reading, it is compared with the target threshold again, and the ready state is determined cyclically.

[0055] For example, the target threshold is 5, the count value is read as 3 on the first read, and it is determined that it is not ready; then, it is polled and read once every 1ms, and the judgment is repeated until the count value reaches the threshold, then the polling ends and the semaphore is marked as ready.

[0056] The readiness state is determined by comparing the current count value with the target threshold, establishing clear and unified judgment rules. It can accurately replicate the semaphore synchronization logic in the capture environment, accurately control the timing of task blocking and wake-up, ensure that the GPU task replay sequence is consistent with the original execution process, and improve the realism and reliability of trajectory replay.

[0057] In some optional implementations of the embodiments of this disclosure, the above-mentioned GPU execution trajectory replay method further includes: in response to the polling waiting time reaching a preset timeout parameter, and among all waiting objects there is a waiting object whose ready state is not ready, stopping the replay running process, and returning the result identification information of the replay failure.

[0058] During the continuous polling and reading of the current count value of the waiting semaphore, the polling waiting time is recorded synchronously. If the polling waiting time reaches the preset timeout parameter, and there are waiting objects among all waiting objects whose ready state is not ready, that is, the waiting semaphore associated with the task to be executed is still in a not ready state, then a synchronization blocking anomaly is determined to have occurred. At this time, the overall playback process will be stopped immediately, the semaphore status will no longer be polled, the GPU instruction delivery hardware queue will no longer be generated, and the playback failure result identifier information will be returned to the upper layer module to facilitate the staff to locate anomalies such as semaphore synchronization timing mismatch and missing original trajectory operations. The timeout parameter can be set according to the business scenario. It can be a preset value or dynamically calculated based on the GPU execution trajectory file. This embodiment does not make a specific limitation on this. Assuming the timeout parameter is 2000ms, if the semaphore is still not ready after the task has been waiting for 2000ms, the playback will be terminated and a failure identifier will be reported.

[0059] Optionally, before replay starts, all waiting objects associated with pending tasks can be traversed and organized into an ordered list of pending tasks. Simultaneously, the preset timeout parameters and polling interval configurations for each waiting object are read and written into the current replay execution context for storage. The execution context continuously holds these parameters throughout the replay period. When polling to check the readiness status of waiting objects, the polling interval is directly read from the context to control the query frequency, and the blocking duration is monitored based on the timeout parameters. This eliminates the need for repeatedly loading configurations, ensuring stable execution of the semaphore waiting logic.

[0060] By setting a timeout monitoring mechanism, the playback process is terminated in a timely manner when the semaphore fails to be ready for an extended period, preventing the task from being blocked indefinitely and causing the program to freeze. At the same time, a playback failure flag is output, which can quickly identify synchronization anomalies such as missing track operations and timing mismatches, making it easier to locate faults and improving the stability of the track playback system and the efficiency of anomaly troubleshooting.

[0061] Step 206: In response to the fact that all waiting objects associated with the task to be executed are in the ready state, the GPU instruction data corresponding to the task to be executed is sent to the GPU hardware queue so that the GPU hardware queue can execute the task to be executed.

[0062] The above steps 206 and as follows Figure 1 The steps shown are the same as step 103. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0063] According to the GPU execution trajectory replay method provided in this disclosure, the effective address of the replay environment is obtained through address mapping, the real-time count value is read and combined with the target threshold to determine the ready state; when all tasks are waiting for the semaphore to be ready, the GPU instruction is sent to the hardware queue for execution. Thus, by using standardized data to unify the synchronization judgment logic, adapting to the address differences between the capture and replay environments, the synchronization timing of the original tasks is accurately restored, ensuring that the replay behavior is consistent with the actual execution process. This method can stably reproduce GPU running scenarios and support hardware verification, driver testing, and problem reproduction.

[0064] 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: Perform structured processing on the association information of the waiting semaphores of the task to be executed in the GPU execution trajectory file to obtain the structured semaphore data corresponding to the waiting semaphores.

[0065] Step 302: Determine the ready state of the waiting object associated with the waiting semaphore based on the structured semaphore data.

[0066] Steps 301-302 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.

[0067] Step 303: In response to the fact that all waiting objects associated with the task to be executed are in a ready state, GPU instruction data is generated based on the set of command parameters corresponding to the task to be executed.

[0068] In this embodiment, during the GPU trajectory playback scheduling process, the readiness status of all waiting objects bound to each task to be executed is continuously monitored. When it is determined that all waiting objects corresponding to the task to be executed are in a ready state, the instruction generation and submission process is triggered. That is, using the task identifier of the task to be executed as the retrieval key, the command parameter set corresponding to the task to be executed, which is pre-stored in the intermediate file, is read. The command parameter set may include register configuration parameters, memory copy instruction parameters, computation task instruction parameters, and the original execution order of various operations. According to the order of instructions recorded in the captured trajectory, the command parameter set is parsed and encoded, and the standardized parameter information is compiled into binary GPU instruction data that can be recognized by the GPU hardware.

[0069] In some optional implementations of the embodiments of this disclosure, the command parameter set includes register configuration information and command parameter information. Step 303 can be executed as follows: parsing the register configuration information to generate register configuration instructions for setting the GPU hardware context; parsing the command parameter information to generate GPU operation instructions; and assembling the register configuration instructions and GPU operation instructions according to the original execution order of the register configuration information and command parameter information to obtain GPU instruction data.

[0070] In this implementation, when all waiting semaphores bound to a task are detected to be ready, the command parameter set corresponding to the task is read, and register configuration information is extracted from it. The register configuration information may include raw record parameters such as the target register number, register access permissions, the value to be written, and write timing constraints. Then, the above configuration information is parsed line by line according to the GPU hardware instruction set specification, distinguishing between control registers, status registers, and resource scheduling registers. The parameters are encapsulated into hardware-recognizable register write instructions, generating a register configuration instruction sequence for building the GPU hardware context.

[0071] This instruction sequence is responsible for configuring the hardware context environment, including the computing channel, memory access parameters, and pipeline control parameters. When constructing complete GPU instruction data, register configuration instructions are placed at the front of the instruction queue and submitted to the GPU hardware queue first. This ensures that the GPU completes hardware context initialization first, and then executes subsequent instructions such as data copying and parallel computing, accurately reproducing the hardware register state before the task starts in the captured environment.

[0072] After the task to be executed completes the hardware context register configuration, command parameter information is extracted from the command parameter set. This information records various raw operation descriptions collected during the capture phase, such as memory copying, kernel startup, synchronization primitives, and barrier operations. Then, the command parameter information is parsed line by line according to the GPU hardware instruction encoding specification, identifying parameter fields such as operation type, operation source address, target address, data length, kernel entry point, and synchronization flags. This transforms the abstract operation description into hardware-recognizable binary GPU operation instructions.

[0073] Next, the system reads the original execution timing identifiers corresponding to the register configuration information and command parameter information recorded in the GPU trajectory file to reconstruct the execution order in the capture environment. Then, following this original order, all register configuration instructions are arranged first, followed by the sequentially generated GPU operation instructions. If register configuration operations are interspersed between computational operations in the trajectory, the two types of instructions are arranged alternately, strictly following the timing sequence at the time of capture. Afterward, the ordered combination of register configuration instructions and GPU operation instructions is encapsulated into a continuous instruction data packet, forming complete GPU instruction data. This GPU instruction data maintains an instruction sequence consistent with the capture trajectory and is sent to the GPU hardware queue to ensure that the execution timing of GPU context switching, register settings, and various computational and memory access operations is consistent with the capture scenario.

[0074] By parsing register configuration information and command parameter information separately, corresponding register configuration instructions and GPU operation instructions are generated. Then, based on the original execution order of the trajectory record, various instructions are assembled to obtain GPU instruction data. This method can accurately restore the execution sequence of hardware context configuration and computational operations in the captured environment, ensuring that the register state takes effect before the corresponding operation, maintaining the execution logic of the instructions unchanged, improving the consistency and fidelity of GPU trajectory playback, and reliably reproducing the original running scene.

[0075] Step 304: Send GPU instruction data to the GPU hardware queue so that the GPU hardware queue can execute the task to be executed.

[0076] In this embodiment, after the GPU instruction data is constructed, it is pushed to the GPU hardware queue. The GPU hardware queue schedules hardware resources according to the enqueue order, parses and executes each GPU instruction in the command buffer in sequence, and fully reproduces all the operation behaviors of the task to be executed in the capture environment.

[0077] According to the GPU execution trajectory replay method provided in this disclosure, the associated information of waiting semaphores in the GPU execution trajectory file is structured. The ready state of each waiting object is parsed based on the structured semaphore data. Only after all waiting objects are ready is GPU instruction data generated based on the command parameter set and submitted to the GPU hardware queue for execution. This achieves standardized parsing of synchronization dependencies during the replay process, avoiding issuing instructions before preconditions are met, reducing the occurrence of problems such as illegal memory access, rendering anomalies, and task suspension, thereby improving the operational stability and execution accuracy of GPU trajectory replay.

[0078] 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: Determine the target threshold corresponding to the count value of the waiting semaphore from the associated information of the waiting semaphores of the task to be executed.

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

[0080] Step 402: Obtain the notification semaphore of the task to be executed from the GPU execution trajectory file.

[0081] In this embodiment, the GPU execution trajectory file is parsed line by line, and notification operation records bound to the task to be executed are retrieved from the trajectory log to extract the notification semaphore information to be triggered when the task is completed. Here, the notification semaphore information may include the original address of the semaphore in the capture environment and the increment value corresponding to the notification trigger. This notification semaphore is associated with the current task to be executed. After the task is completed in the playback environment, a semaphore count increment operation is performed based on this information. For example, the original address of the notification semaphore bound to Task_002 is parsed to be 0xffff80001A200800, with a notification increment of 1, which serves as the trigger object after the task ends.

[0082] Step 403: Based on the waiting semaphore and the notification semaphore, determine the dependent task groups with dependencies from all pending tasks in the GPU execution trajectory file, and assign group identifiers to the dependent task groups.

[0083] During the replay initialization phase, all tasks to be executed are traversed, and the waiting semaphore and notification semaphore corresponding to each task are extracted. If the notification semaphore of one task is the same as the waiting semaphore of another task, the two tasks are determined to have an upstream / downstream dependency and are included in the same dependent task group. The search continues outward, and all tasks with chained semaphore dependencies are grouped together to form complete dependent task groups. Tasks that are not associated with each other through waiting or notification semaphores are assigned to different task groups. After grouping, a globally unique group identifier is assigned to each dependent task group.

[0084] For example, when task T1 completes execution, it sends a synchronization signal via semaphore S1. Task T2 depends on semaphore S1 to start. When task T2 completes execution, it triggers task T3 via semaphore S2. T1, T2, and T3 are then grouped into the same dependent task group and assigned group identifier G01. Task T4, which has no semaphore dependency, forms its own dependent task group and is assigned group identifier G02. During scheduling, tasks in each group can be distinguished based on their group identifiers, and semaphore polling and task replay can be performed in an orderly manner according to their dependencies.

[0085] In some optional implementations of the embodiments of this disclosure, step 403 above may be performed as follows: in response to the fact that the wait semaphore of the first task to be executed in the GPU execution trajectory file is the same as the notification semaphore of the second task to be executed in the GPU execution trajectory file, a dependent task group including the first task to be executed and the second task to be executed is determined; wherein the first task to be executed depends on the second task to be executed.

[0086] In this implementation, all pending tasks are traversed, and the waiting semaphore bound to the first pending task and the notification semaphore bound to the second pending task are extracted and compared. When it is identified that the waiting semaphore of the first pending task and the notification semaphore of the second pending task are the same synchronization resource, a dependency relationship is determined: the second pending task is executed first, and after the task is completed, a notification counting operation is performed on the semaphore; the first pending task needs to wait for the semaphore count value to reach the target threshold before it can start, that is, the first pending task depends on the second pending task. Subsequently, the first and second pending tasks are grouped into the same dependent task group.

[0087] For example, if the waiting semaphore for task T1 is S0 and the notification semaphore for task T2 is S0, then T1 is considered to depend on T2, and T1 and T2 are assigned to the same dependent task group. During replay scheduling, it is necessary to wait for T2 to finish executing and trigger the semaphore S0 so that S0 satisfies the waiting condition of T1 before executing T1.

[0088] By comparing the waiting and notification semaphores of tasks, upstream and downstream dependencies can be identified, and synchronization constraints between tasks can be accurately determined. Tasks with dependencies are grouped into dependent task groups. This allows the system to reconstruct the task execution sequence based on semaphores in the original GPU trajectory, distinguish the sequential triggering logic between tasks, and facilitate the scheduler to manage each group of tasks in an orderly manner according to dependencies. This avoids out-of-order execution that violates the original synchronization order, ensures the consistency of trajectory playback timing, and improves the matching degree between playback results and the captured scene.

[0089] In some optional implementations of the embodiments of this disclosure, the above-described method for replaying the GPU execution trajectory further includes: obtaining a buffer object carrying GPU task service data; determining a first buffer object corresponding to the original address of the waiting semaphore and a second buffer object corresponding to the original address of the notification semaphore; establishing a mapping relationship between the original address of the waiting semaphore and the first buffer object, and between the original address of the notification semaphore and the second buffer object; and generating dependency topology chain information based on the dependency relationship and the mapping relationship.

[0090] In this implementation, the various buffer objects carrying GPU task data are first acquired. Based on the original capture address of the waiting semaphore, the corresponding first buffer object is determined; based on the original capture address of the notification semaphore, the corresponding second buffer object is determined. Then, a mapping relationship is established: the original address of the waiting semaphore is bound to the first buffer object, and the original address of the notification semaphore is bound to the second buffer object. Afterwards, combining the upstream and downstream dependencies between tasks based on semaphores, and the mapping relationship between semaphore addresses and buffer objects, a complete dependency topology chain is generated. This topology chain records the correspondence between task execution order, semaphore resources, and associated buffer objects.

[0091] By acquiring buffer objects, a mapping relationship is established between the original address of the semaphore and the corresponding buffer object. This, combined with task dependencies, generates dependency topology chain information. This accurately reconstructs the synchronization relationships between GPU tasks, resolves matching errors caused by address offsets during playback, and ensures accurate and reliable parsing of task dependency logic.

[0092] In some optional implementations of the embodiments of this disclosure, the above-described GPU execution trajectory replay method further includes: in response to an anomaly occurring during the replay process, performing anomaly analysis based on the dependent topology chain information.

[0093] In this implementation, once a replay anomaly such as instruction execution error, semaphore wait timeout, or memory access anomaly is detected during the replay process, the scheduling module retrieves the pre-built dependency topology chain information, traces the abnormal task, associated semaphore, and corresponding buffer object along the task chain, locates the link where the anomaly occurred and related resources, and completes the anomaly source analysis.

[0094] For example, when a task experiences a semaphore wait timeout, the upstream task that generated the notification semaphore can be found by relying on the dependency topology chain. At the same time, the buffer object corresponding to the semaphore can be located to quickly distinguish whether the exception is caused by the upstream task not executing properly or by abnormal buffer data.

[0095] When replaying anomalies, the system leverages topology chains to trace related tasks, semaphores, and buffer objects, quickly locating faulty links and causes, thus improving the efficiency of anomaly troubleshooting in GPU trajectory replay scenarios.

[0096] Step 404: Integrate the original address, target threshold, and group identifier into structured semaphore data.

[0097] In this embodiment, the GPU execution trajectory is parsed to obtain the original address and target threshold of the waiting semaphore, and the group identifier of the dependent task group corresponding to the task to which the semaphore belongs is obtained. The original address, target threshold, and group identifier are integrated and encapsulated to form a structured semaphore data. For example, the original address of the waiting semaphore is 0xffff80002100, the target threshold is 1, and the group identifier is G03. These three pieces of information are combined and stored as structured semaphore data for unified reading and use in subsequent waiting object creation, dependency group verification, and ready state judgment processes.

[0098] Step 405: Determine the valid address in the playback environment corresponding to the original address of the waiting semaphore in the capture environment.

[0099] Step 406: Read the current count value of the waiting semaphore from the valid address.

[0100] Step 407: Determine the ready status of the waiting object based on the current count value and the target threshold.

[0101] Step 408: In response to the fact that all waiting objects associated with the task to be executed are in the ready state, the GPU instruction data corresponding to the task to be executed is sent to the GPU hardware queue so that the GPU hardware queue can execute the task to be executed.

[0102] Steps 405-408 above and as follows Figure 2 Steps 203-206 shown are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0103] According to the GPU execution trajectory replay method provided in this disclosure, notification semaphores corresponding to tasks are extracted from the trajectory file. Task dependencies are identified by combining waiting semaphores, and dependent task groups are divided and assigned group identifiers. Then, the original semaphore address, target threshold, and group identifier are integrated into structured semaphore data, uniformly encapsulating synchronization resource information and task grouping information. This facilitates centralized reading of required parameters in the scheduling process, associates semaphores with their respective task groups, supports readiness judgment, orderly task scheduling, and dependency link tracing, ensuring that GPU trajectory replay follows the original synchronization sequence.

[0104] 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 device, which is similar to... Figure 1 The example shown corresponds to the method embodiment for replaying the GPU execution trajectory.

[0105] like Figure 5As shown, the GPU execution trajectory playback device 500 of this embodiment may include: a data generation module 501, a state determination module 502, and a data transmission module 503. The data generation module 501 is configured to perform structured processing on the association information of the waiting semaphores of the task to be executed in the GPU execution trajectory file to obtain structured semaphore data corresponding to the waiting semaphores; the state determination module 502 is configured to determine the ready state of the waiting objects associated with the waiting semaphores based on the structured semaphore data; and the data transmission module 503 is configured to send the GPU instruction data corresponding to the task to be executed to the GPU hardware queue in response to all waiting objects associated with the task to be executed being ready, so that the GPU hardware queue executes the task to be executed.

[0106] In some optional implementations of the embodiments of this disclosure, the specific processing of the data generation module 501, the state determination module 502, and the data transmission module 503, and the resulting technical effects, can be referred to respectively. Figure 1 The relevant descriptions of steps 101-103 in the corresponding embodiments will not be repeated here.

[0107] In some optional implementations of the embodiments of this disclosure, the data generation module 501 includes: a threshold determination submodule, configured to determine a target threshold corresponding to the count value of the waiting semaphore from the associated information of the waiting semaphore of the task to be executed; and an integration submodule, configured to integrate the original address of the waiting semaphore in the capture environment with the target threshold into structured semaphore data; wherein the capture environment is the environment for capturing GPU execution trajectory files.

[0108] In some optional implementations of the embodiments of this disclosure, the state determination module 502 includes: an address determination submodule, configured to determine the valid address in the playback environment corresponding to the original address of the waiting semaphore in the capture environment; a count value determination submodule, configured to read the current count value of the waiting semaphore from the valid address; and a state determination submodule, configured to determine the ready state of the waiting object based on the current count value and a target threshold.

[0109] In some optional implementations of the embodiments of this disclosure, the state determination submodule is further configured to: determine the ready state of the waiting object as ready in response to the current count value being not less than the target threshold.

[0110] In some optional implementations of the embodiments of this disclosure, the state determination submodule is further configured to: determine the ready state of the waiting object as not ready in response to the current count value being less than the target threshold; continuously read the new current count value of the waiting semaphore at a preset polling period, and determine the ready state of the waiting object based on the new current count value and the target threshold.

[0111] In some optional implementations of the embodiments of this disclosure, the GPU execution trajectory playback device further includes: a return module, configured to stop the playback process and return playback failure result identification information in response to the polling waiting time reaching a preset timeout parameter and there being a waiting object with a ready state of not ready among all waiting objects.

[0112] In some optional implementations of the embodiments of this disclosure, the GPU execution trajectory playback device further includes: an acquisition module configured to acquire notification semaphores of tasks to be executed from the GPU execution trajectory file; an identification determination module configured to determine dependent task groups with dependencies from all tasks to be executed in the GPU execution trajectory file based on the waiting semaphores and notification semaphores, and assign group identifiers to the dependent task groups; and an integration submodule further configured to integrate the original address, target threshold, and group identifiers into structured semaphore data.

[0113] In some optional implementations of the embodiments of this disclosure, the identifier determination module is further configured to: determine a dependent task group including the first task to be executed and the second task to be executed in response to the fact that the waiting semaphore of the first task to be executed in the GPU execution trajectory file is the same as the notification semaphore of the second task to be executed in the GPU execution trajectory file; wherein the first task to be executed depends on the second task to be executed.

[0114] In some optional implementations of the embodiments of this disclosure, the GPU execution trajectory playback device further includes: a dependency topology generation module, configured to obtain a buffer object carrying GPU task service data; determine a first buffer object corresponding to the original address of the waiting semaphore and a second buffer object corresponding to the original address of the notification semaphore; establish a mapping relationship between the original address of the waiting semaphore and the first buffer object, and between the original address of the notification semaphore and the second buffer object; and generate dependency topology chain information based on the dependency relationship and the mapping relationship.

[0115] In some optional implementations of the embodiments of this disclosure, the GPU execution trajectory playback device further includes: an anomaly analysis module, configured to perform anomaly analysis based on dependent topology chain information in response to an anomaly generated during the playback process.

[0116] In some optional implementations of the embodiments of this disclosure, the data sending module 503 includes: an instruction data generation submodule, configured to generate GPU instruction data based on the command parameter set corresponding to the task to be executed in response to all waiting objects associated with the task to be executed being in a ready state; and a data sending submodule, configured to send the GPU instruction data to the GPU hardware queue.

[0117] In some optional implementations of the embodiments of this disclosure, the command parameter set includes: register configuration information and command parameter information; the data sending submodule is further configured to: parse the register configuration information to generate a register configuration instruction for setting the GPU hardware context; parse the command parameter information to generate a GPU operation instruction; and assemble the register configuration instruction and the GPU operation instruction according to the original execution order of the register configuration information and the command parameter information to obtain GPU instruction data.

[0118] This embodiment exists as a GPU execution trajectory playback device 500 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 500 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

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

[0124] In some optional implementations of the embodiments of this disclosure, the electronic device 600 may further include a communication interface 603 and a bus 604 for connecting the processor 601, the memory 602 and the communication interface 603.

[0125] In some optional implementations of the embodiments of this disclosure, bus 604 is used to connect communication interface 603, processor 601 and memory 602 to realize mutual communication between these devices.

[0126] In some optional implementations of the embodiments of this disclosure, the processor 601 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 601 may also be other types, and the embodiments of this disclosure do not specifically limit this.

[0127] The aforementioned memory 602 is used to store executable computer programs and data. The executable computer program includes computer operation instructions. Memory 602 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 602 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.

[0128] 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.

[0129] 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.

[0130] According to the technical solution of this disclosure, by continuously utilizing the semaphore information retained in the capture phase during the playback phase, the occurrence of synchronization semantic loss is reduced; by standardizing the unified synchronization judgment logic of semaphore data, the original task synchronization sequence is accurately restored, ensuring the consistency between the playback behavior and the capture scene; and the task scheduling is automated, avoiding timing disorder, stably reproducing the GPU running scene, and improving the reliability and fault reproduction capability in the GPU debugging and testing process.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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 GPU execution trajectories, characterized in that, The method includes: The associated information of the waiting semaphores of the tasks to be executed in the GPU execution trajectory file is processed in a structured manner to obtain the structured semaphore data corresponding to the waiting semaphores; and, Based on the structured semaphore data, determine the ready state of the waiting object associated with the waiting semaphore; In response to the fact that all waiting objects associated with the task to be executed are in a ready state, the GPU instruction data corresponding to the task to be executed is sent to the GPU hardware queue so that the GPU hardware queue executes the task to be executed.

2. The method according to claim 1, characterized in that, The process of structuring the association information of the waiting semaphores of the tasks to be executed in the GPU execution trajectory file to obtain the structured semaphore data corresponding to the waiting semaphores includes: From the associated information of the waiting semaphores of the task to be executed, determine the target threshold corresponding to the count value of the waiting semaphore; The original address of the waiting semaphore in the capture environment is integrated with the target threshold to form the structured semaphore data; wherein, the capture environment is the environment in which the GPU execution trajectory file is captured.

3. The method according to claim 2, characterized in that, Determining the ready state of the waiting object associated with the waiting semaphore based on the structured semaphore data includes: Determine the valid address in the playback environment corresponding to the original address of the waiting semaphore in the capture environment; Read the current count value of the waiting semaphore from the valid address; The ready state of the waiting object is determined based on the current count value and the target threshold.

4. The method according to claim 3, characterized in that, Determining the ready state of the waiting object based on the current count value and the target threshold includes: In response to the current count value being not less than the target threshold, the ready state of the waiting object is determined to be ready.

5. The method according to claim 3, characterized in that, Determining the ready state of the waiting object based on the current count value and the target threshold includes: In response to the current count value being less than the target threshold, the ready state of the waiting object is determined to be not ready; The new current count value of the waiting semaphore is continuously read at a preset polling period, and the ready state of the waiting object is determined based on the new current count value and the target threshold.

6. The method according to claim 5, characterized in that, The method further includes: In response to the polling waiting time reaching the preset timeout parameter, and the existence of a waiting object in the ready state among all waiting objects, the replay process is stopped, and the result identification information of the replay failure is returned.

7. The method according to claim 2, characterized in that, The method further includes: Obtain the notification semaphore of the task to be executed from the GPU execution trajectory file; Based on the waiting semaphore and the notification semaphore, determine the dependent task groups with dependencies from all pending tasks in the GPU execution trajectory file, and assign group identifiers to the dependent task groups. The step of integrating the original address of the waiting semaphore in the capture environment with the target threshold into the structured semaphore data includes: The original address, the target threshold, and the group identifier are integrated into the structured semaphore data.

8. The method according to claim 7, characterized in that, The step of determining the dependent task group with a dependency relationship from all pending tasks in the GPU execution trajectory file based on the waiting semaphore and the notification semaphore includes: In response to the fact that the wait semaphore of the first task to be executed in the GPU execution trajectory file is the same as the notification semaphore of the second task to be executed in the GPU execution trajectory file, a dependent task group including the first task to be executed and the second task to be executed is determined; wherein the first task to be executed depends on the second task to be executed.

9. The method according to claim 7, characterized in that, The method further includes: Obtain the buffer object that carries the GPU task data; Determine the first buffer object corresponding to the original address of the waiting semaphore, and the second buffer object corresponding to the original address of the notification semaphore; Establish a mapping relationship between the original address of the waiting semaphore and the first buffer object, and between the original address of the notification semaphore and the second buffer object; Based on the dependencies and the mapping relationships, dependency topology chain information is generated.

10. The method according to claim 9, characterized in that, The method further includes: In response to an anomaly occurring during the playback process, an anomaly analysis is performed based on the dependent topology chain information.

11. The method according to any one of claims 1-10, characterized in that, The step of responding to the readiness status of all waiting objects associated with the task to be executed being "ready" and sending the GPU instruction data corresponding to the task to be executed to the GPU hardware queue includes: In response to the ready status of all waiting objects associated with the task to be executed, GPU instruction data is generated based on the set of command parameters corresponding to the task to be executed. The GPU instruction data is sent to the GPU hardware queue.

12. The method according to claim 11, characterized in that, The command parameter set includes register configuration information and command parameter information; The step of generating GPU instruction data based on the command parameter set corresponding to the task to be executed includes: The register configuration information is parsed to generate register configuration instructions for setting the GPU hardware context; The command parameter information is parsed to generate GPU operation instructions; Based on the original execution order of the register configuration information and the command parameter information, the register configuration instructions and the GPU operation instructions are assembled to obtain GPU instruction data.

13. A device for replaying GPU execution trajectories, characterized in that, The device includes: The data generation module is configured to perform structured processing on the association information of the waiting semaphores of the tasks to be executed in the GPU execution trajectory file, to obtain structured semaphore data corresponding to the waiting semaphores; and, The state determination module is configured to determine the ready state of the waiting object associated with the waiting semaphore based on the structured semaphore data. The data sending module is configured to send the GPU instruction data corresponding to the task to be executed to the GPU hardware queue in response to the ready status of all waiting objects associated with the task to be executed, so that the GPU hardware queue executes the task to be executed.

14. 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 that can be executed by the at least one processor to enable the at least one processor to perform the GPU execution trajectory playback method according to any one of claims 1-12.

15. 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 GPU execution trajectory as described in any one of claims 1-12.

16. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements a method for replaying GPU execution trajectories according to any one of claims 1-12.

Images