First processing device, second processing device, processing method and processing system

Abstract

The present disclosure provides a first processing device, a second processing device, a processing method and a processing system, and belongs to the technical field of computers. The first processing device is configured to generate a target instruction sequence of a data processing task, determine association information between context containers carrying kernel functions, and send the target instruction sequence to the second processing device for execution; in response to receiving a target interrupt event reported by the second processing device, determine a first target context container according to the target interrupt event, and determine a second target context container having an association relationship with the first target context container according to the association information; perform a readiness check on the kernel functions carried by the first target context container and the second target context container, and in a case where it is determined that there is a ready kernel function, send processing instruction information to the second processing device. The embodiments of the present disclosure can timely and comprehensively detect the ready kernel function, and reduce hardware overhead.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a first processing device, a second processing device, a processing method, and a processing system. Background Technology

[0002] A kernel is a basic computational execution unit that runs on the parallel computing core of a graphics processing unit (GPU). It is the smallest task carrier used by the GPU to complete large-scale parallel computing. Within the dedicated execution resources allocated by the GPU hardware, it executes computational logic in a massive thread parallel manner.

[0003] In related technologies, a snoop filter is typically attached to each bus interface unit to detect and track atomic requests, ensuring that the corresponding data processing can be executed accurately and in an orderly manner. However, due to the need for continuous monitoring of atomic operations and the complex and diverse nesting patterns, the required resource overhead is high, and the register monitoring configuration is also quite complex. Summary of the Invention

[0004] This disclosure provides a first processing device, a second processing device, a processing method, and a processing system.

[0005] In a first aspect, this disclosure provides a first processing device for collaboratively executing a data processing task with a second processing device, the data processing task being completed based on multiple kernel functions; the first processing device is configured to: generate a target instruction sequence for the data processing task, determine the association information between context containers used to carry the kernel functions, and send the target instruction sequence to the second processing device for execution; the target instruction sequence includes a function execution instruction for executing kernel functions, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction, the interrupt trigger instruction corresponding to the dependency update instruction and used to trigger a cross-context container check to see if the kernel functions have released their dependencies; in response to receiving a target interrupt event reported by the second processing device, determine a first target context container based on the target interrupt event, and determine a second target context container that has an association with the first target context container based on the association information; perform a readiness check on the kernel functions carried by the first target context container and the second target context container, and if it is determined that there are ready kernel functions, send processing instruction information to the second processing device, the processing instruction information being used to instruct the second processing device to start the ready kernel functions.

[0006] Secondly, this disclosure provides a second processing device for collaboratively executing a data processing task with a first processing device, the data processing task being completed based on multiple kernel functions; the second processing device is configured to: receive a target instruction sequence sent by the first processing device, the target instruction sequence including a function execution instruction for executing kernel functions, a dependency update instruction for updating dependencies between kernel functions, and an interrupt trigger instruction, the interrupt trigger instruction corresponding to the dependency update instruction and used to trigger a cross-context container check whether kernel functions have released dependencies; during the execution of the target instruction sequence, in response to the execution of the interrupt trigger instruction, report a target interrupt event to the first processing device, and upon receiving processing instruction information sent by the first processing device, start the kernel function indicated by the processing instruction information.

[0007] Thirdly, this disclosure provides a processing method applied to a first processing device, which is used to collaboratively execute a data processing task with a second processing device. The data processing task is completed based on multiple kernel functions. The method includes: generating a target instruction sequence for the data processing task, determining association information between context containers used to carry the kernel functions, and sending the target instruction sequence to the second processing device for execution. The target instruction sequence includes a function execution instruction for executing the kernel functions, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel functions have released their dependencies. In response to receiving a target interrupt event reported by the second processing device, determining a first target context container based on the target interrupt event, and determining a second target context container that is associated with the first target context container based on the association information. Performing a readiness check on the kernel functions carried by the first target context container and the second target context container, and, if it is determined that there are ready kernel functions, sending processing instruction information to the second processing device, the processing instruction information being used to instruct the second processing device to start the ready kernel functions.

[0008] Fourthly, this disclosure provides a processing method applied to a second processing device, the second processing device being used to collaboratively execute a data processing task with a first processing device, the data processing task being completed based on multiple kernel functions; the method includes: receiving a target instruction sequence sent by the first processing device, the target instruction sequence including a function execution instruction for executing kernel functions, a dependency update instruction for updating dependencies between kernel functions, and an interrupt trigger instruction, the interrupt trigger instruction corresponding to the dependency update instruction and used to trigger a cross-context container check whether kernel functions have released dependencies; during the execution of the target instruction sequence, in response to the execution of the interrupt trigger instruction, reporting a target interrupt event to the first processing device, and, upon receiving processing indication information sent by the first processing device, starting the kernel function indicated by the processing indication information.

[0009] Fifthly, this disclosure provides a processing system, which includes a first processing device and a second processing device; the first processing device is the first processing device described above; and the second processing device is the second processing device described above.

[0010] The first processing device provided in this embodiment can cooperate with a second processing device to execute data processing tasks. The first processing device generates a target instruction sequence for the data processing task, determines the association information between context containers used to carry kernel functions, and sends the target instruction sequence to the second processing device for execution. The target instruction sequence includes function execution instructions, dependency update instructions, and interrupt trigger instructions. The interrupt trigger instructions can trigger a cross-context container check to see if the kernel functions have released their dependencies. In response to receiving a target interrupt event reported by the second processing device, the first target context container is determined based on the target interrupt event, and a second target context container that is associated with the first target context container is determined based on the association information. The kernel functions carried by the first target context container and the second target context container are checked for readiness, and if a ready kernel function is determined, processing instruction information is sent to the second processing device. The processing instruction information can instruct the second processing device to start the ready kernel function.

[0011] Therefore, in this embodiment, on the one hand, a target instruction sequence is determined based on the data processing task so that the second processing device can execute the data processing task accurately and orderly. In this process, the dependency update instruction is used to explicitly update the dependency relationship between kernel functions, reducing the number and complexity of listening to atomic operations by the hardware, which can effectively reduce hardware overhead. On the other hand, the association information between context containers is also determined based on the data processing task. After the second processing device reports the target interrupt event to the first processing device through the interrupt trigger instruction, it can check whether the kernel functions have released their dependencies across context containers. This allows for timely readiness checks of kernel functions in the first target context container and also timely readiness checks of kernel functions in the second target context container that are associated with the first target context container. This effectively expands the scope of readiness checks, enabling more timely and comprehensive discovery of ready kernel functions, thereby activating these ready kernel functions in a timely manner and improving task processing efficiency.

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

[0013] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0014] Figure 1 This is a schematic diagram of kernel function startup provided for related technologies.

[0015] Figure 2 A schematic diagram for eavesdropping detection provided for related technologies.

[0016] Figure 3 This is a block diagram of a first processing device provided in an embodiment of the present disclosure.

[0017] Figure 4 This is a block diagram of a second processing device provided in an embodiment of the present disclosure.

[0018] Figure 5 This is a schematic diagram illustrating the interaction process between a first processing device and a second processing device, provided as an embodiment of this disclosure.

[0019] Figure 6 This is a schematic diagram illustrating the execution process of a kernel function provided in an embodiment of this disclosure.

[0020] Figure 7 A flowchart of a processing method provided in an embodiment of this disclosure.

[0021] Figure 8 A flowchart of another processing method provided in an embodiment of this disclosure.

[0022] Figure 9 This is a block diagram of a processing system provided in an embodiment of the present disclosure. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should 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.

[0024] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0025] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0027] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0028] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations. For example, appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identification is eliminated when using personal information to avoid precisely targeting specific individuals.

[0029] In related technologies, for scenarios such as parallel computing, the host side usually initiates a kernel function launch request, and the device side responds to the request and performs kernel function launch and other related processes.

[0030] Figure 1 This diagram illustrates the startup process of a kernel function, providing insights for related technologies. (Refer to...) Figure 1 The host computer includes a processor, which can be a Central Processing Unit (CPU), while the device can be a graphics processing unit (GPU) based processing device. The host computer can initiate a kernel function start request to the device via the high-speed peripheral component interconnect bus (PCIe Bus), and the device responds to the kernel function start request and starts the kernel function. The device can also set up fences to mark task completion points, control the order of operations, and ensure data consistency, thereby achieving synchronization between the CPU and GPU, and between different modules within the GPU.

[0031] Since the host and the device are independent hardware devices, they must exchange data through a preset bus. Physical communication has a certain delay, and in addition, several verification processes need to be performed, resulting in a large time overhead for starting the kernel function.

[0032] Based on this, kernel functions can be launched directly on the device side. The first method is based on a kernel graph; the second method involves complex situations such as nested launches, where a parent kernel launches a new child kernel, and the child kernel can then become a new parent kernel to launch new child kernels, and a parent kernel can contain multiple child kernels.

[0033] For the second scenario, the relevant technology typically involves adding a snoop filter to each Bus Interface Function (BIF). After detecting an atomic request, the snoop filter determines whether it has hit the current snoop filter based on the base address. If it has, it calculates the corresponding bit in the register based on the bit offset. Upon completion of the atomic operation and receipt of the completion response packet, the snoop filter writes a preset value to the corresponding bit in the register and sends an interrupt signal to wake up the driver or firmware to handle the interrupt. After the driver or firmware handles the interrupt, it writes a preset value to the corresponding register to clear the previous status bit, allowing the snoop filter to return to the idle state and continue its monitoring operations.

