A system, method, electronic device and storage medium for synchronizing task flows in a GPU

Abstract

The present disclosure relates to a system, method, electronic device and storage medium for synchronizing task streams in a GPU. The system includes: the GPU driver module, after sending a first task that is dependent on other tasks to a first task stream, sends a recording task to a task scheduling driver module, and before sending a second task that is dependent on the first task to a second task stream, sends a waiting task to the task scheduling driver module in the GPU card; the task scheduling driver module, in the second task stream, sends the waiting task before the second task; after the first task is completed, executes the recording task to set the first state identifier in the first synchronization object on the device side to a state representing the completion of the recording task; after detecting that the first state identifier indicates that the recording task has been completed, marks the waiting task as completed and executes the second task. The embodiments of the present disclosure achieve precise management of the dependency relationship between different task streams.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and more particularly to a system, method, electronic device, and storage medium for synchronizing task flows in a GPU. Background Art

[0002] In the parallel computing environment of graphics processing units (GPUs), dependencies often exist between GPU tasks on different task streams. These dependencies require that certain tasks must complete their state updates or data generation before other tasks can begin executing. Currently, the mainstream approach to handling these dependencies is to use hardware synchronization objects and synchronization fences.

[0003] In the prior art, application developers typically associate a synchronization object with a task or resource that needs to be dependent. To accurately reflect the different states of the dependent task or resource, multiple synchronization fences are associated with a synchronization object. These fences represent different states or stages of the dependent party. When the state of the dependent task or resource is updated, it sends a signal to the associated synchronization object and updates the synchronization fence representing the current state. The dependent party then determines whether the dependent party has reached the required state by checking the state of the synchronization fence corresponding to the dependency.

[0004] However, this approach is highly dependent on specific hardware implementations, as different hardware platforms have different synchronization object management and signaling mechanisms. This limits the solution's portability: a dependency management mechanism developed on one hardware platform may not be directly applicable to another. Summary of the Invention

[0005] The present disclosure proposes a technical solution for synchronization between task flows in a GPU.

[0006] According to one aspect of the present disclosure, a system for synchronizing task flows in a GPU is provided, comprising a GPU driver module on a host side and a task scheduling driver module in a GPU card, wherein:

[0007] The GPU driver module sends a recording task to the task scheduling driver module after sending the first task that is dependent on other tasks to the first task flow; the task scheduling driver module sends the recording task after the first task in the first task flow;

[0008] The GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to the second task flow; the task scheduling driver module sends the waiting task before the second task in the second task flow;

[0009] The task scheduling driving module executes the recording task after the first task is completed, so as to set the first state identifier in the first synchronization object on the device end to a state indicating that the recording task is completed;

[0010] The task scheduling driving module, after detecting that the first status identifier indicates that the recording task is completed, marks the waiting task as completed and executes the second task.

[0011] In one possible implementation, the GPU driver module receives a recording task issuance request sent by user software on the host side, wherein the recording task issuance request includes: a second object identifier of a second synchronization object on the host side, a context identifier and a task flow identifier of a first task on the device side; the GPU driver module determines a first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is an identifier of the first synchronization object; the GPU driver module sends a recording task to the task scheduling driver module, and adds one to the value of the second state identifier of the second synchronization object, wherein the recording task includes: the first object identifier, the context identifier and the task flow identifier of the first task on the device side.

[0012] In one possible implementation, the task scheduling driver module receives the recording task and determines the context to which the recording task is to be sent based on the context identifier in the recording task, and determines the first task flow in the context based on the task flow identifier in the recording task, and sends the recording task after the first task in the first task flow.

[0013] In a possible implementation, when the task scheduling driver module schedules the recording task to be executable, it adds one to the value of the first state identifier of the first object on the device side according to the first object identifier, and marks the recording task as completed.

[0014] In one possible implementation, the GPU driver module receives a waiting task sending request sent by user software on the host side, wherein the waiting task sending request includes: the second object identifier of the second synchronization object on the host side, the context identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier; the GPU driver module determines the first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is the identifier of the first synchronization object, and the second state identifier in the second object; the GPU driver module sends a waiting task to the task scheduling driver module, wherein the waiting task includes: the second state identifier, the context identifier and first object identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier.

[0015] In one possible implementation, the task scheduling driver module receives the waiting task, determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device end, sends the waiting task to the second task flow, and continues to send the second task to the second task flow, so that the waiting task is executed before the second task.

[0016] In one possible implementation, the task scheduling driver module, when scheduling the waiting task to be executable, determines the first state identifier of the first object based on the context identifier and the first object identifier of the first synchronization object on the device side; when it is determined that the first state identifier is greater than or equal to the second state identifier, marks the waiting task as completed and executes the second task, wherein the initial values ​​of the first state identifier and the second state identifier are the same.

[0017] In one possible implementation, the GPU driver module, in response to a synchronization object creation request sent by user software, requests the task scheduling driver module to create a first synchronization object; the task scheduling driver module creates the first synchronization object in the context indicated by the synchronization object creation request, sends the first object identifier of the created first synchronization object to the GPU driver module, and initializes the first state identifier of the first synchronization object; the GPU driver module receives the first object identifier, creates a second synchronization object, associates and saves the second object identifier of the second synchronization object with the first object identifier, and initializes the second state identifier of the second synchronization object; the GPU driver module returns the second object identifier to the user software.

[0018] In one possible implementation, the GPU driver module, in response to a synchronization object destruction request sent by user software, determines the first object identifier based on the second object identifier in the synchronization object destruction request, and requests the task scheduling driver module to destroy the first synchronization object corresponding to the first object identifier; the task scheduling driver module, based on the first object identifier, destroys the first synchronization object in the context indicated by the synchronization object creation request, and returns a successful destruction result to the GPU driver module; the GPU driver module receives the successful destruction result, destroys the second synchronization object corresponding to the second object identifier, and returns the successful destruction result to the user software.

[0019] According to one aspect of the present disclosure, a method for synchronizing task flows in a GPU is provided. The method is applied to the above-mentioned system, which may include a GPU driver module on a host side and a task scheduling driver module in a GPU card. The method includes:

[0020] After the GPU driver module issues the first task, which is dependent on other tasks, to the first task flow, it sends the recording task to the task scheduling driver module; the task scheduling driver module issues the recording task after the first task in the first task flow;

[0021] The GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to the second task flow; the task scheduling driver module sends the waiting task before the second task in the second task flow;

[0022] After the first task is completed, the task scheduling driving module executes the recording task to set the first state identifier in the first synchronization object on the device end to a state indicating that the recording task is completed;

[0023] After detecting that the first status identifier indicates that the recording task is completed, the task scheduling driving module marks the waiting task as completed and executes the second task.

[0024] In one possible implementation, the GPU driver module receives a recording task issuance request sent by user software on the host side, wherein the recording task issuance request includes: a second object identifier of a second synchronization object on the host side, a context identifier and a task flow identifier of a first task on the device side; the GPU driver module determines a first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is an identifier of the first synchronization object; the GPU driver module sends a recording task to the task scheduling driver module, and adds one to the value of the second state identifier of the second synchronization object, wherein the recording task includes: the first object identifier, the context identifier and the task flow identifier of the first task on the device side.

[0025] In one possible implementation, the task scheduling driver module receives the recording task and determines the context to which the recording task is to be sent based on the context identifier in the recording task, and determines the first task flow in the context based on the task flow identifier in the recording task, and sends the recording task after the first task in the first task flow.

[0026] In a possible implementation, when the task scheduling driver module schedules the recording task to be executable, it adds one to the value of the first state identifier of the first object on the device side according to the first object identifier, and marks the recording task as completed.

[0027] In one possible implementation, the GPU driver module receives a waiting task sending request sent by user software on the host side, wherein the waiting task sending request includes: the second object identifier of the second synchronization object on the host side, the context identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier; the GPU driver module determines the first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is the identifier of the first synchronization object, and the second state identifier in the second object; the GPU driver module sends a waiting task to the task scheduling driver module, wherein the waiting task includes: the second state identifier, the context identifier and first object identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier.

[0028] In one possible implementation, the task scheduling driver module receives the waiting task, determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device end, sends the waiting task to the second task flow, and continues to send the second task to the second task flow, so that the waiting task is executed before the second task.

[0029] In one possible implementation, the task scheduling driver module, when scheduling the waiting task to be executable, determines the first state identifier of the first object based on the context identifier and the first object identifier of the first synchronization object on the device side; when it is determined that the first state identifier is greater than or equal to the second state identifier, marks the waiting task as completed and executes the second task, wherein the initial values ​​of the first state identifier and the second state identifier are the same.

[0030] In one possible implementation, the GPU driver module, in response to a synchronization object creation request sent by user software, requests the task scheduling driver module to create a first synchronization object; the task scheduling driver module creates the first synchronization object in the context indicated by the synchronization object creation request, sends the first object identifier of the created first synchronization object to the GPU driver module, and initializes the first state identifier of the first synchronization object; the GPU driver module receives the first object identifier, creates a second synchronization object, associates and saves the second object identifier of the second synchronization object with the first object identifier, and initializes the second state identifier of the second synchronization object; the GPU driver module returns the second object identifier to the user software.

[0031] In one possible implementation, the GPU driver module, in response to a synchronization object destruction request sent by user software, determines the first object identifier based on the second object identifier in the synchronization object destruction request, and requests the task scheduling driver module to destroy the first synchronization object corresponding to the first object identifier; the task scheduling driver module, based on the first object identifier, destroys the first synchronization object in the context indicated by the synchronization object creation request, and returns a successful destruction result to the GPU driver module; the GPU driver module receives the successful destruction result, destroys the second synchronization object corresponding to the second object identifier, and returns the successful destruction result to the user software.

[0032] According to one aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to call the instructions stored in the memory to implement the above system.

[0033] According to one aspect of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the above system is implemented.

[0034] In an embodiment of the present disclosure, a system for synchronizing task streams in a GPU includes a GPU driver module on the host side and a task scheduling driver module in a GPU card, wherein: the GPU driver module sends a recording task to the task scheduling driver module after sending a first task that is dependent on other tasks to a first task stream; the task scheduling driver module sends the recording task after the first task in the first task stream; the GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to a second task stream; the task scheduling driver module sends the waiting task before the second task in the second task stream; the task scheduling driver module executes the recording task after the first task is completed, so as to set the first status identifier in the first synchronization object on the device side to a status representing the completion of the recording task; the task scheduling driver module marks the waiting task as completed after detecting that the first status identifier indicates that the recording task is completed, and executes the second task. Therefore, the GPU driver module on the host side and the task scheduling driver module in the GPU card work together. By issuing record tasks and waiting tasks, and recording the completion status of tasks through the first synchronization object, it is ensured that tasks are executed in a predetermined order and dependency relationship, and the precise management of the dependency relationship between different task flows in the GPU is achieved, avoiding dependence on the hardware platform and improving the portability of the system.

[0035] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, rather than limiting the present disclosure. Other features and aspects of the present disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and, together with the specification, are used to explain the technical solutions of the present disclosure.

[0037] Figure 1 A framework diagram of a system for synchronization between task streams in a GPU according to an embodiment of the present disclosure is shown.

[0038] Figure 2 A schematic diagram of the interactive process of creating a synchronization object provided by an embodiment of the present disclosure is shown.

[0039] Figure 3 A schematic diagram of the interactive process of destroying synchronization objects provided by an embodiment of the present disclosure is shown.

[0040] Figure 4 A schematic diagram of the interactive process of issuing and executing recording tasks provided by an embodiment of the present disclosure is shown.

[0041] Figure 5 A schematic diagram of the interactive process of issuing and executing waiting tasks provided by an embodiment of the present disclosure is shown.

[0042] Figure 6 A schematic diagram of an application scenario provided by an embodiment of the present disclosure is shown.

[0043] Figure 7 A flowchart of a method for synchronizing task flows in a GPU according to an embodiment of the present disclosure is shown.

[0044] Figure 8 A block diagram of an electronic device 1900 according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0045] Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0046] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0047] The term "and / or" herein simply describes an association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can represent the existence of three situations: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" herein refers to any combination of at least two of any one or more of a plurality of items. For example, "at least one of A, B, and C" can represent any one or more elements selected from the set consisting of A, B, and C.