[0034] Figure 2 A schematic diagram illustrating eavesdropping detection for related technologies. (Refer to...) Figure 2 It describes the processing of a 32-bit atomic request received by the snooping filter 15 (SPFilter 15).

[0035] ① Atomic request input: A 32-bit atomic request is initiated on the GPU bus with a target address of 0x10080. This atomic request originates from the dynamic parallel operation of the Child Kernel started by the Parent Kernel on the device side and enters the monitoring port of SPFilter15.

[0036] ② Rule matching configuration, mainly including address range verification and bit offset calculation.

[0037] The address range check is mainly used to confirm whether the destination address 0x10080 of the atomic request is within the monitoring range defined by the base address 0x10000 (base address) of SPFilter15. If it is, SPFilter15 is hit; if it is not, SPFilter15 is not hit and no further operation is required. The bit offset calculation is mainly based on the address difference between the destination address and the base address of the atomic request, combined with the pre-set monitoring granularity, to calculate the 3rd bit (i.e., bit3) of the dedicated register corresponding to the atomic request.

[0038] ③ Atomic requests are passed through, thus achieving non-blocking forwarding. In other words, SPFilter15 is designed for bypass monitoring and will not block the normal execution of atomic requests. The atomic request will flow normally to the GPU memory controller or other functional modules to perform the actual atomic read and write operations, achieving zero performance overhead.

[0039] ④ Atomic operation completion response mainly refers to the bus returning a completion response packet or other messages after the atomic operation is completed, so that SPFilter15 can confirm that the lifecycle of the atomic request has ended.