[0048] In addition, numerous specific details are provided in the following detailed description to better illustrate the present disclosure. Those skilled in the art will appreciate that the present disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main points of the present disclosure.

[0049] Figure 1 A framework diagram of a system for synchronizing task flows in a GPU according to an embodiment of the present disclosure is shown. Figure 1 As shown, it includes a GPU driver module 101 on the host side and a task scheduling driver module 102 in the GPU card, wherein:

[0050] The GPU driver module 101 sends a recording task to the task scheduling driver module after sending the first task that is dependent on other tasks to the first task flow; the task scheduling driver module 102 sends the recording task after the first task in the first task flow;

[0051] The GPU driver module 101 sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to the second task flow; the task scheduling driver module 102 sends the waiting task before the second task in the second task flow;

[0052] The task scheduling driving module 102 executes the recording task after the first task is completed, so as to set the first state identifier in the first synchronization object on the device side to a state indicating that the recording task is completed;

[0053] The task scheduling driving module 102 , upon detecting that the first status flag indicates that the recording task is completed, marks the waiting task as completed and executes the second task.

[0054] A host-side GPU driver module is a software module located on the host computer. It is responsible for establishing communication between the application (user software) and the GPU, converting instructions, managing resources, synchronizing tasks, handling errors, and optimizing performance. In the fields of computer graphics processing and parallel computing, the host refers to any or all of the computer to which the GPU is connected. For example, the part of the computer, opposite the GPU, responsible for executing application and operating system instructions.

[0055] The task scheduling driver module, located within the GPU card, is responsible for managing and scheduling tasks on the GPU, ensuring that they execute in a predetermined order and within their dependencies. For example, when a task completes, the task scheduling driver module executes a "record task" to update the status of the first synchronization object. When another task needs to wait for a task to complete, it executes a "wait task" to check the status of the synchronization object and, if the conditions are met, continue executing the subsequent task.

[0056] In addition, the task scheduling driver module can receive task requests from the host side (CPU) and send these tasks to the execution queue inside the GPU. These tasks may include graphics rendering commands, computing tasks, etc.

[0057] The first task and the second task are used to describe two GPU tasks or operations with a dependency relationship. The first task and the second task can be a graphics rendering command, a computing task, or any other request that requires GPU processing. Among them, the second task is a task that is executed after the first task. For example, the second task needs to depend on the output result of the first task, and its execution needs to wait until the first task is completed. For example, in a graphics rendering application, it is necessary to first load and process the texture data of a 3D model. The operation of loading and processing the texture data here can be regarded as the first task; after the texture data is loaded and processed (that is, the first task is completed), these textures need to be applied to the 3D model and rendered. The rendering operation here can be regarded as the second task, which depends on the correct loading and processing of the texture data in the first task. If the first task fails or is not completed, the execution of the second task will also be affected.

[0058] It should be noted that the first task and the second task are tasks located in different task streams. A task stream is a stream composed of a series of related tasks or operations. Different task streams can be executed in parallel to improve GPU utilization and performance. However, different task streams can also have interdependencies, that is, the execution of a task in one task stream may depend on the completion of a task in another task stream.

[0059] For ease of description, the task flow for issuing the first task is described herein as the first task flow, and the task flow for issuing the second task is described herein as the second task flow. It should be understood that the terms "first" and "second" in the embodiments of this disclosure are used to distinguish between the objects being described and should not be construed as limiting the order of the objects being described, indicating or implying relative importance, or other limitations.

[0060] After the GPU driver module sends the first task, which is dependent on other tasks, to the first task flow, it sends a recording task to the task scheduling driver module. Upon receiving the recording task, the task scheduling driver module sends it to the position after the first task in the first task flow, ensuring that the recording task can be executed immediately after the first task completes.

[0061] The recording task here is used to update the first status indicator of the first synchronization object on the device after the first task is completed. The first synchronization object is an object used to manage dependencies between tasks. The first synchronization object contains a first status indicator that indicates whether the first task has been completed.

[0062] Before the GPU driver module sends a second task that depends on the first task to the second task flow, it sends a waiting task to the task scheduling driver module. After receiving the waiting task, the task scheduling driver module sends it to the position before the second task in the second task flow to ensure that the waiting task can be executed before the second task.

[0063] The waiting task here is used to check the first status identifier of the first synchronization object on the device side before executing the second task, so as to confirm whether the first task has been completed based on the first status identifier, and after the first task has been completed, mark the waiting task as completed and execute the second task.

[0064] When the first task is completed, the task scheduling driver module immediately executes the recording task. The recording task's primary function is to set the first status flag in the first synchronization object on the device to a state indicating the completion of the recording task. This allows other tasks that rely on this synchronization object to determine whether the first task has completed by checking this status flag.

[0065] The task scheduling driver module can periodically execute a waiting task to periodically detect the first status indicator of the first synchronization object on the device side. When the first status indicator is detected to indicate that the recording task has been completed, the waiting task is marked as completed and the second task is allowed to begin execution. This ensures that the second task begins execution only after the first task is completed.

[0066] In an embodiment of the present disclosure, a system for synchronizing task streams in a GPU includes a GPU driver module on the host side and a task scheduling driver module in a GPU card, wherein: the GPU driver module sends a recording task to the task scheduling driver module after sending a first task that is dependent on other tasks to a first task stream; the task scheduling driver module sends the recording task after the first task in the first task stream; the GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to a second task stream; the task scheduling driver module sends the waiting task before the second task in the second task stream; the task scheduling driver module executes the recording task after the first task is completed, so as to set the first status identifier in the first synchronization object on the device side to a status representing the completion of the recording task; the task scheduling driver module marks the waiting task as completed after detecting that the first status identifier indicates that the recording task is completed, and executes the second task. Therefore, the GPU driver module on the host side and the task scheduling driver module in the GPU card work together. By issuing record tasks and waiting tasks, and recording the completion status of tasks through the first synchronization object, it is ensured that tasks are executed in a predetermined order and dependency relationship, and the precise management of the dependency relationship between different task flows in the GPU is achieved, avoiding dependence on the hardware platform and improving the portability of the system.

[0067] The first synchronization object may be pre-created, or may utilize a first synchronization object already existing in the GPU device side. Below, the process of creating the first synchronization object is described in detail.

[0068] In one possible implementation, the GPU driver module, in response to a synchronization object creation request sent by user software, requests the task scheduling driver module to create a first synchronization object; the task scheduling driver module creates the first synchronization object in the context indicated by the synchronization object creation request, sends the first object identifier of the created first synchronization object to the GPU driver module, and initializes the first state identifier of the first synchronization object; the GPU driver module receives the first object identifier, creates a second synchronization object, associates and saves the second object identifier of the second synchronization object with the first object identifier, and initializes the second state identifier of the second synchronization object; the GPU driver module returns the second object identifier to the user software.

[0069] See Figure 2 , Figure 2 A schematic diagram of the interactive process of creating a synchronization object provided by an embodiment of the present disclosure is shown.

[0070] The host-side user software sends a synchronization object creation request to the GPU driver module. This request contains the parameters required to create the synchronization object, such as the context identifier. A context is an environment used to manage GPU resources and status. Different contexts are isolated from each other. Synchronization objects created in one context cannot be accessed or modified by other contexts. Therefore, when creating a synchronization object, you can specify a context identifier to determine the context in which it is created.

[0071] In response to the synchronization object creation request, the GPU driver module sends an instruction to the task scheduling driver module, requesting the creation of a first synchronization object in a specified context. After receiving the instruction, the task scheduling driver module creates the first synchronization object in the context indicated by the synchronization object creation request.

[0072] After creating the first synchronization object, the task scheduling driver module generates a unique first object identifier (such as a handle or ID) and sends this identifier to the GPU driver module. Simultaneously, the task scheduling driver module may also initialize a first state identifier of the first synchronization object. For example, the first state identifier may be set to an initial value (such as 0).

[0073] After receiving the first object identifier, the GPU driver module can create a second synchronization object corresponding to the first synchronization object. The second synchronization object is used for the host-side user software to interact with the GPU driver module.

[0074] The GPU driver module associates and stores the second object identifier of the second synchronization object with the first object identifier, that is, a mapping relationship is maintained within the GPU driver module so that the corresponding first object identifier can be quickly found through the second object identifier.

[0075] Likewise, the GPU driver module also initializes the second state flag of the second synchronization object, typically setting it to the same initial value as the first state flag (eg, 0).

[0076] After completing the above operations, the GPU driver module returns the second object identifier to the user software, so that the user software can use the second object identifier to reference and operate the first synchronization object.

[0077] Synchronization objects are used to coordinate the execution order between different tasks or threads, ensuring data consistency and correctness. Synchronization objects allow you to precisely control the execution order and dependencies of tasks on the GPU.

[0078] The state flags of the first and second synchronization objects are initialized to the same initial value (e.g., 0). The initial value represents the initial state of the synchronization object. During subsequent execution, when a task is completed or a certain condition is met, the value of the state flag can be modified to notify other tasks or threads. This enables communication between different threads and facilitates accurate synchronization of task execution status.

[0079] In the disclosed embodiment, the GPU driver module responds to a synchronization object creation request from user software. The task scheduling driver module creates a first synchronization object in a specified context and initializes its status identifier. Based on this, the GPU driver module then creates a second synchronization object, associates it with the first synchronization object, and stores its identifier and status identifier. Finally, the second object identifier is returned to the user software. This process provides a foundation for inter-task flow dependency management and synchronization, facilitating the rapid and accurate synchronization of task execution status across different task flows on the GPU device.

[0080] In addition, after the task is completed, the first synchronization object may also be destroyed to release processing resources. The process of destroying the first synchronization object is described in detail below.

[0081] In one possible implementation, the GPU driver module, in response to a synchronization object destruction request sent by user software, determines the first object identifier according to the second object identifier in the synchronization object destruction request, and requests the task scheduling driver module to destroy the first synchronization object corresponding to the first object identifier;

[0082] The task scheduling driver module destroys the first synchronization object in the context of the synchronization object creation request indication according to the first object identifier, and returns a result of successful destruction to the GPU driver module;

[0083] The GPU driver module receives the successful destruction result, destroys the second synchronization object corresponding to the second object identifier, and returns the successful destruction result to the user software.

[0084] See Figure 3 , Figure 3 A schematic diagram of the interactive process of destroying synchronization objects provided by an embodiment of the present disclosure is shown.

[0085] User software sends a synchronization object destruction request to the GPU driver module. This request typically includes the second object identifier of the synchronization object to be destroyed and the context identifier of the synchronization object to be destroyed. When destroying a synchronization object, it is ensured to be performed in the correct context. If the synchronization object was created in a specific context, it should also be destroyed in that context.

[0086] Upon receiving the synchronization object destruction request, the GPU driver module searches for the corresponding first object identifier in its internally stored associations based on the second object identifier in the request. After determining the first object identifier, the GPU driver module sends a command to the task scheduling driver module requesting the destruction of the first synchronization object corresponding to the first object identifier.

[0087] After receiving the destruction request, the task scheduling driver module will find and destroy the first synchronization object in the context indicated by the synchronization object creation request according to the first object identifier. Specifically, all resources related to the first synchronization object can be released, and it is ensured that no other tasks or threads are still referencing the first synchronization object.

[0088] If the first synchronization object is successfully destroyed, the task scheduling driver module returns a result of successful destruction to the GPU driver module.

[0089] After receiving the result of successful destruction, the GPU driver module will destroy the second synchronization object corresponding to the second object identifier within itself. Specifically, the data structure or resources related to the second synchronization object may be deleted or released.

[0090] After the GPU driver module completes the destruction of the second synchronization object, it returns a successful destruction result to the user software. In this way, the user software knows that the synchronization object has been successfully destroyed and can release related references or perform subsequent operations.