[0040] ⑤ Status setting and interrupt triggering: SPFilter15 can report interrupts and assist in interrupt handling through register settings. Specifically, setting a dedicated register (such as CR_SPFILTER15) involves writing 1 to bit 3 of the dedicated register, marking that SPFilter15 has captured an atomic operation event. Setting a global register (such as CR_SPFILTER_UPDATES) involves writing 1 to bit 15 of the global register (bit 15 corresponds to the SPFilter15's Filter ID), used to mark that SPFilter15 has undergone a status update, for use in driving interrupts or polling status. Interrupt sending refers to sending an interrupt signal to the GPU's interrupt request to wake up the driver or firmware for further processing. Furthermore, after processing the interrupt reported by SPFilter15, a new value can be written to the global register to clear the SPFilter15's status, allowing SPFilter15 to return to the idle state and resume monitoring atomic requests.

[0041] ⑥ Return the processing result, completion status, and other result data of the atomic request to the initiator of the atomic request (such as the host or a certain processing core).

[0042] In summary, since it typically takes multiple time cycles from issuing an atomic request to its completion, continuous monitoring is required during this period. Therefore, the snooping filter needs to maintain a complete listening state for each address performing an atomic operation. Moreover, there may be many addresses performing atomic operations at the same time, and each atomic operation requires an independent listening context. This results in a large number of registers and a complex state machine, making the register listening configuration quite complex. Furthermore, during module reconstruction, there is a risk that some module functionalities may be removed.

[0043] In view of the above, embodiments of this disclosure provide a first processing device, a second processing device, a processing method, and a processing system.

[0044] In a first aspect, embodiments of this disclosure provide a first processing apparatus.

[0045] Figure 3 This is a block diagram of a first processing device 300 provided in an embodiment of the present disclosure. The first processing device 300 is used to cooperate with a second processing device to perform data processing tasks, which are completed based on multiple kernel functions.

[0046] The first processing device is used for:

[0047] A target instruction sequence for the data processing task is generated, the association information between the context containers used to carry the kernel function is determined, and the target instruction sequence is sent to the second processing device for execution. The target instruction sequence includes function execution instructions for executing the kernel function, dependency update instructions for updating the dependencies between kernel functions, and interrupt trigger instructions. The interrupt trigger instructions correspond to the dependency update instructions and are used to trigger cross-context container checks to see if the kernel functions have released their dependencies.

[0048] In response to receiving a target interrupt event reported by the second processing device, a first target context container is determined based on the target interrupt event, and a second target context container that is associated with the first target context container is determined based on the association information.

[0049] The kernel functions carried by the first target context container and the second target context container are checked for readiness. If a ready kernel function is found, a processing instruction message is sent to the second processing device. The processing instruction message is used to instruct the second processing device to start the ready kernel function.

[0050] In some optional embodiments, the first processing device and the second processing device include devices with certain processing and storage capabilities and capable of performing data processing.

[0051] Furthermore, in some alternative implementations, the first processing device includes a general-purpose processor, and the second processing device includes a dedicated processor, which can work together to complete the data processing task.

[0052] For example, the first processing device includes a CPU, and the second processing device includes a GPU, a general-purpose computing on graphics processing unit (GPGPU), a tensor processing unit, a neural network processing unit (NPU), a deep learning processing unit (DPU), and a brain processing unit (BPU), etc., and the embodiments disclosed herein are not limited thereto.

[0053] In some optional embodiments, the first processing device includes a firmware module, which is a low-level control program embedded in the hardware of the first processing device. It starts upon power-on and can directly manipulate hardware registers and circuits. Upon receiving a target interrupt event, the first processing device can utilize the firmware module to locate the first target context container and the second target context container, perform readiness checks on the kernel functions within them, and return processing instruction information to the second processing device based on the readiness check results.

[0054] In some optional embodiments, the data processing task may include serial computing tasks, parallel computing tasks, such as model training tasks, model inference tasks, etc., and the embodiments disclosed herein do not limit this.

[0055] In some optional embodiments, data processing tasks can be completed based on multiple kernel functions. A kernel function is essentially an executable function that can be used to perform specific data processing. By encapsulating some commonly used or important executable functions into kernel functions, scheduling efficiency can be improved, and batch modification and unified maintenance can be supported.

[0056] For example, kernel functions include an Add kernel function for performing addition operations, a vectorMul kernel function for performing vector multiplication operations, a matrixMul kernel function for performing matrix multiplication operations, etc., and this disclosure does not limit the scope of the embodiments.

[0057] In some alternative implementations, a data processing task can be implemented using multiple kernel functions. For example, multiple data processing steps in a data processing task can be broken down and each step can be performed by a kernel function capable of executing the corresponding data processing step.

[0058] Furthermore, there may be certain dependencies between some kernel functions, which means that the execution result or execution conditions of one kernel function may depend on one or more other kernel functions.

[0059] It should be noted that this dependency between kernel functions is an important foundation for the accurate and orderly execution of various data processing tasks, and a key constraint to ensure the correctness of calculations. This constraint can improve the accuracy of the results of data processing tasks.

[0060] In some optional embodiments, kernel functions need to be hosted in a context container, which is an independent and isolated task execution environment that can contain all the runtime state resources required to execute one or more kernel functions. This approach reduces mutual interference between kernel functions and improves processing efficiency.

[0061] Furthermore, there may be relationships between some context containers, and these relationships can be represented based on association information. Whether a relationship exists between context containers is related to whether the kernel functions running within those context containers have cross-context dependencies. In other words, by determining whether the kernel functions running in the current context container have dependencies on kernel functions running in other context containers, we can ascertain whether a relationship exists between the current context container and other context containers.

[0062] For example, if context container A contains kernel function a and context container B contains kernel function b, and the execution of kernel function a is independent of the execution of kernel function b, then there is no relationship between context container A and context container B; however, if the execution of kernel function b requires the computation result of kernel function a, then there is a relationship between context container A and context container B. In other words, if kernel functions have dependencies on each other, and these kernel functions are hosted by different context containers, then there is a relationship between these different context containers.

[0063] Furthermore, after determining the data processing task, the first processing device can generate a target instruction sequence for the data processing task and send it to the second processing device so that the second processing device can orderly, accurately, and efficiently call upon the corresponding resources to execute the data processing task. The target instruction sequence is a stream of instructions arranged in a certain order that can be recognized and executed by the second processing device.

[0064] In some optional embodiments, the target instruction sequence includes at least three types of instructions: function execution instructions, dependency update instructions, and interrupt trigger instructions. Function execution instructions are instructions that perform corresponding data processing using the corresponding kernel function. Dependency update instructions are used to update the dependencies between corresponding kernel functions. Interrupt trigger instructions correspond to at least some of the dependency update instructions and are used to trigger a cross-context container check to see if kernel functions have released their dependencies. In other words, if the dependency update instructions do not involve updating cross-context container dependencies but only update the dependencies between kernel functions within the same context container, then no interrupt trigger instruction will be set subsequently.

[0065] Furthermore, as mentioned earlier, if we only use a snooping filter at the hardware level to monitor atomic operations to ensure that each kernel function can be executed in an orderly and accurate manner, the snooping filter needs to maintain a complete snooping state for each address that is performing an atomic operation. Moreover, there may be many addresses performing atomic operations at the same time, and each address needs an independent snooping context. Therefore, the required number of registers is large, the state machine is complex, and the register snooping configuration is also quite complex.

[0066] In contrast, in this embodiment of the disclosure, by parsing and processing the data processing task, a corresponding target instruction sequence can be obtained. During this process, the dependencies between kernel functions are explicitly updated through dependency update instructions. In other words, the dependency update instructions can be used to update the complex and dynamically changing dependencies between kernel functions in a timely and accurate manner. Kernel functions that are not ready will not be started prematurely. Based on this, the number of atomic operations that need to be monitored at the hardware level is effectively reduced, the complexity of monitoring is also reduced, the requirement for the number of registers is significantly reduced, and the monitoring configuration can be simplified accordingly.

[0067] In some optional embodiments, the first processing device sends the target instruction sequence to the second processing device, which receives the target instruction sequence and can execute each instruction sequentially. Specifically, when a function execution instruction is executed, the corresponding kernel function is called to perform the corresponding data processing; when a dependency update instruction is executed, the dependencies between corresponding kernel functions are updated; and when an interrupt trigger instruction is executed, a target interrupt event is reported to the first processing device.

[0068] It should be noted that the second processing device can report various types of interrupt events to the first processing device. The target interrupt event specifically refers to the interrupt event that triggers the first processing device to perform a kernel function readiness check across the context container. The type of interrupt event can be reported together with the interrupt event or reported separately. This embodiment of the present disclosure does not limit this.

[0069] For the first processing device, upon receiving a target interrupt event, it determines the first target context container directly corresponding to the target interrupt event, and determines whether a second target context container associated with the first target context container exists based on the association information. If it exists, it performs a readiness check on all kernel functions carried by the first and second target context containers, obtaining the readiness check results for these kernel functions. If it does not exist, it performs a readiness check on all kernel functions carried by the first target context container, obtaining the readiness check results for these kernel functions. Further, if the readiness check result indicates that a certain kernel function is ready, the first processing device can send processing instruction information to the second processing device to instruct the startup of the ready kernel function.

[0070] Therefore, by using dependency update instructions and interrupt trigger instructions, the dependencies between kernel functions can be updated in a timely and accurate manner, and readiness checks can be triggered on a large range of kernel functions with a high probability of being ready. This allows for precise control over the timing of kernel function startup, ensuring that kernel functions are only started and executed after they are truly ready (i.e., all dependencies are removed). This alleviates the monitoring pressure at the hardware level, reduces the number of registers required, and also lowers the complexity of register monitoring configuration.

[0071] The readiness check of the kernel functions carried by the first target context container and the second target context container can be performed on all kernel functions carried by the first target context container and the second target context container, or it can be performed on some kernel functions carried by the first target context container and the second target context container based on the interrupt identifier carried by the target interrupt event. For example, when the interrupt identifier is a kernel function identifier, the kernel function corresponding to the kernel function identifier can be checked for readiness. When the interrupt identifier is a stream identifier, the kernel function running on the execution stream corresponding to the stream identifier can be checked for readiness. This disclosure does not limit this.

[0072] In cases where the readiness check result indicates that the kernel function has removed all dependencies and has not yet been started, the kernel function can be determined to be a ready kernel function.

[0073] It should be noted that the target instruction sequence can be pre-compiled. During the pre-compilation process, the number of clock cycles required for kernel function execution can be estimated, and based on this, the positions of function execution instructions, dependency update instructions, and interrupt trigger instructions can be determined. For example, if the execution of kernel function B depends on the execution result of kernel function A, and the function execution instructions of kernel function A precede those of kernel function B, the dependency update instructions (used to update the dependency relationship between kernel function B and the execution result of kernel function A) and the interrupt trigger instructions are located between these two function execution instructions. When the second processing device executes the dependency update instructions and the interrupt trigger instructions, the function execution instructions of kernel function A may not have finished executing. While the second processing device sends an interrupt to the first processing device, it can continue executing the function execution instructions of kernel function A. After the first processing device receives the target interrupt event, determines that kernel function B can be started, and sends a concurrent instruction to the second processing device, the function execution instructions of kernel function A can be completed before the second processing device actually starts kernel function B.

[0074] In other words, during the data operations corresponding to the function execution instructions of kernel function A executed by the second processing device, if an interrupt trigger instruction is encountered, a target interrupt event can be reported to the first processing device, and the data operations of kernel function A can continue unaffected. Simultaneously, in response to the target interrupt event, the first processing device performs a readiness check on at least one kernel function, including kernel function B, to determine that kernel function B can be started and concurrently instructed to the second processing device. During the aforementioned processing by the first processing device, the data operations of kernel function A in the second processing device can continue, as long as all data operations of kernel function A can be completed and the execution result of kernel function A obtained before the second processing device starts kernel function B based on the instruction. In this way, the latency of kernel function execution can be further reduced, improving device execution efficiency.

[0075] Therefore, by pre-compiling and optimizing the target instruction sequence and combining the kernel function clock cycle prediction results, the positions of various instructions can be flexibly arranged, breaking the inherent execution logic of processing subsequent instructions only after the preceding instructions have been fully executed. Thus, the waiting delay time during kernel function execution can be effectively reduced, the overall task execution time can be shortened, the overall execution efficiency of multi-processing device collaborative computing can be improved, and the performance of multi-device parallel operation can be optimized.

[0076] In summary, in this embodiment of the present disclosure, the target instruction sequence is determined based on the data processing task.

[0077] This allows the second processing device to execute the data processing task accurately and orderly. During this process, dependency update instructions are used to explicitly update the dependencies between kernel functions, reducing the number and complexity of hardware monitoring atomic operations and effectively lowering hardware overhead. Furthermore, the association information between context containers is determined based on the data processing task. After the second processing device reports a target interrupt event to the first processing device via an interrupt trigger instruction, it can check whether kernel functions have resolved dependencies across context containers. This allows for timely readiness checks of kernel functions within the first target context container and also timely readiness checks of kernel functions within the second target context container that are associated with the first target context container. This effectively expands the scope of readiness checks, enabling more timely and comprehensive discovery of ready kernel functions, thus facilitating their timely activation and improving task processing efficiency.

[0078] The first processing device according to an embodiment of this disclosure will now be described in detail.

[0079] In some optional embodiments, the first processing device is configured to: parse a data processing task to obtain multiple kernel functions, dependencies between kernel functions, and association information; determine multiple function execution instructions based on the multiple kernel functions; insert at least one dependency update instruction into the multiple function execution instructions based on the dependencies between kernel functions; and set an interrupt trigger instruction after the dependency update instruction corresponding to the cross-context dependency based on the association information to obtain a target instruction sequence, wherein the cross-context dependency is used to characterize the dependency relationship between the corresponding kernel functions, and the corresponding kernel functions are respectively carried by different context containers.

[0080] It should be noted that, for situations where it is necessary to update the dependencies between kernel functions, corresponding dependency update instructions can be set to update the dependencies. On this basis, an interrupt trigger instruction is only set after the dependency update instruction that updates dependencies across contexts. For dependency update instructions that update dependencies between kernel functions within the same context container, it is not necessary to set an interrupt trigger instruction after them. The second processing device can determine which processing needs to be performed (such as suspending kernel functions, resuming kernel functions, etc.) based on the dependency update results.

[0081] Therefore, it can be seen that when the first processing device generates the target instruction sequence, it follows the following processing logic: First, it performs multi-dimensional analysis of the data processing task to clarify the kernel functions used, the dependencies between these kernel functions, and the association information between the context containers that carry the kernel functions. Then, it determines the corresponding kernel function execution instructions based on the most basic kernel function. Next, it inserts dependency update instructions at appropriate positions based on the dependencies between kernel functions. Then, it identifies dependency update instructions that have cross-context dependency updates and sets interrupt trigger instructions afterward to ensure that cross-context container checks are triggered to see if the dependencies between kernel functions are removed.

[0082] In summary, by performing a comprehensive analysis of the data processing task, core data such as kernel functions, dependencies, and related information can be fully obtained, providing comprehensive data support for the accurate generation of the target instruction sequence. This overcomes instruction logic errors caused by incomplete or incorrect analysis, improving the accuracy of instruction sequence generation. Inserting dependency update instructions at corresponding positions based on kernel function dependencies enables ordered and constrained execution of kernel functions, reducing computational conflicts and data anomalies caused by disordered kernel function execution, thus improving the execution standardization of the data processing task. Furthermore, configuring corresponding interrupt trigger instructions for cross-context dependency updates can solve the problem of collaborative execution of kernel functions between different context containers, minimizing the issue of ready kernel functions failing to start in a timely manner due to the inability to identify or perceive the removal of dependencies across context containers. This fills the gap in the inability to perform readiness checks on kernel functions across context containers, improving the detection rate of ready kernel functions and contributing to improved overall processing efficiency.

[0083] In some optional embodiments, a data processing task can correspond to an application, which includes which parent kernel function can launch which child kernel functions, data dependency information between kernel functions, logical dependency information between kernel functions, etc. By parsing and compiling the application, the dependency relationship between kernel functions can be determined, and the dependency relationship value of each kernel function can be initialized, thereby generating a target instruction sequence corresponding to the data processing task.

[0084] In other words, the dynamic and complex dependencies between kernel functions can be quantified into dependency values, so that the dependencies between kernel functions can be updated accurately and conveniently through dependency update instructions, ensuring that all data processing runs in an orderly manner.

[0085] Furthermore, the data dependency information between kernel functions is used to characterize the dependency relationship between kernel functions with respect to the data dimension. For example, if kernel function B needs to perform calculations on the processing result of kernel function A, then there is a data dependency relationship between kernel function B and kernel function A (i.e., kernel function B depends on kernel function A). The logical dependency information between kernel functions is used to characterize the dependency relationship between kernel functions with respect to the processing logic dimension. For example, if kernel function C is used to preprocess sample data and kernel function D is used to perform feature extraction, then since the processing logic usually requires preprocessing before feature extraction, there is a logical dependency relationship between kernel function D and kernel function C (i.e., kernel function D depends on kernel function C).

[0086] It should be noted that the kernel functions that a kernel function depends on may include its parent kernel function, other kernel functions, or both parent and other kernel functions. This embodiment of the present disclosure does not impose any limitations on this. However, after determining that the kernel function has its dependency removed, it is necessary to start the kernel function through its parent kernel function.

[0087] In some optional embodiments, the interrupt triggering instruction includes the NOP.trigger instruction. The NOP.trigger instruction is a special instruction that combines the basic characteristics of a NoOperation (NOP) with the function of triggering hardware events. It does not require any valid data processing, yet it has the ability to trigger specific hardware events, thus enabling efficient and convenient triggering of target interrupt events.

[0088] It should be noted that the above examples of interrupt triggering instructions are merely illustrative and are not intended to limit the scope of this disclosure.

[0089] In some optional embodiments, the context container includes a first context container and a second context container; the first processing device is configured to: determine that there is an association between the first context container and the second context container when it is determined that the output data of the kernel function in the first context container is the input data of the kernel function in the second context container, and generate corresponding association information.

[0090] The first context container is any one of many independent context containers, capable of independently carrying out the computation and execution of one or more kernel functions. The second context container is another independent runtime container, distinct from the first context container, and its resources are isolated from the first context container. It can also independently carry out the computation and execution of one or more kernel functions. In other words, if different independent context containers interact or collaborate on computations due to the data input / output flow of the kernel functions they carry, then a relationship can be established between these context containers.

[0091] Furthermore, the relationships between context containers can be recorded in the association information for later use. That is, the association information is standardized data information used to record and represent the relationships between different context containers, which can serve as an important basis for processing stages such as kernel function dependency resolution, instruction sequence configuration, and kernel function readiness checks.

[0092] It should be noted that the association information in the first processing device may only reflect the association relationship between context containers. For example, it is sufficient to clarify the association relationship between the first context container carrying kernel function a and the second context container carrying kernel function b through the association information, without needing to go down to the specific context container. In other words, after determining the first target context container based on the target interrupt event, the second target context container that has an association with it can be locked based on the association information.

[0093] In summary, the data input / output flow logic of kernel functions can be used to quickly identify the relationships between context containers, thereby accurately locating context containers with data interaction and cooperation, and obtaining the corresponding relationship information. This provides important data support for cross-context dependency identification, interrupt trigger instruction configuration, etc., and helps to ensure the orderly progress of the overall instruction sequence generation process.

[0094] It should be noted that the dependency update instruction, as an instruction used to update the dependency relationship between kernel functions, can be used both when updating the dependency relationship between kernel functions within the same context container and when updating the dependency relationship between kernel functions across context containers. This disclosure does not limit this.

[0095] In some alternative embodiments, the first processing device is configured to: insert a dependency update instruction after the function execution instruction if it is determined that the output data corresponding to the function execution instruction is the input data of another kernel function.

[0096] Therefore, by observing the flow of input and output data between kernel functions, the dependencies between kernel functions can be identified quickly and accurately. This allows for the insertion of dependency update instructions at precise and appropriate locations, which not only improves instruction generation efficiency but also enhances the accuracy and rationality of the target instruction sequence.

[0097] In some optional embodiments, there may be mutual dependencies between two kernel functions, that is, the current kernel function depends on another kernel function, and the other kernel function also depends on the current kernel function. In this case, multiple corresponding instructions can be generated. By executing these instructions, the corresponding kernel functions can be used to perform various computational tasks, the dependencies between kernel functions can be accurately updated at the appropriate time, and interrupts can be triggered in a timely manner to perform readiness checks on the corresponding kernel functions across context containers.

[0098] In some optional embodiments, the kernel function includes a first kernel function and a second kernel function that are mutually dependent and respectively carried by different context containers; wherein, the first kernel function is used to obtain a first calculation result based on a first calculation, the second kernel function depends on the first calculation result and obtains a second calculation result through a second calculation, and the first kernel function depends on the second calculation result and obtains a third calculation result through a third calculation; the first processing device is used to: generate a first function execution instruction for executing the first calculation of the first kernel function, generate a second function execution instruction for executing the second calculation of the second kernel function, and generate a third function execution instruction for executing the third calculation of the first kernel function; insert a first dependency update instruction between the first function execution instruction and the second function execution instruction, and set a first interrupt trigger instruction after the first dependency update instruction, the first dependency update instruction being used to remove the second kernel function's dependency on the first calculation result; insert a second dependency update instruction between the second function execution instruction and the third function execution instruction, and set a second interrupt trigger instruction after the second dependency update instruction, the second dependency update instruction being used to remove the first kernel function's dependency on the second calculation result.

[0099] For example, kernel function A and kernel function B run in different context containers. Kernel function B can only be started after kernel function A has completed computation task 1 and obtained computation result 1. Kernel function B needs to use computation result 1 to execute computation task 2 and obtain computation result 2. Furthermore, kernel function A needs to use the computation result 2 of kernel function B to execute computation task 3 and obtain computation result 3. Accordingly, the target instruction sequence corresponding to this part of the processing may include:

[0100] kernel_A (Computation Task 1);

[0101] Dependency update instruction 1 (used to update the dependency of kernel function B on computation result 1);

[0102] First interrupt trigger instruction;

[0103] kernel_B (computation task 2);

[0104] Dependency update instruction 2 (used to update the dependency of kernel function A on calculation result 2);

[0105] Second interrupt trigger instruction;

[0106] kernel_A (Computation Task 3).

[0107] Therefore, kernel_A (computation task 1) instructs kernel function A to execute computation task 1 and obtain the corresponding computation result 1. During this process, since kernel function B has not yet removed its dependency, kernel function B is in a state of waiting to start.

[0108] When kernel function A obtains calculation result 1, the dependency relationship between kernel function B and calculation result 1 is updated using dependency update instruction 1, and a target interrupt event is reported to the first processing device based on the first interrupt trigger instruction. In response to the target interrupt event, the first processing device determines the context container corresponding to kernel function A as the first target context container, and determines the context container corresponding to kernel function B as the second target context container based on the association relationship, and performs a readiness check on all kernel functions within it. Since kernel function B has already de-depended, it is determined that kernel function B is ready. The first processing device sends a processing instruction to start kernel function B to the second processing device. In response to receiving the processing instruction, the second processing device starts kernel function B and executes kernel_B (computation task 2), obtaining calculation result 2.

[0109] Similarly, the dependency update instruction 2 updates the dependency relationship between kernel function A and computation result 2, and triggers a target interrupt event to be reported to the first processing device based on the second interrupt trigger instruction. In response to the target interrupt event, the first processing device determines the context container corresponding to kernel function B as the first target context container, and determines the context container corresponding to kernel function A as the second target context container based on the association relationship, performing a readiness check on all kernel functions within it. Since kernel function A has been de-depended on, the second processing device can continue executing kernel_A (computation task 3) to obtain computation result 3.

[0110] In this scenario, the first processing device recognizes that kernel function A has been started. Therefore, even after completing the readiness check, it does not need to send processing instructions to the second processing device. After reporting the target interrupt event, the second processing device can obtain the updated dependency information of kernel function A through polling or periodic querying, and then schedule kernel function A to execute computation task 3. This approach reduces the number of interactions between the first and second processing devices, thus reducing resource overhead.

[0111] Therefore, for scenarios where a first kernel function and a second kernel function belonging to different context containers have a bidirectional dependency, the first processing device can be used to generate the corresponding instructions. Specifically, based on the computational logic between the two bidirectionally dependent kernel functions, corresponding function execution instructions can be generated sequentially. Furthermore, according to the dependency relationship between the kernel functions, corresponding dependency update instructions are inserted between different function execution instructions to update the dependency relationship in a timely manner, avoiding problems such as computational freezes caused by bidirectional dependencies and ensuring smooth task execution. Moreover, since cross-context container dependency updates are involved, interrupt trigger instructions can also be inserted after the corresponding dependency update instructions. This allows for the step-by-step removal of the bidirectional dependency constraints between the second kernel function and the first kernel function and the second computation result, and timely triggering of readiness checks for the corresponding kernel functions, effectively balancing data processing efficiency and computational stability.

[0112] In some optional embodiments, after executing the interrupt trigger instruction, the second processing device may report the target interrupt event to the first processing device. Furthermore, to enable the first processing device to quickly and accurately identify the kernel function to be checked for readiness, the second processing device may also provide an interrupt identifier to the first processing device.

[0113] In some optional embodiments, the first processing device is configured to: upon obtaining an interrupt identifier from the second processing device, determine a first target context container based on the interrupt identifier, wherein the interrupt identifier corresponds to a target interrupt event and includes at least one of a flow identifier, a kernel function identifier, and a container identifier; wherein the flow identifier is used to identify an execution flow, the execution flow belongs to any context container, and is used to execute one or more kernel functions carried by the context container.

[0114] In some alternative embodiments, multiple execution flows can run within a context container, and any execution flow can execute one or more kernel functions carried by the context container. Based on this, when the second processing device passes an interrupt identifier to the first processing device, it has multiple options, such as transmitting a flow identifier, a kernel function identifier, or a container identifier, or multiple of them. This disclosure does not limit this.

[0115] For the first processing device, different methods can be used to lock the first target context container for different types of interrupt flags, which is more flexible. Moreover, if different types of interrupt flags are obtained, the first processing device can determine the corresponding first target context container and judge whether these first target context containers are the same, which is equivalent to achieving a verification effect. In addition, since it supports obtaining multiple types of interrupt flags, even if one type of interrupt flag is not successfully obtained, the first target context container can be locked by obtaining other types of interrupt flags, which improves the success rate.

[0116] In some optional embodiments, the first processing device is further configured to: read an interrupt identifier from a target register of the second processing device upon receiving a target interrupt event.

[0117] Therefore, it can be seen that while reporting the target interrupt event, the second processing device can also write an interrupt flag to the target register, so that the first processing device can obtain the interrupt flag by reading the target register signal after receiving the target interrupt event.

[0118] In some optional embodiments, the first processing device is configured to perform at least one of the following steps: if the interrupt identifier includes a flow identifier, determine a target execution flow corresponding to the target interrupt event based on the flow identifier, and determine the context container in which the target execution flow is located as a first target context container; if the interrupt identifier includes a kernel function identifier, determine a first target kernel function based on the kernel function identifier, determine a target execution flow for executing the first target kernel function, and determine the context container to which the target execution flow belongs as the first target context container; if the interrupt identifier includes a container identifier, determine the context container corresponding to the container identifier as the first target context container.

[0119] Among them, the kernel function identifier is used to uniquely identify the kernel function, the stream identifier is used to uniquely identify the execution flow, and the container identifier is used to uniquely identify the context container.

[0120] Therefore, for different types of interrupt identifiers, the first processing device can use corresponding methods to lock the first target context container. Specifically, if the interrupt identifier is a container identifier, the corresponding context container can be directly located based on the container identifier and used as the first target context container; if the interrupt identifier is a flow identifier, considering that the execution flow belongs to a certain context container, the target execution flow can be determined first based on the flow identifier, and the context container where the target execution flow resides can be determined as the first target context container; if the interrupt identifier is a kernel function identifier, considering that the kernel function runs in a certain execution flow, and the execution flow belongs to a certain context container, the corresponding first target kernel function can be determined first based on the kernel function identifier, the target execution flow executing the first target kernel function can be determined, and the context container to which the target execution flow belongs can be determined, and that context container can be determined as the first target context container.

[0121] In summary, regardless of the type of interrupt identifier obtained, the first target context container can be accurately located, providing an important foundation for subsequently determining the associated second target context container.

[0122] Correspondingly, for the second processing device, after reporting the target interrupt event, it can also locate the first target context container based on the interrupt identifier, and obtain the dependency information of the kernel functions in the first target context container by means of polling, periodic querying, etc., and determine which kernel functions have been released from their dependencies and can continue to be scheduled, and which kernel functions need to be suspended, so as to perform the recovery, suspension and other processing of these kernel functions locally.

[0123] In some alternative implementations, after determining the first target context container, the first processing device may also search for context containers that are associated with the first target context container based on the association information, and use these context containers as the second target context containers.

[0124] It should be noted that, due to the dependency relationship between the kernel functions in the first target context container and the kernel functions in the second target context container, after an interruption is triggered by a dependency update in the kernel function of the first target context container, there is a relatively high probability that a kernel function in the associated second target context container will be ready due to this dependency update. Therefore, in addition to performing readiness checks on the kernel functions in the first target context container, readiness checks are also performed on the kernel functions in the second target context container. Based on this, the scope of checking potentially ready kernel functions is effectively expanded, which helps to improve the detection rate of ready kernel functions. Furthermore, because ready kernel functions can be discovered more comprehensively and promptly, they can be started in a timely manner, thereby improving the overall execution efficiency of the task.

[0125] It should also be noted that the relevant technologies do not involve performing readiness checks on kernel functions across context containers, but only within the same context container. Therefore, it is impossible to identify or perceive that the dependencies between kernel functions have been resolved across context containers, which can easily lead to the problem that kernel functions that are already ready cannot be detected in time and thus cannot be started in time, which will have a certain impact on task processing efficiency.

[0126] In some optional embodiments, the dependencies between kernel functions can be characterized based on dependency values; the first processing device is configured to: obtain the dependency value of each kernel function carried by a first target context container and the dependency value of each kernel function carried by a second target context container; and determine the readiness check result of the corresponding kernel function based on the obtained dependency values.

[0127] For example, if the dependency value indicates that the kernel function has resolved all dependencies, then a readiness check result indicating that the kernel function is ready is obtained; if the dependency value indicates that the kernel function still has at least one unresolved dependency, then a readiness check result indicating that the kernel function is not ready is obtained.

[0128] It should be noted that by quantifying the dynamic and complex dependencies between kernel functions into dependency values, the dependencies between kernel functions can be updated accurately and conveniently through dependency update instructions, ensuring the orderly operation of various data processing tasks. Furthermore, during ready checks, the ready check results can be obtained quickly and accurately through numerical judgment or comparison, resulting in high processing efficiency.

[0129] In some alternative implementations, the first processing device is configured to: send processing instructions to the second processing device to start the kernel function when the readiness check result indicates that the corresponding kernel function has removed all dependencies and the kernel function has not yet been started.

[0130] Therefore, in response to a target interrupt event, after detecting the existence of a ready but not yet started kernel function, the first processing device can send processing instruction information to the second processing device to start the kernel function, thereby promptly instructing the second processing device to start the kernel function to perform the corresponding data processing and improve the overall processing efficiency of the task.

[0131] For example, if the kernel function Kernel1 has N dependencies (N≥1), the dependency value of the kernel function Kernel1 can be used to indicate the number of dependencies of the kernel function Kernel1 that have not yet been resolved. Its value can be either the number of dependencies of Kernel1 that have not yet been resolved, N1, or the number of dependencies of Kernel1 that have been resolved, N2; where N1+N2=N.

[0132] Furthermore, the dependency value is not a fixed value, but may change as data processing progresses through the execution of dependency update instructions. The updating of the dependency value is primarily performed on the second processing device side; relevant details can be found in the description of the second processing device, and will not be elaborated upon here.

[0133] Therefore, it can be seen that dependency values ​​can be used to conveniently and intuitively manage and reflect the dependencies between kernel functions. Combined with the interrupt reporting mechanism, the first processing device can more accurately control the start time of the kernel function, so that the kernel function will only start execution after it is truly ready (i.e., all dependencies are released). In other words, when the kernel function starts, the data it needs is already in the final state, and the relevant data is already consistent and ready in memory and / or cache. Therefore, it is no longer necessary to configure complex listening rules, state tracking and retry logic for a large number of data addresses, which significantly reduces the configuration complexity and hardware overhead of the snooping filter and related consistency control registers.

[0134] In some optional implementations, the first processing device is further configured to: in response to receiving a fault interruption event reported by the second processing device, determine a third target context container carrying the second target kernel function based on the fault interruption event, wherein the fault interruption event is used to characterize a fault in the second target kernel function; determine a fourth target context container that is associated with the third target context container based on association information; determine a first dependent kernel function in the third target context container that is dependent on the second target kernel function, and a second dependent kernel function in the fourth target context container that is dependent on the second target kernel function; and send kernel function shutdown indication information to the second processing device, wherein the kernel function shutdown indication information is used to indicate the shutdown of the second target kernel function, the first dependent kernel function, and the second dependent kernel function.

[0135] Therefore, the second processing device can also report fault interruption events that characterize kernel function failures. For such events, the first processing device can first determine the faulty second target kernel function based on the fault interruption event, then determine the third target context container carrying the second target kernel function, and then, based on the association information, lock the fourth target context container that is associated with the third target context container. Next, it checks whether there is a first dependent kernel function in the third target context container that depends on the second target kernel function, and then checks whether there is a second dependent kernel function in the fourth target context container that depends on the second target kernel function. If there are first dependent kernel functions and / or second dependent kernel functions, a kernel function shutdown instruction message can be sent to the second processing device to instruct the second processing device to shut down the second target kernel function and all first and second dependent kernel functions.

[0136] This approach allows for the accurate identification of kernel functions that are dependent on the faulty kernel function. This enables the timely shutdown of the faulty kernel function and its dependent kernel functions, minimizing the impact of the fault and reducing erroneous execution results caused by the fault.

[0137] Secondly, embodiments of this disclosure provide a second processing device.

[0138] Figure 4 This is a block diagram of a second processing device 400 provided in an embodiment of the present disclosure. The second processing device 400 is used to cooperate with a first processing device to perform data processing tasks, which are completed based on multiple kernel functions.

[0139] The second processing device is used for:

[0140] The system receives a target instruction sequence sent by the first processing device. The target instruction sequence includes a function execution instruction for executing a kernel function, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel functions have released their dependencies.

[0141] During the execution of the target instruction sequence, in response to the execution of an interrupt trigger instruction, a target interrupt event is reported to the first processing device, and upon receiving processing instruction information sent by the first processing device, the kernel function indicated by the processing instruction information is started.

[0142] For example, when the second processing device receives a target instruction sequence sent by the first processing device, it can establish multiple context containers and schedule the instructions in the target instruction sequence to be executed in the multiple context containers.

[0143] Furthermore, a context container can run multiple execution streams to achieve parallel execution. Multiple kernel functions hosted by this context container can be executed on different execution streams. Additionally, the execution stream in which each kernel function resides can be stored and marked in information such as the context control block and control stream to facilitate subsequent kernel function startup.

[0144] In the context container context0, the parent kernel function A is set to run in the execution stream stream_x. The pending_semaphore information for child kernel B is set to indicate the dependency of child kernel function B on parent kernel function A. Simultaneously, when child kernel function B is called, its calling form is modified, its dependency is updated using atomic operations, and a Nop.trigger instruction is added to trigger an interrupt, reporting the execution stream stream_x(id) information to the target register on the first processing device. Alternatively, the kernel function identifier of child kernel function B can be written to the aforementioned target register or another target register.

[0145] The firmware module in the first processing device, based on the interrupt reporting type, determines that the interrupt type triggered by the Nop.trigger instruction is a specific type used to start a kernel function. At this point, the firmware module can read the information from the target register, obtain stream_x(id), and then determine its context container as context0. Using the information in context0, it can further retrieve information about all kernel functions contained within context0. Based on this, for sub-kernel function B, it obtains its corresponding dependency information and checks whether its dependencies are completely resolved. When completely resolved, it triggers the execution of the relevant operations to start kernel function B by sending an instruction to the second processing device.

[0146] During the execution of the target instruction sequence, in response to the execution of a function execution instruction, the corresponding data processing is performed using the corresponding kernel function; in response to the execution of a dependency update instruction, the dependency relationship between the corresponding kernel functions is updated; in response to the execution of an interrupt trigger instruction, the target interrupt event is reported to the first processing device, and the processing instruction information sent by the first processing device is received. The processing instruction information indicates the ready kernel function, and the second processing device can start the indicated ready kernel function.

[0147] Therefore, the second processing device can execute the target instruction sequence in an orderly manner. During this process, if an interrupt trigger instruction is executed, the target interrupt event is reported to the first processing device, so that the first processing device performs a kernel function readiness check across the context container. After detecting a ready kernel function, the first processing device sends a processing instruction to the second processing device to start the ready kernel function. This not only enables the orderly execution of data processing of various kernel functions and accurate updating of dependencies between kernel functions, but also timely reporting of target interrupt events and timely starting of ready kernel functions according to the issued processing instruction, thereby improving the overall task processing efficiency.

[0148] In some alternative implementations, the second processing device includes multiple streaming multiprocessors, an interrupt controller, and a target register; the streaming multiprocessors are used to issue an interrupt indication to the interrupt controller and write an interrupt identifier to the target register when an interrupt trigger instruction is executed; the interrupt controller is used to send a target interrupt event to the first processing device according to the interrupt indication.

[0149] In some optional implementations, the interrupt identifier corresponds to the target interrupt event and includes at least one of a flow identifier, a kernel function identifier, and a container identifier; wherein, the flow identifier is used to identify the execution flow, the execution flow belongs to any context container, and is used to execute one or more kernel functions carried by the context container. For the first processing device, it can adopt different processing methods for different types of interrupt identifiers, and ultimately lock the first target context container and the second target context container. For relevant details, please refer to the description on the first processing device side, which will not be elaborated here.

[0150] In some alternative implementations, the processing instruction information includes an identifier of a ready kernel function; the second processing device is also used to start the kernel function corresponding to the identifier of the ready kernel function.

[0151] In some alternative implementations, the second processing device is further configured to: start the ready target subfunction based on the parent kernel function among the dependent kernel functions, provided that the ready target subfunction and all its dependent kernel functions are carried by the same context container.

[0152] Here, the dependent kernel function refers to the kernel function that the target subfunction depends on, including the parent kernel function of the target subfunction. In some cases, the target subfunction and all its dependent kernel functions can be held in the same context container. The ready state of the target subfunction can be determined by the second processing device or the first processing device.

[0153] For example, during the execution of the target instruction sequence, the second processing device can determine, based on the dependency relationship value, that all the dependent kernel functions on which the target sub-function depends have been executed. At this point, the target sub-function can be started based on the parent kernel function without the need for instruction from the first processing device.

[0154] Furthermore, as previously stated, the first processing device sends processing instruction information when it determines that the target sub-function is ready based on the target interrupt event. Upon receiving the processing instruction information sent by the first processing device, the second processing device can determine the parent kernel function of the ready kernel function based on the identifier of the ready kernel function (i.e., the identifier of the target sub-function) and the kernel function parent-child relationship information, and start the ready kernel function based on the parent kernel function.

[0155] For example, the processing instruction information includes the identifier kernel(A) of the ready kernel function, indicating that the ready kernel function is kernel function A. The second processing device queries the kernel function parent-child relationship information and finds that its parent kernel function is kernel function B. Therefore, kernel function A can be started through kernel function B. The kernel function parent-child relationship information is determined according to the data processing task.

[0156] In some optional implementations, the target instruction sequence includes function execution instructions for executing kernel functions, dependency update instructions for updating dependencies between kernel functions, and interrupt trigger instructions. The interrupt trigger instructions correspond to the dependency update instructions and are used to trigger cross-context container checks to see if kernel functions have released their dependencies.

[0157] This allows for the quantification of dynamic and complex dependencies between kernel functions into dependency values. These values ​​can then be updated using dependency update instructions based on atomic operations, thereby ensuring the accuracy and global consistency of the dependency values.

[0158] In some alternative embodiments, dependency values ​​can be represented based on dependency semaphores, which are essentially integer counters with wait logic that can be used to mark how many dependencies remain unresolved or how many dependencies have been resolved.

[0159] Furthermore, considering that the dependency value is a shared counter that is simultaneously contested and modified by multiple hardware units (such as firmware, streaming multiprocessor bus interfaces, etc.), only atomic operations can guarantee that the three steps of "reading, modifying, and writing" the dependency count are not fragmented or interrupted; otherwise, the count value will be incorrect, leading to kernel function dependency synchronization failure. Based on this, atomic operations can be used to accurately update the dependency value; in other words, dependency update instructions are essentially atomic operation instructions.

[0160] For example, the dependency update instruction Atomic_add(pending_semaphore,1) in the form of an atomic operation instruction can be used to perform an atomic increment operation on the dependency value pending_semaphore.

[0161] For example, an atomic decrement operation can be performed on the dependency value pending_semaphore using the dependency update instruction Atomic_sub(pending_semaphore,﹣1) in the form of an atomic operation instruction.

[0162] Therefore, when initializing the dependency value, it can be initialized to zero, and its value can be updated subsequently through an atomic increment operation. Alternatively, the dependency value can be initialized to N, where N represents the total number of dependencies, and its value can be updated subsequently through an atomic decrement operation. This disclosure does not limit this approach.

[0163] In some alternative implementations, the second processing device further includes a streaming multiprocessor and a global cache module; the streaming multiprocessor is used to send an atomic memory operation request to the global cache module when a dependency update instruction is executed; the global cache module is used to update the dependency value corresponding to the dependency update instruction based on the atomic operation when the atomic memory operation request is received.

[0164] In some optional implementations, the global cache module includes an L2 cache module. The L2 cache module is responsible for caching global memory data, maintaining cache consistency, and handling atomic operation requests. Global atomic operations are executed within the L2 cache module, ensuring the atomicity of the Streaming Multiprocessor (SM). In other words, if the second processing device identifies an atomic operation instruction during the execution of the target instruction sequence, it can pass it through the L1 cache module to the L2 cache module, where the L2 cache module executes the corresponding atomic operation.

[0165] In summary, the embodiments disclosed herein essentially modify the kernel function startup method, improving it from a normal startup method to a startup method that includes dependency judgment. For example, in related technologies, this can be achieved through `child_kernel_B<<`.<grid_size, block_size, sharedmem, streamid> >>(kernel_params) starts kernel function B, and in this embodiment of the disclosure, kernel function B can be started in the following manner:

[0166] device void kernel_A()

[0167] {

[0168] …

[0169] Atomic_add(pending_semephore.value, 1); / / Dependency update instruction, updates the dependency value to 1, indicating that a dependency has been removed.

[0170] Nop.trigger(); / / Interrupt trigger command

[0171] …

[0172] Return;

[0173] }

[0174] For example, kernel function A is the parent kernel function. When the warp block of kernel function A starts, the backbone instructions of kernel function A (such as several function execution instructions) are executed normally. After executing the dependency update instruction, the dependencies between kernel functions are updated. Further, when NOP.trigger is executed, the target interrupt event can be reported to the first processing device through the interrupt controller, and the input signal of the target register is configured to transmit the interrupt identifier. After reporting the target interrupt event, the first processing device performs a series of processes. After confirming that kernel function B has released all dependencies through a readiness check, it sends a processing instruction to start kernel function B to the second processing device. In response to this processing instruction, the second processing device starts kernel function B based on kernel function A.

[0175] The following is combined with Figure 5 and Figure 6 The embodiments of this disclosure will be further described.

[0176] Figure 5 This is a schematic diagram illustrating the interaction process between a first processing device and a second processing device, provided as an embodiment of this disclosure. (Refer to...) Figure 5 The first processing device includes a parsing module and a firmware (FW) module, while the second processing device includes a command control engine (CCE), a streaming multiprocessor, a target register, an interrupt controller (InterruptReQuest, IRQ), and an L2 cache module.

[0177] In the first processing device, the parsing module is used to generate a target instruction sequence based on the received data processing instructions and determine the associated information. The target instruction sequence can be further sent to the second processing device for execution. At the same time, the parsing module can also send the associated information to the firmware module so that after receiving the target interrupt event, the firmware module can perform processing such as determining the context container and checking the kernel function readiness.

[0178] In the second processing device, the command control engine receives the target instruction sequence and schedules it for execution in the corresponding streaming multiprocessor. The streaming multiprocessor can create multiple context containers for running kernel functions. Furthermore, when executing a dependency update instruction, the streaming multiprocessor sends an atomic memory operation request to the global cache module. Upon receiving the atomic memory operation request, the global cache module updates the dependency relationship value corresponding to the dependency update instruction based on the atomic operation.

[0179] The control flow operations for initiating kernel functions are scheduled and executed in the CCE. After the kernel function is started, it can assemble related warps and allocate corresponding resources, and then be scheduled into the MP for execution. The second processing device can be a GPU, which is a complex parallel processor with multiple MPs contained in one MP core cluster. The MP includes functions such as instruction fetching, decoding, issuing, executing, and writing back. Dependency update instructions and NOP.trigger are fetched from the MP and issued for execution. However, dependency update instructions update dependencies based on atomic operations, so their actual execution is in the L2 Cache module. When the NOP.trigger instruction is executed, the stream identifier (stream id) and / or kernel identifier (kernel id) can be written to the target register, and then an interrupt is reported to the FW module in the first processing device via IRQ. The FW model obtains the stream identifier (stream id) and / or kernel identifier (kernel id) by querying the target register and performs kernel function readiness checks and other processing.

[0180] Furthermore, when the streaming multiprocessor executes an interrupt trigger instruction, it writes the stream identifier of the corresponding execution stream into the target register and reports the target interrupt event to the first processing device through the interrupt controller.

[0181] After receiving the target interrupt event, the control module in the first processing device reads the stream identifier through the target register, determines the target execution flow corresponding to the target interrupt event based on the stream identifier, and determines the context container where the target execution flow is located as the first target context container. Based on the association information, it searches for the second target context container that is associated with the first target context container, and performs a readiness check on all kernel functions carried by the first and second target context containers. If a ready kernel function exists, it sends processing instruction information to the second processing device to indicate the start of the ready kernel function.

[0182] The second processing device starts the ready kernel function according to the received processing instruction information, and uses the kernel function to perform the corresponding data processing. This process continues until the target instruction sequence is completed and the task processing result corresponding to the data processing task is obtained.

[0183] Therefore, the first processing device can establish dependencies between parent and child kernel functions and between child and parent kernel functions based on information representing dependencies between kernel functions, such as parent kernel launch child kernel in the application (i.e., data processing task), and generate corresponding target instruction sequences. In these target instruction sequences, dependency update instructions that use atomic operations to resolve kernel function dependencies are inserted. By triggering interrupt reporting interrupt identifiers (such as stream id) through the NOP.trigger instruction, the firmware module in the first processing device can retrieve whether the corresponding kernel function has released all dependencies. If it has, the corresponding ready child kernel function can be launched by the command control engine based on the sending of instructions.

[0184] Figure 6 This is a schematic diagram illustrating the execution process of a kernel function provided in an embodiment of this disclosure. (Refer to...) Figure 6 Kernel function A and kernel function B run on execution flows of different context containers. The corresponding processing steps are as follows: Kernel function A can only start after it has completed computation task 1 and obtained computation result 1. Kernel function B executes computation task 2 based on computation result 1 and obtains computation result 2. Furthermore, kernel function A can use the computation result 2 of kernel function B to execute computation task 3 and obtain computation result 3.

[0185] like Figure 6 As shown, the second processing device executes each instruction sequentially. After executing the function execution instruction that performs computation task 1 based on kernel function A and obtains computation result 1, it executes the dependency update instruction Atomic_add(pending_semaphore_A,1), indicating that the dependency relationship between kernel function B and computation result 1 has been removed. Based on this, the first processing device is triggered by the interrupt trigger instruction NOP.trigger() to report the target interrupt event to the first processing device. The processing procedure of the first processing device can be found in relevant content and will not be described further here. Furthermore, since kernel function B is ready, the first processing device, after performing a readiness check, sends a processing instruction message to the second processing device to start kernel function B. Upon receiving the processing instruction message, the second processing device starts kernel function B.

[0186] Furthermore, after starting kernel function B, several initialization operations need to be performed, such as: `self_pending_semaphore_B = sema_poll.allocate()`, which indicates that the parent kernel function A has requested an unused semaphore from the hardware semaphore pool (sema_poll) as a dedicated free semaphore for the child kernel function B. This semaphore belongs to the child kernel function B and is used to manage its own execution state; `kernel_B.self_pending_sema = self_pending_semaphore_B`, which writes the allocated semaphore into the context control block of kernel function B, and kernel function B can modify this semaphore after execution to report its own execution state to the parent kernel function; `kernel_B.parent_pending_sema = self_pending_semaphore_A`, which writes the parent dependent semaphore into the context control block of kernel function B.

[0187] Furthermore, kernel function B can execute computation task 2, and after obtaining computation result 2, it can update self_pending_semaphore_B, thereby updating the dependency relationship between kernel function A and the computation result 2 of kernel function B. This allows kernel function A to continue executing computation task 3 based on computation result 2, and obtain computation result 3.

[0188] like Figure 6 As shown, the execution flow can also be bound to barriers, which serve as hardware completion markers. These barriers can be used to mark task completion points and trigger updates to dependency values. For example, when kernel function B completes computation task 2, the hardware triggers a barrier, indicating that computation task 2 has truly been completed. The hardware can then automatically execute operations such as `Atomic_sub(pending_semaphore_B, -1)` to update `self_pending_semaphore_B`, thereby triggering a series of data processing steps, including reporting the target interrupt event.

[0189] Furthermore, kernel function A can also instruct kernel function A to wait using (self_pending_semaphore_A==0), and can also exit using the swap (XCHG) instruction (self_pending_semaphore_A, -1). Similarly, kernel function B can also wait using (self_pending_semaphore_B==0), and can restore parent semaphore A to its initial state using the subtraction (SUB) instruction (self_pending_semaphore_A, -1), and can also exit using the swap (XCHG) instruction (self_pending_semaphore_B, -1).

[0190] Thirdly, embodiments of this disclosure provide a processing method that can be applied to a first processing device.

[0191] Figure 7 This is a flowchart illustrating a processing method provided in an embodiment of the present disclosure. This method can be applied to a first processing device, which is used to collaboratively execute data processing tasks with a second processing device. The data processing tasks are completed based on multiple kernel functions. (Refer to...) Figure 7 The processing method may include the following steps:

[0192] Step S71: Generate the target instruction sequence for the data processing task, determine the association information between the context containers used to carry the kernel function, and send the target instruction sequence to the second processing device for execution;

[0193] The target instruction sequence includes function execution instructions for executing kernel functions, dependency update instructions for updating dependencies between kernel functions, and interrupt trigger instructions. The interrupt trigger instructions correspond to the dependency update instructions and are used to trigger cross-context container checks to see if kernel functions have released their dependencies.

[0194] Step S72: In response to receiving a target interruption event reported by the second processing device, determine the first target context container based on the target interruption event, and determine the second target context container that is associated with the first target context container based on the association information;

[0195] Step S73: Perform a readiness check on the kernel functions carried by the first target context container and the second target context container, and if it is determined that there are ready kernel functions, send processing instruction information to the second processing device.

[0196] The processing instruction information is used to instruct the kernel function of the second processing device to be ready to start.

[0197] Furthermore, the specific details of this processing method can be found in the relevant description of the first processing device, and will not be elaborated upon here.

[0198] Therefore, in this embodiment, on the one hand, a target instruction sequence is determined based on the data processing task so that the second processing device can execute the data processing task accurately and orderly. In this process, the dependency update instruction is used to explicitly update the dependency relationship between kernel functions, reducing the number and complexity of listening to atomic operations by the hardware, which can effectively reduce hardware overhead. On the other hand, the association information between context containers is also determined based on the data processing task. After the second processing device reports the target interrupt event to the first processing device through the interrupt trigger instruction, it can check whether the kernel functions have released their dependencies across context containers. This allows for timely readiness checks of kernel functions in the first target context container and also timely readiness checks of kernel functions in the second target context container that are associated with the first target context container. This effectively expands the scope of readiness checks, enabling more timely and comprehensive discovery of ready kernel functions, thereby activating these ready kernel functions in a timely manner and improving task processing efficiency.

[0199] Fourthly, embodiments of this disclosure provide a processing method that can be applied to a second processing device.

[0200] Figure 8 A flowchart illustrating another processing method provided in this embodiment of the present disclosure is shown. This processing method can be applied to a second processing device, which is used to collaboratively execute data processing tasks with a first processing device. The data processing tasks are completed based on multiple kernel functions. (Refer to...) Figure 8 The processing method may include the following steps:

[0201] Step S81: Receive the target instruction sequence sent by the first processing device. The target instruction sequence includes a function execution instruction for executing a kernel function, a dependency update instruction for updating the dependency relationship between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel function has released its dependency relationship.

[0202] Step S82: During the execution of the target instruction sequence, in response to the execution of the interrupt trigger instruction, a target interrupt event is reported to the first processing device, and upon receiving the processing instruction information sent by the first processing device, the kernel function indicated by the processing instruction information is started.

[0203] Furthermore, the specific details of this processing method can be found in the relevant description of the second processing device, and will not be elaborated here.

[0204] Therefore, in this embodiment, the second processing device can execute the target instruction sequence in an orderly manner. During this process, if an interrupt trigger instruction is executed, a target interrupt event is reported to the first processing device so that the first processing device performs a kernel function readiness check across the context container. After detecting a ready kernel function, the first processing device sends a processing instruction information to the second processing device to start the ready kernel function. This not only enables the orderly execution of data processing of various kernel functions and accurate updating of dependencies between kernel functions, but also timely reporting of target interrupt events and timely starting of ready kernel functions according to the issued processing instruction information, thereby improving the overall task processing efficiency.

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

[0206] In addition, this disclosure also provides a processing system that can be used to implement any of the processing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the relevant section on methods and will not be repeated here.

[0207] Fifthly, embodiments of this disclosure provide a processing system.

[0208] Figure 9 This is a block diagram of a processing system provided in an embodiment of the present disclosure.

[0209] Reference Figure 8 This disclosure provides a processing system 900, which includes a first processing device 910 and a second processing device 920.

[0210] The first processing device 910 adopts the first processing device described in any one of the embodiments of this disclosure, and the second processing device 920 adopts the second processing device described in any one of the embodiments of this disclosure. The corresponding processing process is described in the relevant description and will not be elaborated here.

[0211] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0212] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

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