[0091] In an embodiment of the present disclosure, the GPU driver module, in response to a synchronization object destruction request sent by the user software, determines the first object identifier according to the second object identifier in the synchronization object destruction request, and requests the task scheduling driver module to destroy the first synchronization object corresponding to the first object identifier; the task scheduling driver module, according to the first object identifier, destroys the first synchronization object in the context indicated by the synchronization object creation request, and returns the result of successful destruction to the GPU driver module; the GPU driver module receives the result of successful destruction, destroys the second synchronization object corresponding to the second object identifier, and returns the result of successful destruction to the user software. In this way, it is possible to ensure that the synchronization object is destroyed in the correct context, and at the same time release the resources related to the synchronization object, ensuring that the system resources are effectively managed and utilized. By first destroying the first synchronization object on the device side and then destroying the second synchronization object on the host side, the integrity and consistency of the synchronization object destruction are ensured, and resource leakage and system errors are avoided.

[0092] After the first synchronization object is successfully created, the first synchronization object can be used to record the execution status of the first task. Specifically, a recording task can be sent to the device to record the execution status of the first object on the device.

[0093] In one possible implementation, the GPU driver module receives a recording task issuance request sent by user software on the host side, wherein the recording task issuance request includes: a second object identifier of a second synchronization object on the host side, a context identifier and a task flow identifier of a first task on the device side; the GPU driver module determines a first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is an identifier of the first synchronization object; the GPU driver module sends a recording task to the task scheduling driver module, and adds one to the value of the second state identifier of the second synchronization object, wherein the recording task includes: the first object identifier, the context identifier and the task flow identifier of the first task on the device side.

[0094] In this implementation, by receiving the recording task issuance request sent by the host-side user software, the association between the GPU driver module and the synchronization object is utilized to bind the task to the first task, context and task flow identifier of the device side, and update the status identifier of the synchronization object, thereby realizing the function of accurately recording and managing the task execution status on the device side, and enhancing the flexibility and accuracy of task scheduling.

[0095] In one possible implementation, the task scheduling driver module receives the recording task and determines the context to which the recording task is to be sent based on the context identifier in the recording task, and determines the first task flow in the context based on the task flow identifier in the recording task, and sends the recording task after the first task in the first task flow.

[0096] In this implementation, the recording task is received by the task scheduling driver module, and the target context and the first task flow are accurately located based on the context identifier and the task flow identifier. The recording task is then sent to after the first task, thereby achieving precise control of the task execution order and improving the efficiency of task scheduling and the ability to handle dependencies between tasks.

[0097] In a possible implementation, when the task scheduling driver module schedules the recording task to be executable, it adds one to the value of the first state identifier of the first object on the device side according to the first object identifier, and marks the recording task as completed.

[0098] In this implementation, when recording that a task is executable, the task scheduling driver module updates the first status identifier of the first object on the device side according to the first object identifier, and marks the task as completed, thereby effectively tracking and recording the progress of task execution, ensuring the accuracy and real-time synchronization of task status, and improving the reliability and efficiency of task management.

[0099] See Figure 4, Figure 4 A schematic diagram of the interactive process of issuing and executing recording tasks provided by an embodiment of the present disclosure is shown.

[0100] The host-side user software sends a recording task request, and the GPU driver module receives the recording task request from the host-side user software. The request includes the second object identifier of the second synchronization object on the host side, the context identifier of the first task on the device side, and the task flow identifier.

[0101] Among them, the context identifier and task flow identifier of the first task on the device side included in the request are used to indicate the specific task flow to which the recording task needs to be sent; and the second object identifier of the second synchronization object on the host side is used for the GPU driver module to find the first object identifier for recording the task status on the device side.

[0102] The GPU driver module searches for a first object identifier corresponding to the second object identifier according to a pre-stored association relationship, where the first object identifier indicates a first synchronization object on the device side.

[0103] The GPU driver module sends a recording task to the task scheduling driver module. The recording task includes a first object identifier, a context identifier for the first task on the device side, and a task flow identifier. Simultaneously, the GPU driver module increments the value of the second state identifier of the second synchronization object by one to record the issuance of the recording task.

[0104] After receiving the recording task, the task scheduling driving module determines the first task flow according to the context identifier and the task flow identifier, and then sends the recording task to the first task flow and ensures that the recording task is executed after the first task.

[0105] When the task scheduling driver module schedules the recording task to be executable (that is, the first task has been completed or other conditions are met), the task scheduling driver module adds one to the value of the first status identifier of the first object on the device side based on the first object identifier in the recording task. This operation indicates that the first task has been completed and its execution status is recorded in the first synchronization object.

[0106] After successfully updating the first state identifier of the first object, the task scheduling driver module marks the recording task as completed and returns a successful recording result to the host-side GPU driver module. This result includes the first object identifier of the first synchronization object on the device. The GPU driver module then determines the second object identifier corresponding to the first object identifier based on a pre-stored association relationship and returns the successful recording result, including the second object identifier, to the host-side user software.

[0107] The first state identifier and the second state identifier are used to track the state change of the synchronization object. By comparing the values ​​of the two state identifiers, it can be determined whether the task on the device side has been completed.

[0108] After successfully creating the first synchronization object, the execution timing of the second task can be determined based on the execution status of the first task recorded in the first synchronization object. Specifically, a waiting task can be sent to the device to query the execution status of the first object on the device.

[0109] In one possible implementation, the GPU driver module receives a waiting task sending request sent by user software on the host side, wherein the waiting task sending request includes: the second object identifier of the second synchronization object on the host side, the context identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier; the GPU driver module determines the first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is the identifier of the first synchronization object, and the second state identifier in the second object; the GPU driver module sends a waiting task to the task scheduling driver module, wherein the waiting task includes: the second state identifier, the context identifier and first object identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier.

[0110] In this implementation, the GPU driver module receives and processes the waiting task issuance request sent by the host-side user software, uses the pre-saved association relationship to determine the relevant synchronization objects and their status, and then sends the waiting task containing detailed context and task flow information to the task scheduling driver module, realizing flexible control of the task execution order and precise management of the synchronization object status, thereby improving the efficiency and reliability of task scheduling and resource utilization.

[0111] In one possible implementation, the task scheduling driver module receives the waiting task, determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device end, sends the waiting task to the second task flow, and continues to send the second task to the second task flow, so that the waiting task is executed before the second task.

[0112] In this implementation, the waiting tasks are received and processed by the task scheduling driver module, and the waiting tasks are sent to the specified second task flow, and are ensured to be executed before the second task, thereby achieving precise control of the task execution order, effectively managing the dependencies between tasks, and improving the flexibility of task scheduling and the overall operating efficiency of the system.

[0113] In one possible implementation, the task scheduling driver module, when scheduling the waiting task to be executable, determines the first state identifier of the first object based on the context identifier and the first object identifier of the first synchronization object on the device side; when it is determined that the first state identifier is greater than or equal to the second state identifier, marks the waiting task as completed and executes the second task, wherein the initial values ​​of the first state identifier and the second state identifier are the same.

[0114] In this implementation, when the task scheduling driver module schedules the waiting task to be executable, it checks whether the state identifier of the first synchronization object meets the preset conditions (that is, the first state identifier is greater than or equal to the second state identifier). After the conditions are met, the waiting task is marked as completed and subsequent tasks are executed, thereby ensuring the accuracy of synchronization between tasks, effectively managing the task execution order and dependencies, and improving the reliability of task scheduling and system efficiency.

[0115] See Figure 5 , Figure 5 A schematic diagram of the interactive process of issuing and executing waiting tasks provided by an embodiment of the present disclosure is shown.

[0116] The host-side user software sends a pending task dispatch request, and the GPU driver module receives the pending task dispatch request from the host-side user software. The request includes the second object identifier of the second synchronization object on the host side, the context identifier of the first synchronization object on the device side, the context identifier of the second task to be dispatched to the device side, and the task flow identifier.

[0117] Among them, the second object identifier of the second synchronization object on the host side contained in the request is used for the GPU driver module to find the first object identifier that records the task status on the device side; the context identifier of the first synchronization object on the device side is used to determine the context of the first synchronization object on the device side; the context identifier and task flow identifier of the second task to be sent to the device side are used to indicate the specific task flow to which the waiting task needs to be sent.

[0118] The GPU driver module searches for the first object identifier corresponding to the second object identifier based on the pre-stored association relationship and reads the value of the second state identifier in the second object.

[0119] The GPU driver module sends a waiting task to the task scheduling driver module. The waiting task includes the second state identifier, the context identifier and first object identifier of the first synchronization object on the device side, and the context identifier and task flow identifier of the second task to be sent to the device side.

[0120] Among them, the context identifier and first object identifier of the first synchronization object on the device side contained in the waiting task are used to determine the first object whose status identifier needs to be obtained; the second status identifier is used to compare with the first status identifier of the obtained first object to determine whether the first task is completed; the context identifier and task flow identifier of the second task to be sent to the device side are used to indicate the specific task flow to which the waiting task needs to be sent.

[0121] After receiving the waiting task, the task scheduling driver module determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device. Then, the task scheduling driver module sends the waiting task to the second task flow and ensures that the waiting task is executed before the second task.

[0122] When the task scheduling driving module schedules the waiting task to be executable, it determines the first state identifier of the first object according to the context identifier and the first object identifier of the first synchronization object on the device side.

[0123] If the value of the first state flag is greater than or equal to the value of the second state flag, indicating that the first task has been completed, the task scheduling driver module will mark the waiting task as completed and immediately execute the second task.

[0124] If the value of the first state identifier is less than the value of the second state identifier, the task scheduling driver module will wait for the next task scheduling cycle to obtain the first state identifier again, and compare the value of the first state identifier with the value of the second state identifier until the value of the first state identifier is greater than or equal to the value of the second state identifier.

[0125] Since the initial values ​​of the first state identifier and the second state identifier are the same, the GPU driver module increments the value of the second state identifier of the second synchronization object by one when sending the recording task to the task scheduling driver module; and the task scheduling driver module increments the value of the first state identifier of the first object on the device side by one when scheduling the recording task to be executable. Therefore, if the value of the first state identifier is greater than or equal to the value of the second state identifier, it indicates that the first task has been completed and the second task can be executed. Then, the waiting task can be marked as completed so that the second task can be executed.

[0126] An application scenario of the embodiment of the present disclosure is described below. Figure 6 As shown, Figure 6A schematic diagram of an application scenario provided by an embodiment of the present disclosure is shown. In this application scenario, after issuing the first task (task 2), a recording task is issued to the first task flow to which it is located, and then before issuing the second task (task 3), a waiting task is issued to the second task flow to which it is located. The synchronization object used is the same as the synchronization object used for the above-mentioned recording task, which can ensure that task 3 starts to execute after task 2 is completed, solving the task dependency problem between task flows.

[0127] In one possible implementation, the system for synchronizing task streams in a GPU may be executed by electronic devices such as terminal devices and servers. The terminal devices may be user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, vehicle-mounted devices, wearable devices, and the like. The system may be implemented by a processor calling computer-readable instructions stored in a memory.

[0128] In addition, the present disclosure also provides a method, electronic device, computer-readable storage medium, and program for synchronization between task streams in a GPU. The above can be used to implement any system for synchronization between task streams in a GPU provided by the present disclosure. The corresponding technical solutions and descriptions are referred to the corresponding records in the system part and will not be repeated here.

[0129] Figure 7 A flowchart of a method for synchronizing task flows in a GPU according to an embodiment of the present disclosure is shown. The method is applied to the above-mentioned system, which can include a GPU driver module on the host side and a task scheduling driver module in the GPU card, such as Figure 7 As shown, the method includes:

[0130] In step S201, the GPU driver module sends a recording task to the task scheduling driver module after sending the first task that is dependent on other tasks to the first task flow;

[0131] In step S202, the task scheduling driving module sends the recording task after the first task in the first task flow;

[0132] In step S203, the GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending the second task that is dependent on the first task to the second task flow;

[0133] In step S204, the task scheduling driving module sends the waiting task before the second task in the second task flow;

[0134] In step S205, after the first task is completed, the task scheduling driving module executes the recording task to set the first state flag in the first synchronization object on the device side to a state indicating that the recording task is completed;

[0135] In step S206 , after detecting that the first status flag indicates that the recording task is completed, the task scheduling driving module marks the waiting task as completed and executes the second task.