[0214] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A first processing device, characterized in that, The first processing device is configured to cooperate with a second processing device to perform data processing tasks, the data processing tasks being completed based on multiple kernel functions; the first processing device is configured to: A target instruction sequence for the data processing task is generated, the association information between the context containers used to carry the kernel function is determined, and the target instruction sequence is sent to the second processing device for execution. The target instruction sequence includes a function execution instruction for executing the kernel function, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel function has released its dependencies in order to perform a kernel function readiness check. In response to receiving a target interruption event reported by the second processing device, a first target context container is determined based on the target interruption event, and a second target context container that is associated with the first target context container is determined based on the association information; A readiness check is performed on the kernel functions carried by the first target context container and the second target context container. If a ready kernel function is determined to exist, a processing instruction message is sent to the second processing device. The processing instruction message is used to instruct the second processing device to start the ready kernel function.

2. The device according to claim 1, characterized in that, The first processing device is used for: The data processing task is analyzed to obtain multiple kernel functions, the dependencies between kernel functions, and related information. Based on the multiple kernel functions, determine the multiple function execution instructions; Based on the dependencies between the kernel functions, at least one dependency update instruction is inserted into the multiple function execution instructions; as well as, Based on the association information, the interrupt trigger instruction is set after the dependency update instruction corresponding to the cross-context dependency relationship to obtain the target instruction sequence. The cross-context dependency relationship is used to characterize the dependency relationship between the corresponding kernel functions, and the corresponding kernel functions are respectively carried by different context containers.