[0136] In one possible implementation, the GPU driver module receives a recording task issuance request sent by user software on the host side, wherein the recording task issuance request includes: a second object identifier of a second synchronization object on the host side, a context identifier and a task flow identifier of a first task on the device side; the GPU driver module determines a first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is an identifier of the first synchronization object; the GPU driver module sends a recording task to the task scheduling driver module, and adds one to the value of the second state identifier of the second synchronization object, wherein the recording task includes: the first object identifier, the context identifier and the task flow identifier of the first task on the device side.

[0137] In one possible implementation, the task scheduling driver module receives the recording task and determines the context to which the recording task is to be sent based on the context identifier in the recording task, and determines the first task flow in the context based on the task flow identifier in the recording task, and sends the recording task after the first task in the first task flow.

[0138] In a possible implementation, when the task scheduling driver module schedules the recording task to be executable, it adds one to the value of the first state identifier of the first object on the device side according to the first object identifier, and marks the recording task as completed.

[0139] In one possible implementation, the GPU driver module receives a waiting task sending request sent by user software on the host side, wherein the waiting task sending request includes: the second object identifier of the second synchronization object on the host side, the context identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier; the GPU driver module determines the first object identifier corresponding to the second object identifier based on a pre-saved association relationship, wherein the first object identifier is the identifier of the first synchronization object, and the second state identifier in the second object; the GPU driver module sends a waiting task to the task scheduling driver module, wherein the waiting task includes: the second state identifier, the context identifier and first object identifier of the first synchronization object on the device side, the context identifier of the second task to be sent to the device side, and the task flow identifier.

[0140] In one possible implementation, the task scheduling driver module receives the waiting task, determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device end, sends the waiting task to the second task flow, and continues to send the second task to the second task flow, so that the waiting task is executed before the second task.

[0141] In one possible implementation, the task scheduling driver module, when scheduling the waiting task to be executable, determines the first state identifier of the first object based on the context identifier and the first object identifier of the first synchronization object on the device side; when it is determined that the first state identifier is greater than or equal to the second state identifier, marks the waiting task as completed and executes the second task, wherein the initial values ​​of the first state identifier and the second state identifier are the same.

[0142] In one possible implementation, the GPU driver module, in response to a synchronization object creation request sent by user software, requests the task scheduling driver module to create a first synchronization object; the task scheduling driver module creates the first synchronization object in the context indicated by the synchronization object creation request, sends the first object identifier of the created first synchronization object to the GPU driver module, and initializes the first state identifier of the first synchronization object; the GPU driver module receives the first object identifier, creates a second synchronization object, associates and saves the second object identifier of the second synchronization object with the first object identifier, and initializes the second state identifier of the second synchronization object; the GPU driver module returns the second object identifier to the user software.

[0143] In one possible implementation, the GPU driver module, in response to a synchronization object destruction request sent by user software, determines the first object identifier based on the second object identifier in the synchronization object destruction request, and requests the task scheduling driver module to destroy the first synchronization object corresponding to the first object identifier; the task scheduling driver module, based on the first object identifier, destroys the first synchronization object in the context indicated by the synchronization object creation request, and returns a successful destruction result to the GPU driver module; the GPU driver module receives the successful destruction result, destroys the second synchronization object corresponding to the second object identifier, and returns the successful destruction result to the user software.

[0144] This method has a specific technical connection with the internal structure of the computer system, and can solve the technical problem of how to improve the hardware computing efficiency or execution effect (including reducing the amount of data storage, reducing the amount of data transmission, increasing the hardware processing speed, etc.), thereby obtaining the technical effect of improving the internal performance of the computer system in accordance with the laws of nature.

[0145] In some embodiments, the specific implementation of the method embodiment provided by the embodiments of the present disclosure can refer to the description of the system embodiment above, and for the sake of brevity, it will not be repeated here.

[0146] The present disclosure also provides a computer-readable storage medium having computer program instructions stored thereon, wherein the computer program instructions are executed by a processor to implement the above system. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0147] An embodiment of the present disclosure further proposes an electronic device, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to call the instructions stored in the memory to implement the above system.

[0148] An embodiment of the present disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device implements the above-mentioned system.

[0149] The electronic device may be provided as a terminal, a server, or other forms of devices.

[0150] Figure 8 FIG1 shows a block diagram of an electronic device 1900 according to an embodiment of the present disclosure. For example, the electronic device 1900 can be provided as a server or a terminal device. Figure 8The electronic device 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions executable by the processing component 1922, such as an application. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the above-described method.

[0151] The electronic device 1900 may further include a power supply component 1926 configured to perform power management of the electronic device 1900, a wired or wireless network interface 1950 configured to connect the electronic device 1900 to a network, and an input / output (I / O) interface 1958. The electronic device 1900 may operate based on an operating system stored in the memory 1932, such as a Microsoft Server operating system (Windows Server 2003). TM ), a graphical user interface operating system launched by Apple (Mac OSX TM ), a multi-user, multi-process computer operating system (Unix TM ), a free and open source Unix-like operating system (Linux TM ), an open-source Unix-like operating system (FreeBSD TM ) or similar.

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

[0153] The present disclosure may be a system, method and / or computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present disclosure.

[0154] Computer-readable storage media can be a tangible device that can hold and store the instructions used by the instruction execution device. Computer-readable storage media can be, for example, (but not limited to) an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, for example, a punch card or a convex structure in a groove on which instructions are stored, and any suitable combination thereof. Computer-readable storage media used herein is not interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses by fiber optic cables), or electrical signals transmitted by wires.

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

[0156] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., utilizing an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions. The electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

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

[0158] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

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

[0160] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and the part of the module, program segment or instruction contains one or more executable instructions for realizing the prescribed logical function. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the prescribed function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0161] The computer program product may be implemented in hardware, software, or a combination thereof. In one embodiment, the computer program product is implemented as a computer storage medium. In another embodiment, the computer program product is implemented as a software product, such as a software development kit (SDK).

[0162] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced with each other and will not be repeated herein for the sake of brevity.

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