3. The device according to claim 2, characterized in that, The kernel function includes a first kernel function and a second kernel function that are interdependent and carried by different context containers; wherein, the first kernel function is used to obtain a first calculation result based on a first calculation, the second kernel function depends on the first calculation result and obtains a second calculation result through a second calculation, and the first kernel function depends on the second calculation result and obtains a third calculation result through a third calculation; The first processing device is used for: Generate a first function execution instruction for performing a first computation of the first kernel function, generate a second function execution instruction for performing a second computation of the second kernel function, and generate a third function execution instruction for performing a third computation of the first kernel function; A first dependency update instruction is inserted between the first function execution instruction and the second function execution instruction, and a first interrupt trigger instruction is set after the first dependency update instruction. The first dependency update instruction is used to remove the second kernel function's dependency on the first calculation result. A second dependency update instruction is inserted between the second function execution instruction and the third function execution instruction, and a second interrupt trigger instruction is set after the second dependency update instruction. The second dependency update instruction is used to remove the first kernel function's dependency on the second calculation result.

4. The device according to claim 2, characterized in that, The context container includes a first context container and a second context container; the first processing device is configured to: If the output data of the kernel function in the first context container is determined to be the input data of the kernel function in the second context container, an association relationship is determined between the first context container and the second context container, and corresponding association information is generated.

5. The device according to claim 2, characterized in that, The first processing device is used for: If it is determined that the output data corresponding to the function execution instruction is the input data of other kernel functions, the dependency update instruction is inserted after the function execution instruction.

6. The device according to claim 1, characterized in that, The dependencies between the kernel functions are represented based on dependency value representations; the first processing device is used for: Obtain the dependency values ​​of each kernel function carried by the first target context container and the dependency values ​​of each kernel function carried by the second target context container; The readiness check result of the corresponding kernel function is determined based on the obtained dependency values.

7. The device according to claim 1, characterized in that, The first processing device is used for: If an interrupt identifier is obtained from the second processing device, the first target context container is determined based on the interrupt identifier, wherein the interrupt identifier corresponds to the target interrupt event and includes at least one of a stream identifier, a kernel function identifier, and a container identifier; The stream identifier is used to identify the execution stream, which belongs to any of the context containers and is used to execute one or more kernel functions carried by the context container.

8. The device according to claim 7, characterized in that, The first processing device is configured to perform at least one of the following steps: If the interrupt identifier includes the flow identifier, the target execution flow corresponding to the target interrupt event is determined according to the flow identifier, and the context container in which the target execution flow is located is determined to be the first target context container; If the interrupt identifier includes the kernel function identifier, a first target kernel function is determined based on the kernel function identifier, a target execution flow for executing the first target kernel function is determined, and the context container to which the target execution flow belongs is determined as the first target context container; If the interrupt identifier includes the container identifier, the context container corresponding to the container identifier is determined as the first target context container.