[0164] If the technical solution of this application involves personal information, the product that applies the technical solution of this application has clearly informed the personal information processing rules and obtained the individual's voluntary consent before processing personal information. If the technical solution of this application involves sensitive personal information, the product that applies the technical solution of this application has obtained the individual's separate consent before processing sensitive personal information, and at the same time meets the "explicit consent" requirement. For example, on personal information collection devices such as cameras, a clear and prominent sign is set to inform that the personal information collection scope has been entered and personal information will be collected. If the individual voluntarily enters the collection scope, it is deemed that they agree to the collection of their personal information; or on the personal information processing device, when the personal information processing rules are notified by obvious signs / information, the individual's authorization is obtained through pop-up information or by asking the individual to upload their personal information; among which, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the type of personal information processed.

[0165] While various embodiments of the present disclosure have been described above, the above descriptions are illustrative, non-exhaustive, and not intended to be limiting of the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A system for synchronizing task flows in a GPU, characterized in that: It includes the GPU driver module on the host side and the task scheduling driver module in the GPU card, including: The GPU driver module sends a recording task to the task scheduling driver module after sending the first task that is dependent on other tasks to the first task flow; the task scheduling driver module sends the recording task after the first task in the first task flow; The GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to the second task flow; the task scheduling driver module sends the waiting task before the second task in the second task flow; The task scheduling driving module executes the recording task after the first task is completed, so as to set the first state identifier in the first synchronization object on the device end to a state indicating that the recording task is completed; The task scheduling driving module, after detecting that the first status identifier indicates that the recording task is completed, marks the waiting task as completed and executes the second task; The task scheduling driving module receives the waiting task, determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device end, sends the waiting task to the second task flow, and continues to send the second task to the second task flow so that the waiting task is executed before the second task.

2. The system according to claim 1, wherein: The GPU driver module receives a recording task issuing request sent by the user software on the host side, wherein the recording task issuing request includes: a second object identifier of a second synchronization object on the host side, a context identifier of a first task on the device side, and a task flow identifier; The GPU driver module determines, based on a pre-stored association relationship, a first object identifier corresponding to the second object identifier, where the first object identifier is an identifier of the first synchronization object; The GPU driver module sends a recording task to the task scheduling driver module and increases the value of the second state identifier of the second synchronization object by one. The recording task includes: the first object identifier, the context identifier of the first task on the device side, and the task flow identifier.

3. The system according to claim 2, characterized in that: The task scheduling driving module receives the recording task and determines the context to which the recording task is to be sent based on the context identifier in the recording task, and determines the first task flow in the context based on the task flow identifier in the recording task, and sends the recording task to after the first task in the first task flow.

4. The system according to claim 2, wherein: When the recording task is scheduled to be executable, the task scheduling driving module increases the value of the first state identifier of the first object on the device side by one according to the first object identifier, and marks the recording task as completed.

5. The system according to claim 1, wherein: The GPU driver module receives a waiting task issuance request sent by user software on the host side, wherein the waiting task issuance request includes: a second object identifier of a second synchronization object on the host side, a context identifier of a first synchronization object on the device side, a context identifier of a second task to be issued to the device side, and a task flow identifier; The GPU driver module determines, based on a pre-stored association relationship, a first object identifier corresponding to the second object identifier, the first object identifier being an identifier of the first synchronization object, and a second state identifier in the second object; The GPU driver module sends a waiting task to the task scheduling driver module, and the waiting task includes: the second state identifier, the context identifier and the first object identifier of the first synchronization object on the device side, and the context identifier and the task flow identifier of the second task to be sent to the device side.

6. The system according to claim 5, characterized in that: The task scheduling driving module determines the first state identifier of the first object according to the context identifier and the first object identifier of the first synchronization object on the device side when the waiting task is scheduled to be executable; When it is determined that the first state identifier is greater than or equal to the second state identifier, the waiting task is marked as completed and the second task is executed, wherein the initial values ​​of the first state identifier and the second state identifier are the same.

7. The system according to claim 1, wherein: The GPU driver module, in response to the synchronization object creation request sent by the user software, requests the task scheduling driver module to create a first synchronization object; The task scheduling driver module creates a first synchronization object in the context indicated by the synchronization object creation request, sends a first object identifier of the created first synchronization object to the GPU driver module, and initializes a first state identifier of the first synchronization object; The GPU driver module receives the first object identifier, creates a second synchronization object, associates and stores a second object identifier of the second synchronization object with the first object identifier, and initializes a second state identifier of the second synchronization object; The GPU driver module returns the second object identifier to the user software.

8. The system according to claim 1, wherein: The GPU driver module, in response to the synchronization object destruction request sent by the user software, determines the first object identifier according to the second object identifier in the synchronization object destruction request, and requests the task scheduling driver module to destroy the first synchronization object corresponding to the first object identifier; The task scheduling driver module destroys the first synchronization object in the context of the synchronization object creation request indication according to the first object identifier, and returns a result of successful destruction to the GPU driver module; The GPU driver module receives the successful destruction result, destroys the second synchronization object corresponding to the second object identifier, and returns the successful destruction result to the user software.

9. A method for synchronizing task flows in a GPU, characterized in that: The method is applied to the system according to any one of claims 1 to 8, wherein the system may include a GPU driver module on a host side and a task scheduling driver module in a GPU card, and the method includes: After the GPU driver module issues the first task, which is dependent on other tasks, to the first task flow, it sends the recording task to the task scheduling driver module; the task scheduling driver module issues the recording task after the first task in the first task flow; The GPU driver module sends a waiting task to the task scheduling driver module in the GPU card before sending a second task that is dependent on the first task to the second task flow; the task scheduling driver module sends the waiting task before the second task in the second task flow; After the first task is completed, the task scheduling driving module executes the recording task to set the first state identifier in the first synchronization object on the device end to a state indicating that the recording task is completed; After detecting that the first status identifier indicates that the recording task is completed, the task scheduling driving module marks the waiting task as completed and executes the second task; The task scheduling driving module receives the waiting task, determines the second task flow based on the context identifier and task flow identifier of the second task to be sent to the device end, sends the waiting task to the second task flow, and continues to send the second task to the second task flow so that the waiting task is executed before the second task.

10. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to implement the system according to any one of claims 1 to 8.

11. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the system according to any one of claims 1 to 8 is implemented.

Images