9. The device according to claim 7, characterized in that, The first processing device is further configured to: Upon receiving the target interrupt event, the interrupt identifier is read from the target register of the second processing device.

10. The device according to any one of claims 1-9, characterized in that, The first processing device is used for: If the readiness check result indicates that the corresponding kernel function has removed all dependencies and the kernel function has not yet been started, a processing instruction message for starting the kernel function is sent to the second processing device.

11. The device according to any one of claims 1-9, characterized in that, The first processing device is further configured to: In response to receiving a fault interruption event reported by the second processing device, a third target context container carrying the second target kernel function is determined based on the fault interruption event, wherein the fault interruption event is used to characterize a fault in the second target kernel function; Based on the association information, a fourth target context container that is associated with the third target context container is determined; Identify the first dependent kernel function in the third target context container that has a dependency relationship with the second target kernel function, and the second dependent kernel function in the fourth target context container that has a dependency relationship with the second target kernel function; Send a kernel function shutdown instruction to the second processing device. The kernel function shutdown instruction is used to instruct the shutdown of the second target kernel function, the first dependent kernel function, and the second dependent kernel function.

12. A second processing apparatus, characterized in that, The second processing device is used to coordinate with the first processing device to perform data processing tasks, the data processing tasks being completed based on multiple kernel functions; the second processing device is used for: The system receives a target instruction sequence sent by the first processing device. The target instruction sequence includes a function execution instruction for executing a kernel function, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel functions have released their dependencies. During the execution of the target instruction sequence, in response to the execution of the interrupt trigger instruction, a target interrupt event is reported to the first processing device, and upon receiving processing instruction information sent by the first processing device, the kernel function indicated by the processing instruction information is started.

13. The device according to claim 12, characterized in that, The second processing device includes multiple streaming multiprocessors, an interrupt controller, and a target register; The streaming multiprocessor is configured to, upon execution of the interrupt trigger instruction, issue an interrupt indication to the interrupt controller and write an interrupt identifier to the target register; The interrupt controller is configured to send the target interrupt event to the first processing device according to the interrupt indication.

14. The device according to claim 12, characterized in that, The processing instruction information includes the identifier of the ready kernel function; The second processing device is used to: start the kernel function corresponding to the identifier of the ready kernel function.

15. The device according to claim 12, characterized in that, The second processing device is further configured to: when it is determined that the ready target sub-function and all its dependent kernel functions are carried by the same context container, start the ready target sub-function based on the parent kernel function in the dependent kernel functions.

16. The device according to claim 12, characterized in that, The second processing device also includes a streaming multiprocessor and a global cache module; The streaming multiprocessor is used to send an atomic memory operation request to the global cache module when the dependent update instruction is executed. The global cache module is used to update the dependency value corresponding to the dependency update instruction based on the atomic operation when the atomic memory operation request is received.

17. A processing method, characterized in that, The method is applied to a first processing device, which is used to collaboratively execute a data processing task with a second processing device, the data processing task being completed based on multiple kernel functions; the method includes: A target instruction sequence for the data processing task is generated, the association information between the context containers used to carry the kernel function is determined, and the target instruction sequence is sent to the second processing device for execution. The target instruction sequence includes a function execution instruction for executing the kernel function, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel function has released its dependencies in order to perform a kernel function readiness check. In response to receiving a target interruption event reported by the second processing device, a first target context container is determined based on the target interruption event, and a second target context container that is associated with the first target context container is determined based on the association information; A readiness check is performed on the kernel functions carried by the first target context container and the second target context container. If a ready kernel function is determined to exist, a processing instruction message is sent to the second processing device. The processing instruction message is used to instruct the second processing device to start the ready kernel function.

18. A processing method, characterized in that, The method is applied to a second processing device, which is used to collaboratively execute data processing tasks with a first processing device, the data processing tasks being completed based on multiple kernel functions; the method includes: The system receives a target instruction sequence sent by the first processing device. The target instruction sequence includes a function execution instruction for executing a kernel function, a dependency update instruction for updating the dependencies between kernel functions, and an interrupt trigger instruction. The interrupt trigger instruction corresponds to the dependency update instruction and is used to trigger a cross-context container check to see if the kernel functions have released their dependencies. During the execution of the target instruction sequence, in response to the execution of the interrupt trigger instruction, a target interrupt event is reported to the first processing device, and upon receiving processing instruction information sent by the first processing device, the kernel function indicated by the processing instruction information is started.

19. A processing system, characterized in that, It includes a first processing device and a second processing device; The first processing device is the first processing device as described in any one of claims 1-11; The second processing device is the second processing device as described in any one of claims 12-16.

Images