Preemption management method, apparatus, device, storage medium, and program product

Abstract

The application provides a preemption management method, device, equipment, storage medium and program product. The preemption management device is located in a graphics processor, and the method comprises the following steps: receiving a calculation task; storing task information of the calculation task in the preemption management device; updating the task information based on the execution condition of the calculation task during the execution of the calculation task; resuming the execution of the calculation task based on the updated task information in the case that the execution condition comprises being preempted by another calculation task and the other calculation task is executed; and the execution priority of the other calculation task is higher than that of the calculation task. In the preemption management method, the task information of the calculation task is stored in the preemption management device, and the task information is updated during the execution of the calculation task to obtain the latest calculation task to be executed. After the calculation task is preempted, the calculation task can be resumed based on the stored task information, and the efficiency of resuming the execution of the calculation task after preemption is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to a preemption management method, apparatus, device, storage medium, and program product. Background Technology

[0002] In recent years, graphics processing units (GPUs) have supported instruction-level preemption. This feature means that if a higher-priority task arises while the GPU is executing a task, the currently executing lower-priority task needs to be completely offloaded from the GPU, and the higher-priority task can be processed only after the GPU returns to an idle state. However, offloading the task data of the lower-priority task to off-chip means that the task data needs to be loaded from off-chip during the resumption of execution of the lower-priority task, which affects the efficiency of resuming execution of the lower-priority task after preemption. Summary of the Invention

[0003] In view of this, embodiments of this application provide at least one preemption management method, apparatus, device, storage medium, and program product.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] On one hand, this application provides a preemption management method applied to a preemption management device located within a graphics processor. The preemption management method includes: receiving a computing task issued by a front-end module; storing task information of the computing task in the preemption management device; updating the task information based on the execution status of the computing task during the execution of the computing task to obtain updated task information; and resuming the execution of the computing task based on the updated task information when the execution status includes being preempted by other computing tasks and the other computing tasks have completed their execution; wherein the execution priority of the other computing tasks is higher than that of the computing task.

[0006] On the other hand, embodiments of this application provide a preemption management device, which includes a receiving unit, a storage unit, an updating unit, and an execution unit. The receiving unit is used to receive computing tasks issued by a front-end module; the storage unit is used to store task information of the computing tasks in the preemption management device; the updating unit is used to update the task information based on the execution status of the computing tasks during execution of the computing tasks, obtaining updated task information; the execution unit is used to resume execution of the computing tasks based on the updated task information when the execution status includes being preempted by other computing tasks and the other computing tasks have completed execution; the execution priority of the other computing tasks is higher than that of the computing tasks.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the steps in the aforementioned preemption management method.

[0008] In another aspect, embodiments of this application provide a storage medium on which a computer program is stored, which, when executed by a processor, implements the steps in the aforementioned preemption management method.

[0009] In another aspect, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in the aforementioned preemption management method.

[0010] In this embodiment, the received computing task information is stored in the preemption management device to back up the computing task. The backed-up computing task is updated during the execution of the computing task to obtain the latest computing task to be executed. Compared with the related technology, which requires loading the task data from outside the chip into the graphics processor first and then obtaining the sub-task from outside the chip based on the task data to resume the execution of the computing task, this application can directly obtain the sub-task from outside the chip based on the updated task information stored in the graphics processor when resuming the execution of the computing task, thereby improving the efficiency of resuming the execution of the computing task after instruction-level preemption.

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

[0012] Figure 1 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 1 ;

[0013] Figure 2 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 2 ;

[0014] Figure 3 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 3 ;

[0015] Figure 4 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 4 ;

[0016] Figure 5 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 5 ;

[0017] Figure 6 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 6 ;

[0018] Figure 7 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 7 ;

[0019] Figure 8 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 8 ;

[0020] Figure 9 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 9 ;

[0021] Figure 10 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 10 ;

[0022] Figure 11 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 10 one;

[0023] Figure 12 This application provides a schematic diagram of the composition structure of a preemption management device.

[0024] Figure 13 This is a schematic diagram of the preemption management device provided in an embodiment of this application;

[0025] Figure 14 A flowchart illustrating the preemption management method provided in an embodiment of this application;

[0026] Figure 15 for Figure 14 A partial diagram of the linked list in the preemption management method;

[0027] Figure 16 for Figure 14 A flowchart illustrating step S1404 in the preemptive management method;

[0028] Figure 17 for Figure 14 A flowchart illustrating step S1408 in the preemptive management method;

[0029] Figure 18 for Figure 14 A flowchart illustrating step S1409 in the preemptive management method;

[0030] Figure 19 for Figure 14The diagram illustrates an exemplary representation of the computational task within a stream processor in the preemption management method.

[0031] Figure 20 This refers to the storage status of the task sequence in the preemption management module 1330.

[0032] Figure 21 This refers to the storage state of the task sequence after it has been updated in the preemption management module 1330.

[0033] Figure 22 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

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

[0036] In recent years, Graphics Processing Units (GPUs) have supported instruction-level execution preemption. This feature is used when the GPU is executing a task, and the software receives a higher-priority task from the user, requiring the GPU to perform computation on that task as quickly as possible. However, loading a higher-priority task directly without unloading the currently running task can lead to increased execution time for the higher-priority task or GPU lockup. These problems arise because: 1) the GPU's hardware capacity is insufficient to handle two large-scale computational tasks simultaneously; 2) the synchronization and / or isolation mechanisms for running two tasks concurrently are not properly handled; 3) mutual exclusion occurs between resources of different tasks; and 4) random errors in hardware operation occur in complex scenarios due to simultaneous multitasking.

[0037] Therefore, it is necessary to first unload the currently executing task from the GPU, and then let the obtained idle thread execute the higher priority task. In other words, at the time when the software begins to unload, the GPU's Streaming Multiprocessor (SM) is executing the instructions of the task thread, hence it is also called instruction-level preemption. This type of preemption is currently the finest-grained preemption in the industry and can solve problems that higher-grained preemption cannot solve.

[0038] During the GPU unloading of the current task, the computing unit stops issuing subsequent instructions to the threads corresponding to low-priority tasks. The preceding task management module saves the context of each thread outside the graphics processor. After a thread finishes executing its current instruction, an idle thread is obtained to execute higher-priority tasks. When a higher-priority task finishes processing and is resumed, the task management module directly restores the context within the graphics processor to resume the execution of the low-priority task.

[0039] In some use cases, hardware may not support preemptive nesting. Preemptive nesting can include: the 0th control flow (context0) being preempted by the 1st control flow (context1), and when context1 is executed, it is preempted by the 2nd control flow (context2) with higher priority.

[0040] However, offloading all task data for low-priority tasks to off-chip means that during the process of resuming execution of the low-priority task, the task data needs to be loaded from off-chip, which affects the efficiency of resuming execution of low-priority tasks after preemption.

[0041] Therefore, how to improve the efficiency of resuming the execution of low-priority tasks after preemption has become an urgent problem to be solved.

[0042] In view of the above problems, this application provides a preemption management method. By storing the task information of the computing task issued to the preemption management device in the preemption management device, and updating the stored task information according to the execution status of the computing task during the execution of the computing task, the real-time execution status of the computing task is obtained. This allows the preemption status of the computing task to be obtained based on the task information stored in the preemption management device when the computing task is preempted, so as to continue executing the remaining part of the computing task.

[0043] In other words, it provides a method for handling instruction-level execution preemption at the task management module level, supporting the function of instruction-level execution preemption with minimal hardware overhead and architectural changes. It implements the functionality of this level module in instruction-level execution preemption, and reduces the time required for preemption and restore flow in the implementation process of this module, while having good compatibility with the original microarchitecture.

[0044] Figure 1 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, the preemption management method is applied to a preemption management device located within a graphics processor. The preemption management method includes at least steps S101 to S104.

[0045] Step S101: Receive the computing task issued by the front-end module.

[0046] The front-end module is used to allocate and distribute computing tasks, as well as to receive the results of computing tasks.

[0047] In some embodiments, the front-end module dispatches computing tasks based on the running status of the thread used to execute the computing task. It should be noted that if a computing task is interrupted by other computing tasks before it is completely dispatched, the front-end module will resume dispatching the computing task until it is completely dispatched when the execution of the computing task is resumed.

[0048] For example, a computing task includes subtasks 1 to 5, and the thread used to execute the computing task includes thread 1. Then, after the front-end module issues the first subtask, assigns it to thread 1 and starts executing it, the front-end module issues the second subtask, assigns it to thread 1 and waits to execute it, until the fifth subtask is assigned to thread 1 and waits to execute it, at which point the computing task is completed.

[0049] Step S102: Store the task information of the computing task in the preemption management device.

[0050] Here, based on the task information of the computation task, the computation task can be executed and the computation result obtained. The task information of the computation task may include, but is not limited to, subtask sequence information, execution location information, etc.

[0051] The execution of the computation task includes processing the data to be processed through instruction code segments to obtain the data processing results. The storage information of the instruction code segments and the storage information of the data to be processed are stored in the preemption management device. In this way, if it is necessary to resume the execution of the computation task, the instruction code segments can be retrieved based on the storage information of the instruction code segments, and the data to be processed can be retrieved based on the storage information of the data to be processed, thereby resuming the execution of the computation task. At this time, the task information includes the storage information of the instruction code segments and the storage information of the data to be processed.

[0052] In some embodiments, a computing task includes multiple subtasks. The preemption management device stores the task information of the computing task in the following manner: a task identifier is configured for each subtask; the task identifiers of multiple subtasks are stored in the preemption management device according to the execution order of the subtasks; and the execution position information of the subtasks is carried in the task identifier storage. That is, the task identifiers and execution position information of the subtasks are stored in one storage unit of the preemption management device. In this way, the corresponding execution position information can be indexed based on the task identifier. It is understood that if the task information includes other task information, the other task information can be stored in the corresponding storage unit of the preemption management device. The execution position information is used to indicate the position where the computing task is executed. For example, if the computing task has not yet started execution, the execution position information can indicate that execution starts from the first subtask of the computing task; when the computing task has completed the execution of the third subtask, the execution position information is updated to indicate that execution starts from the fourth subtask of the computing task.

[0053] For example, the task information for storing computing tasks can be: the preemption management device includes storage units 1 to 10, and its reading order is configured to storage units 1 to 10. The computing task includes subtasks 1 to 5 in the execution order. Then, the task identifier of subtask 1, the task identifier of subtask 2 to the task identifier of subtask 5 are stored in storage units 1 to 5 in sequence, and the location information of subtask 1, the location information of subtask 2 to the location information of subtask 5 are stored in storage units 1 to 5 in corresponding locations.

[0054] Step S103: During the execution of the computing task, the task information is updated based on the execution status of the computing task to obtain the updated task information.

[0055] The preemption management device transmits computing tasks to the stream processors, which then execute the tasks. During the execution of the computing tasks, the stream processors send the execution status of the computing tasks to the preemption management device based on the execution progress. Correspondingly, the preemption management device updates the task information based on the received execution status, obtaining updated task information, backing up the execution context of the computing tasks, and obtaining the latest computing tasks to be executed. It can be understood that when the computing tasks include an initialization task, this initialization task is jointly executed by the preemption management device and the stream processors. Since the stream processors execute the initialization task after the preemption management device, the execution status of the initialization task is also sent to the preemption management device by the stream processors based on their execution progress.

[0056] The execution status can include, but is not limited to, situations such as the completion of the computation task or the interruption of the computation task. The preemption management device can then perform operations such as adding, deleting, or modifying the task information based on different execution statuses.

[0057] The computational tasks are executed by one or more threads of the stream processor. Correspondingly, the preemption of a computational task by other computational tasks includes two scenarios: First, if a computational task is preempted while being executed by a single thread, the preemption management device obtains the execution interruption data of that thread and updates the execution position information based on the interruption data. Second, if a computational task is preempted while being executed by multiple threads, the preemption management device needs to obtain the execution interruption data of each thread separately and update the task information based on the interruption data for each thread. The execution interruption data represents the current execution data of the thread when the computational task is preempted.

[0058] In some embodiments, when the execution status indicates that the computing task has been completed, the task information of the computing task is deleted from the preemption management device; when the execution status indicates that the computing task has been interrupted, the task information of the computing task is updated. Updating the task information may include updating the stored information of the instruction code segment to start execution from the interrupted location. Accordingly, the instruction code segment includes multiple instructions, and the interrupted location may be the interrupted instruction.

[0059] In some other embodiments, when a computing task is interrupted, the portion of the computing task that has already been executed may generate intermediate data. This intermediate data is stored outside the graphics processor in the form of source operands. In order to resume the execution of the computing task, the storage information of the source operands needs to be added to the task information of the computing task. The storage information of the source operands can be the storage location of the source operands outside the graphics processor.

[0060] In other embodiments, when a computing task includes multiple subtasks, updating task information based on the execution status of the computing task can be achieved in the following ways: When a subtask is completed, its task information is deleted from the preemption management device. If a subtask is interrupted due to preemption by other computing tasks, the execution location information of the computing task is updated based on the execution interruption data.

[0061] For example, the preemption management device includes storage units 1 to 10, and its reading order is configured as storage units 1 to 10. The computation task includes subtasks 1 to 5 in execution order, and the task information of subtasks 1 to 5 is stored sequentially in storage units 1 to 5. If subtask 1 is completed, the preemption management device deletes the task information of subtask 1 from storage unit 1 and configures the reading order of the storage units to storage units 2 to 10. If the computation task is preempted by other computation tasks during the execution of subtask 1, the execution of subtask 1 is interrupted. The preemption management device obtains the execution interruption data of subtask 1 and updates the execution position information of the computation task based on the execution interruption data to resume execution from subtask 2.

[0062] Step S104: If the execution situation includes being preempted by other computing tasks and the other computing tasks have completed their execution, resume the execution of the computing task based on the updated task information; the execution priority of the other computing tasks is higher than that of the computing task.

[0063] The execution status includes situations where a computing task is preempted by another computing task. In this case, the stream processor transmits this preemption information to the preemption management device. Based on step S103, the preemption management device updates the task information, stores the execution state of the preempted task, and obtains the latest pending computing tasks. At this time, the stream processor executes other computing tasks. Once these other tasks are completed, an idle stream processor is available.

[0064] Correspondingly, idle stream processors can be used to resume execution of computation tasks. In the case where a computation task is preempted by another computation task, the updated execution location information has already been obtained based on the execution interrupt data. Furthermore, since the latest computation task to be executed has been stored in the preemption management device through step S103, the computation task can be resumed from the interrupt location based on the updated execution location information.

[0065] In some embodiments, the execution of the computational task can be resumed based on the updated task information in the following manner: based on the updated execution location information, execution is resumed from the point where the computational task was interrupted.

[0066] For example, the task information of the computing task is stored in the preemption management device, and the updated execution position information indicates that execution is resumed from line 5 of the instruction code segment. Therefore, when resuming execution, execution is resumed from line 5 of the instruction code segment.

[0067] As another example, the task information of the first subtask, the task information of the second subtask, and the task information of the fifth subtask are stored sequentially in the first to fifth storage units, and the preemption management device stores the updated execution position information. Then, the computation task is resumed from the interrupted subtask based on the updated execution position information; and the subtasks of the subsequent storage units are executed sequentially based on the configured reading order of the storage units.

[0068] In this embodiment, the received computing task information is stored in the preemption management device to back up the computing task. The backed-up computing task is updated during the execution of the computing task to obtain the latest computing task to be executed. Compared with the related technology, which requires loading the task data from outside the chip into the graphics processor first and then obtaining the sub-task from outside the chip based on the task data to resume the execution of the computing task, this application can directly obtain the sub-task from outside the chip based on the updated task information stored in the graphics processor when resuming the execution of the computing task, thereby improving the efficiency of resuming the execution of the computing task after instruction-level preemption.

[0069] Figure 2 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 2 ,like Figure 2 As shown, the task information includes execution location information, and step S103 may include at least step S201 and step S202.

[0070] Step S201: If the execution status indicates that the computing task has not ended normally, obtain the execution interruption data of the computing task.

[0071] In this context, "abnormal termination" includes situations where a computation task is preempted by another computation task, preventing its continued execution via the stream processor and resulting in an interruption. An abnormal termination indicates the need to save the data from the interrupted computation task for future resumption. Therefore, in cases of abnormal termination, the preemption management device needs to update the task information based on the interruption data.

[0072] In some embodiments, execution interruption data may include the execution location of the computation task being executed by the stream processor when the computation task is interrupted.

[0073] In some other embodiments, execution interrupt data may include the execution position of the computation task at the time of interruption and intermediate data generated by subtasks already executed by the stream processor. It is understood that when there are dependencies between preceding and following parts of the computation task, the executed part will generate intermediate data, which is stored outside the graphics processor in the form of source operands.

[0074] Accordingly, the preemption management device receives the execution status, which includes the execution interruption data of the computing task. In other words, the preemption management device receives the execution status and obtains the execution interruption data.

[0075] In some embodiments, the computing task includes multiple subtasks. In this case, the execution status includes the task identifier of the subtask being executed and information indicating that it has not ended normally. When the preemption management device receives the execution status, it obtains the location of the subtask where the computing task was interrupted based on the task identifier of the subtask. The location of the subtask where the computing task was interrupted is the execution interruption data.

[0076] In some other embodiments, there are dependencies between multiple subtasks of the computation task, that is, the data processed by the next adjacent subtask is related to the data output by the previous adjacent subtask. In this case, the execution interrupt data also includes the storage information of the intermediate data generated by the executed subtask, that is, the storage information of the source operands. The storage information of the source operands is obtained from the stream processor by the preemption management device.

[0077] For example, a computation task includes subtasks 1 through 5. A thread is currently executing subtask 3 of the computation task. If the computation task is preempted by another computation task, then subtask 3 is considered an abnormally terminated subtask. The stream processor then sends an execution status update to the preemption management device, including the task identifier of subtask 3 and information indicating abnormal termination. Based on the execution status, the preemption management device determines that the interrupted subtask location in the execution interruption data is subtask 3. If the computation task generates intermediate data in the form of source operands, the preemption management device also needs to obtain the storage information of the source operands from the stream processor.

[0078] Step S202: Update the execution location information based on the execution interruption data to obtain the updated execution location information.

[0079] The execution location information can be understood as the starting execution location when the computation task resumes execution. After updating the original execution location information based on the execution interruption data, the updated execution location information can be obtained.

[0080] In some implementations, the execution location information can be updated to indicate that execution has resumed from the interruption location, based on the execution location of the computational task when it was interrupted, contained in the execution interruption data.

[0081] For example, an interrupt flag is attached to the interrupted execution location, and when the computation task is resumed, execution starts from the interrupted execution location based on the interrupt flag.

[0082] In some other implementations, the execution interruption data also includes the storage information of the source operand. The storage information of the source operand also needs to be added to the preemption management device. When execution is resumed, the source operand is obtained according to the storage information of the source operand, and execution is resumed from the interrupted execution position based on the interruption flag.

[0083] In this embodiment, when the execution status indicates that the computing task has not ended normally, execution interruption data of the computing task is acquired; the execution location information is updated based on the execution interruption data to obtain updated execution location information. By storing the execution context when the computing task is preempted by other computing tasks in the preemption management device after updating the execution location information with execution interruption data, compared to related technologies where all data of the computing task is stored outside the graphics processor when the computing task is preempted by other computing tasks, the execution of the computing task can be resumed from the interruption location with more accurate location, thereby improving the efficiency of resuming the execution of the computing task.

[0084] In some implementations, the computation task includes multiple subtasks, and the execution location information includes the sub-location information of each of the subtasks. Step S201 can be implemented through step S2011, and step S202 can be implemented through step S2021.

[0085] Step S2011: If the execution status characterization indicates that a subtask in execution has not finished normally, obtain the sub-interruption data of the subtask in execution; the execution interruption data includes the sub-interruption data.

[0086] Step S2021: Based on the sub-interruption data of the executing sub-task, update the sub-position information of the executing sub-task among the plurality of sub-tasks to obtain the updated sub-position information corresponding to each sub-task.

[0087] Here, if a thread is in the gap between executing one subtask and preparing to execute the next subtask, and the computation task is preempted by other computation tasks, then since it has already entered the preparation period for executing the next subtask, the subtask being executed is the next subtask.

[0088] The sub-interrupt data can include the task identifier of the executing subtask and information about the subtask not ending properly. This sub-interrupt data is included in the execution status. In other words, when the preemption management device receives the execution status, it obtains the sub-interrupt data from the execution status.

[0089] Then, the preemption management device updates the sub-location information of the sub-task corresponding to the task identifier based on the task identifier. This sub-location information is used to indicate whether the sub-task is a sub-task to be executed, that is, whether the sub-task needs to be executed when execution is resumed.

[0090] In some embodiments, the preemption management device receives sub-interruption data, queries the subtask corresponding to the task identifier, and adds sub-position information to the subtask corresponding to the task identifier based on the information that it did not end normally. The content of the sub-position information can be a first marker. Thus, when resuming execution of a subtask, execution is resumed using the subtask corresponding to the first marker. That is, the updated sub-position information of each subtask includes: subtasks whose execution order precedes the subtask corresponding to the first marker are non-to be executed subtasks, and subtasks whose execution order follows the subtask corresponding to the first marker are to be executed subtasks.

[0091] For example, the computing task includes subtasks 1 to 5. A thread is executing the 3rd subtask of the computing task. If the computing task is preempted by other computing tasks at this time, then the 3rd subtask is an executing subtask. The stream processor sends the execution status to the preemption management device. The execution status includes the task identifier of the 3rd subtask and information that it did not end normally. Based on the task identifier of the 3rd subtask, a first mark is added to the 3rd subtask. When execution is resumed, execution is resumed from the subtask with the first mark.

[0092] In this embodiment, by updating the sub-location information of the subtask in the preemption management device based on the sub-interruption data of the executing subtask, the location where the computing task was interrupted can be determined based on the updated sub-location information, so as to obtain the subtask to be executed from the interruption location, thereby resuming the execution of the computing task and improving the efficiency of resuming the execution of the computing task.

[0093] Figure 3 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 3 ,like Figure 3 As shown, the sub-interruption data includes the instruction position of the interrupted instruction in the executing subtask; the sub-position information includes the instruction offset information of the subtask, and step S2021 may include at least step S301 or step S302.

[0094] Step S301: If the subtask being executed is a working subtask, update the instruction offset information based on the position of the instruction that was interrupted in the subtask being executed, and obtain the updated instruction offset information.

[0095] Step S302: If the subtask being executed is an initialization task, the instruction offset information is not updated.

[0096] The subtasks are categorized into working subtasks and initialization tasks. Each computation task includes an initialization task and working subtasks that are executed contingent upon the initialization task. It should be noted that there are no dependencies between working subtasks under different initialization tasks.

[0097] Therefore, based on this dependency relationship between the initialization task and the working subtasks, the initialization task will not need to be executed again when execution resumes only after all the working subtasks that depend on it have been completed. Thus, when the executing subtask is a working subtask, it is generally unnecessary to update the instruction offset information of the initialization task. However, since a working subtask consists of multiple instructions, its instruction offset information needs to be updated based on the location of the interrupted instruction.

[0098] Similarly, when the subtask being executed is an initialization task, since the subtasks that are executed based on the initialization task have not yet been completed, there is no need to update the instruction offset information of the initialization task.

[0099] It should be noted that the exception where updating the instruction offset information of the initialization task is not required is when the last working subtask that depends on the initialization task has been executed, in which case the instruction offset information of that working subtask and its corresponding initialization task should be updated. This update can be achieved by deleting the instruction offset information of that working subtask and its corresponding initialization task. It is understood that there are no dependencies between the working subtasks of different initialization tasks.

[0100] Each subtask comprises multiple instructions, and the instruction offset information refers to the offset of the instruction to be processed. For example, assuming a task includes N instructions, the address of the first instruction is the task address, and the instruction offset information is used to determine the instruction that needs to be executed first when executing the task.

[0101] In some embodiments, the instruction offset information is the instruction address of the instruction that needs to be executed when the task is being performed; that is, when the task is not being executed, the task can be executed starting from the first instruction based on the instruction address of the first instruction; when the task is resumed after being interrupted, the task can be executed starting from the nth instruction that was interrupted based on the instruction address of the nth instruction.

[0102] In other embodiments, the instruction offset information is the number of instructions from the first instruction of the task to be executed when the task is performed. For example, the instruction address of the instruction to be executed when the task is performed can be obtained based on this number of instructions and the task address.

[0103] For example, a subtask includes instructions 1 to 5. If the computation task is preempted by other computation tasks when the 3rd instruction is executed, the preemption management device obtains the sub-interrupt data as the 3rd instruction. In some embodiments, the instruction offset information of the subtask can be set as the instruction address of the 3rd instruction; in other embodiments, the instruction offset information of the subtask can be set to 2. In this way, the instruction address of the 3rd instruction can be determined based on the task address of the subtask (the instruction address of the 1st instruction) and the two instruction address offsets.

[0104] It is understandable that in step S301 above, the original instruction offset information needs to be updated to obtain the updated instruction offset information, so that when the subtask is resumed in the future, the position of the instruction to be executed can be determined based on the updated instruction offset information; in step S302, since the initialization task does not need to update the original instruction offset information, the instruction offset information is still the original instruction offset information.

[0105] In this embodiment of the application, by obtaining the position of the interrupted instruction in the executing subtask and updating the instruction offset information, the updated instruction offset information can be obtained. Based on the updated instruction offset information, the execution of the computation task can be resumed directly from the interrupted instruction, thereby improving the efficiency of resuming the execution of the computation task.

[0106] Figure 4 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 4 ,like Figure 4 As shown, when the subtask being executed is a working subtask, the task information also includes the storage information of the source operands, and the preemption management method may also include step S401.

[0107] Step S401: Add the storage information of the source operands to the task information to obtain the updated task information; the storage information of the source operands is generated by the stream processor when it stores the source operands in response to the preemption of the executing subtask.

[0108] In some implementations, this can be achieved by: when the subtask being executed is a working subtask, preempting the intermediate data of the management device based on the thread, generating storage information of the source operands, and storing it in the storage unit corresponding to the working subtask.

[0109] In this embodiment, the storage information of the source operand is generated based on the intermediate data generated by the thread's executed instructions, and the storage information of the source operand is added to the task information. This enables the computation task of dependent preceding and following instructions to resume execution from the interruption point, improving the applicability of the scheme to resume the execution of the computation task from the interruption point.

[0110] Figure 5 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 5 ,like Figure 5 As shown, the computation task includes multiple subtasks; the task information includes subtask sequence information, which is used to characterize the relative order between each subtask that has not ended normally among the multiple subtasks, and step S103 may include step S501.

[0111] Step S501: If the execution status indicates that the subtask has ended normally, update the subtask sequence information based on the normally ended subtask to obtain the updated subtask sequence information.

[0112] Here, the types of subtasks include initialization tasks and working subtasks. Their relationship can be understood by referring to the textual description of step S302 above. Based on the aforementioned textual description, initialization tasks should be executed before working subtasks. Therefore, when a normally completed subtask is an initialization task, the subtask order information remains unchanged. When a normally completed subtask is a working subtask, the relative order of the preceding and following subtasks is updated to obtain updated subtask order information, ensuring that completed subtasks are not executed repeatedly during resumption. When a normally completed subtask is the last subtask under an initialization task, indicating that the computation task has been completed, the subtask and its corresponding initialization task are removed from the relative subtask order, resulting in updated subtask order information, so that the computation task is removed from the list of tasks to be resumed in the preemption management device.

[0113] It is understandable that the subtasks that end normally and those that do not end normally are relative and can be determined based on the execution status of the subtask.

[0114] For example, the computation task includes an initialization task and six working subtasks. If the execution status indicates that the initialization task has completed normally, the subtask order information remains unchanged after the update. If the execution status indicates that the first working subtask has completed normally, the subtask order information of the initialization task is updated to include: the next subtask of the initialization task is the second working subtask; and the previous subtask of the second working subtask is the initialization task. If the execution status indicates that the sixth working subtask has been completed, the sixth working subtask and the initialization task are removed from the subtask order information, and the subtask order information is updated to include: the next subtask of the last working subtask of the preceding computation task is the initialization task of the next computation task.

[0115] In this embodiment, when the execution status indicates that the subtask has completed normally, the subtask sequence information is updated based on the normally completed subtask to obtain updated subtask sequence information. By updating the subtask sequence information of the computation task in real time according to the execution status of the computation task, and removing completed subtasks from the subtask sequence information, execution can be resumed directly based on the updated subtask sequence information upon resumption, thus improving the efficiency of resuming computation task execution.

[0116] In some embodiments, step S103 may include step S502.

[0117] Step S502: If the execution status indicates that the computing task has ended normally, delete the task information corresponding to the computing task.

[0118] Here, based on the textual description of step S402, if the subtask that ends normally is the last subtask associated with the initialization task, it indicates that the calculation task has been completed. Accordingly, the completion of the calculation task means that the calculation task has ended normally, and the task information corresponding to the calculation task in the preemption management device will be deleted.

[0119] In this embodiment of the application, by backing up the task information of the computing task to the preemption management device and clearing the task information of the computing task from the preemption management device when the computing task is preempted by other computing tasks, since the subtask order information of the computing task has been updated, it is only necessary to store the interrupt execution data to the preemption management device to unload the thread executing the computing task in the stream processor, thereby improving the efficiency of executing the preemption request.

[0120] Figure 6 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 6 ,like Figure 6 As shown, in some embodiments, the updated task information includes the updated execution location information, and step S104 may include step S601.

[0121] Step S601: Based on the updated execution location information, resume the execution of the computing task.

[0122] Here, the execution location information indicates the execution progress of the computation task, that is, at which subtask the computation task was interrupted. The updated execution location information includes the starting execution location when the computation task is resumed.

[0123] In some implementations, this can be achieved as follows: Upon receiving resumption execution information, the preemption management device sends the task information of the computational task to the stream processor based on the execution location information, so that the stream processor can obtain the subtask based on the received task information and resume the execution of the subtask. The resumption execution information indicates that the stream processor has completed the execution of other computational tasks and has obtained an idle stream processor.

[0124] It is understood that the resumption execution information can be sent from the software side to the preemption management device, and this application embodiment does not impose specific restrictions on this.

[0125] For example, the computing task includes subtasks 1 to 5. If the execution location information indicates that the execution start position is subtask 3, then, upon receiving the resumption execution information, the preemption management device sends the task information of subtask 3, subtask 4 and subtask 5 to the stream processor starting from subtask 3. The stream processor resumes the execution of the computing task based on the received task information.

[0126] In other embodiments, when the computational task to be resumed includes an initialization task, the starting execution position indicated by the execution location information is the initialization task. The resumption of computational task execution can be achieved as follows: Upon receiving resumption execution information, the preemption management device sends the task information of the initialization task indicated by the execution location information to the stream processor based on the execution location information, so that the stream processor resumes execution of the initialization task; then, based on the updated subtask sequence information, it sends the task information of subsequent subtasks to the stream processor, so that the stream processor resumes execution of the working subtasks.

[0127] For example, a computation task includes a 0th initialization task, a 1st working subtask, a 2nd working subtask, ... a 6th working subtask. The execution location information indicates that the starting execution location includes the 0th initialization task, and the updated subtask sequence information indicates that the next subtask of the 0th initialization task is the 2nd working subtask. Then, upon receiving the resumption execution information, the preemption management device sends the task information of the 0th initialization task to the stream processor based on the execution location information; and then, based on the updated subtask sequence information, sends the task information of the 2nd working subtask, the 3rd working subtask, ..., the 6th working subtask to the stream processor respectively.

[0128] It should be noted that the preemption management device may store task information for multiple computing tasks. Therefore, the starting execution position indicated by the execution position information includes the subtask that was first stored in the preemption management device.

[0129] In some implementations, the computation task includes multiple subtasks, and the updated execution location information includes the updated sub-location information corresponding to each of the subtasks. Step S601 can be implemented through step S6011.

[0130] Step S6011: Based on the updated sub-location information corresponding to each sub-task, resume execution of the corresponding sub-task.

[0131] Here, the technical solution for updating sub-location information can refer to the implementation method of the aforementioned step S2021.

[0132] In some embodiments, based on the sub-location information corresponding to each subtask, the execution sub-location information indicates that the subtask is a subtask of a subtask to be executed. Specifically, when the subtask is an initialization task, the preemption management device configures initialization data for the initialization task based on the sub-location information of the initialization task and sends it to the stream processor; when the subtask indicated by the sub-location information as a subtask to be executed is a working subtask, the task information of the working subtask is sent to the stream processor so that the stream processor can resume the execution of the subtask.

[0133] In this embodiment, based on the updated sub-location information corresponding to each subtask, the execution of the corresponding subtask is resumed. This enables the resumption of execution of the computing task from the point of instruction interruption when the computing task is preempted by other computing tasks, thereby improving the efficiency of resuming execution of the computing task.

[0134] Figure 7 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 7 ,like Figure 7 As shown, in some embodiments, the sub-location information includes the instruction offset information of the sub-task, and step S6011 may include step S701 or step S702.

[0135] Step S701: If the subtask is a working subtask, determine the instruction position of the instruction to be executed in the subtask based on the updated instruction offset information, execute the corresponding initialization task, and resume the execution of the subtask from the instruction to be executed based on the instruction position.

[0136] Step S702: If the subtask is an initialization task, resume execution of the initialization task based on the unupdated instruction offset information.

[0137] Here, the technical solution for updating the instruction offset information can refer to the implementation method of step S301 above. Since the initialization task is executed in its entirety when execution is resumed, if the subtask being executed is the initialization task, its instruction offset information is not updated. Therefore, during the process of resuming execution of the initialization task, the initialization task can be resumed based on the unupdated instruction offset information.

[0138] In some embodiments, an initialization task is obtained and executed based on instruction offset information; the location of the interrupted instruction, i.e., the instruction location of the instruction to be executed, is obtained based on instruction offset information, so as to obtain the instruction to be executed from the instruction location and execute the instruction to be executed; correspondingly, the instructions to be executed are obtained and executed sequentially according to the instruction offset information of the subtasks based on subtask sequence information.

[0139] For example, the updated subtask sequence information includes the following execution order: initialization task 0, working subtask 3, working subtask 4, initialization task 1, and working subtask 6. Then, based on the instruction offset information of initialization task 0, initialization task 0 is obtained and executed; then, based on the instruction offset information of working subtask 3, instructions not executed in working subtask 3 are executed from the interrupted instruction; then, based on the instruction offset information of working subtask 4, instructions not executed in working subtask 4 are executed from the interrupted instruction, and so on, until the target has completed executing all the computational tasks stored in the management device.

[0140] In this embodiment, depending on the type of subtask, the execution of the initialization task or the unexecuted instructions of the working subtask are resumed directly based on the updated or unupdated instruction offset information in the preemption management device. This reduces the time required to obtain instruction offset information from outside the chip and improves the efficiency of resuming the execution of the computation task.

[0141] In some implementations, the updated task information also includes the storage information of the source operands, which can be implemented by step S7011.

[0142] Step S7011: Send the instruction location and the storage information to the stream processor, so that the stream processor loads the source operand based on the storage information and resumes execution of the subtask from the execution instruction.

[0143] In some embodiments, the instruction location and storage information are sent to the stream processor, which resumes execution of the instruction from the instruction location and performs data processing on the source operands under the storage information to resume execution of the computation task.

[0144] For example, a subtask includes instructions 1 to 5, with instruction position 3, and stored information used to obtain source operands. Then, the preemption management device sends the instruction offset information of instruction 3 to the stream processor. The stream processor executes instruction 3 according to the instruction offset information of instruction 3, performs data processing on the source operands, and continues to execute instructions 4 and 5 to resume the execution of the computing task.

[0145] In this embodiment, intermediate data is obtained based on the storage information of the source operand, enabling computational tasks with dependencies between preceding and following subtasks to resume execution from the execution context when preempted, thus improving the applicability of the scheme for resuming computational tasks from the interrupted position.

[0146] In some embodiments, the computation task includes multiple subtasks; the task information includes subtask order information, which is used to characterize the relative order between each subtask that has not ended normally among the multiple subtasks. Step S104 can be implemented in the following manner: based on the updated relative order between each subtask that has not ended normally, each subtask that has not ended normally is executed sequentially.

[0147] In some embodiments, the preemption management device sends the task information of the first subtask included in the subtask sequence information to the stream processor; then, based on the subtask sequence information, it sends the task information of subsequent subtasks to the stream processor until all stored subtasks have been sent.

[0148] For example, the preemption management device uses subtask sequence information, including subtasks executed in the order of: initialization task 0, working subtask 3, working subtask 4, initialization task 1, and working subtask 6. Then, the preemption management device sends the stored task information of initialization task 0 to the stream processor; then, based on the subtask sequence information of initialization task 0, it queries the working subtask 3 and sends its task information to the stream processor, and so on, until the task information of working subtask 6 is sent to the stream processor.

[0149] In other embodiments of this application, when the execution situation includes being preempted by other computing tasks and the other computing tasks have been completed, the execution priority of the computing task to be resumed is higher than the execution priority of the new computing task issued by the front-end module.

[0150] Here, in order to reflect the impact of execution priority on the preemption process, a new computing task is introduced in the current embodiment. This new computing task is not the computing task issued in the aforementioned step S101, nor is it any other computing task with a higher execution priority than the aforementioned computing task. Instead, it is a new computing task issued by the front-end module.

[0151] In some implementations, when resuming the execution of computing tasks, the subtasks stored in the preemption management device are executed first. After all the subtasks in the preemption management device are sent to the stream processor, the front-end module continues to send the remaining computing tasks.

[0152] For example, a computation task includes a 0th initialization task, a 1st working subtask, a 2nd working subtask, ..., a 12th working subtask. After the 0th initialization task, the 1st working subtask, the 2nd working subtask, ..., the 5th working subtask are sent to the preemption management device, their task information is stored in the preemption management device. When the 3rd working subtask is executed, the computation task is preempted by other subtasks. At this time, the preemption management device is updated to include the task information corresponding to the 0th initialization task, the 3rd working subtask, the 4th working subtask, and the 5th working subtask. Therefore, when the computation task resumes execution, the preemption management device first sends the task information corresponding to the 0th initialization task, the 3rd working subtask, the 4th working subtask, and the 5th working subtask to the stream processor, and then the front-end module sends the 6th working subtask, the 7th working subtask, ..., the 12th working subtask to the stream processor.

[0153] In other embodiments of this application, if a preempted computing task can be configured to not support preemption, then the preemption management method further includes: in response to resuming the execution of the computing task based on updated task information, marking the resumed computing task as non-preemptible.

[0154] Here, the resumed execution of a computing task can be understood as the state of a preempted computing task after its execution has been resumed following the update of the task information.

[0155] In this way, when the execution of a computing task is resumed, the subtasks stored in the preemption management device are executed first. After all the subtasks in the preemption management device are sent to the stream processor, the task information of the remaining computing tasks is no longer stored in the preemption management device while the front-end module continues to send the remaining computing tasks.

[0156] Figure 8 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 8 ,like Figure 8 As shown, in some embodiments, the preemption management device is provided with a task list including multiple task nodes, and step S102 may include at least step S801.

[0157] Step S801: Store the subtask information of each subtask in the task information in the idle task node of the task chain list.

[0158] The preemption management device stores the subtask information of each subtask in the available task nodes of the task chain list according to the order in which the subtasks are received. The order in which the subtasks are received is the order in which they are executed. During the storage of subtask information, an available task node is determined for each subtask, and the subtask information is stored in the determined available task node accordingly.

[0159] For example, if the task list contains a first free node, a second free node, a third non-empty node, and a fourth free node, then when a subtask is received, the second free node is identified as the free task node for that subtask, the subtask information of the subtask is stored in the second free node, and the tag of the second free node is updated to the second non-empty node. At this time, when another subtask is received, the fourth free node is identified as the free task node for that subtask, the subtask information of the subtask is stored in the fourth free node, the tag of the fourth free node is updated to the fourth non-empty node, and so on.

[0160] In this embodiment of the application, by setting a task chain list in the preemption management device and storing the task information of the subtasks in the task chain list, the task information of the subtasks is backed up, so that when the subtasks are resumed, they can be resumed directly based on the backed-up task information, thereby improving the efficiency of resuming the execution of subtasks.

[0161] Figure 9 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 9 ,like Figure 9 As shown, in some embodiments, the subtask information includes subtask sequence information, which is used to characterize the relative order among the various subtasks that have not ended normally. The task list includes an end node identifier, and the task node includes a node index. The end node identifier is used to store the node index of the task node of the last subtask stored in the preemption management device. Step S801 may include at least steps S901 to S903.

[0162] Step S901: Store the node index of the idle task node into the task node stored in the last subtask as a backward index, which is used to point to the next task node of the task node.

[0163] Each task node has a unique node index for identification, allowing for the unique retrieval of a task node based on the node index. The task linked list stores multiple subtasks received by the preemption management device. Therefore, it can be understood that the subtasks within the task linked list change dynamically as the preemption management device receives them. Thus, the end node identifier is the node index of the last subtask in the current state within the task linked list; that is, this end node identifier changes dynamically as the subtasks within the task linked list change.

[0164] Accordingly, after storing the subtask information in an idle task node, the subtask is updated to become the last subtask in the task list. To distinguish between the last subtask before and after the update, the last subtask before the update is called the original last subtask, and the last subtask after the update is called the new last subtask. Then, the subtask following the original last subtask is the new last subtask. This new last subtask is stored in an idle task node, so the index of the idle task node is used as the backward index of the original last subtask.

[0165] In some implementations, the task node includes a backward index storage space, where the node index of the idle task node is stored in the backward index storage space of the original last subtask, so that the node index of the idle task node becomes the backward index of the original last subtask. In other words, after the original last subtask is executed, the subtask of the idle task node can be executed based on the backward index of the task node of the original last subtask.

[0166] For example, the original last subtask in the task list is the 5th subtask, and the subtask information of the 5th subtask is stored in the 7th task node, with the end node identified as the index of the 7th task node. At this time, the 6th subtask is received, and the idle task node for the 6th subtask is determined to be the 4th task node. Then, the index of the 4th task node is stored in the backward index storage space of the 7th task node, so that the index of the 4th task node becomes the backward index of the 7th task node.

[0167] Step S902: Store the node index of the task node where the last subtask is stored in the idle task node as a forward index, which is used to point to the previous task node of the task node.

[0168] In some implementations, the task node includes a forward index storage space. The node index of the original last subtask's task node is stored in the forward index storage space of the idle task node, so that the node index of the original last subtask's task node becomes the forward index of the idle task node. In other words, after the subtasks of the idle task node are executed, the previous subtask can be queried based on the forward index of the idle task node, thereby updating the subtask order information.

[0169] For example, the original last subtask in the task list is the 5th subtask, and the subtask information of the 5th subtask is stored in the 7th task node, with the end node identified as the index of the 7th task node. At this time, the 6th subtask is received, and the idle task node for the 6th subtask is determined to be the 4th task node. Then, the index of the 7th task node is stored in the forward index storage space of the 4th task node, so that the index of the 7th task node becomes the forward index of the 4th task node.

[0170] Step S903: Use the node index of the idle task node as the end node identifier; wherein, the subtask sequence information includes the end node identifier, the forward index and the backward index of each task node.

[0171] It should be noted that step S903 should be executed only after steps S901 and S902 have been completed. This is because the end node identifier used in steps S901 and S902 is the end node identifier before updating the task list, while step S903 is used to update the end node identifier. Once step S903 is executed, steps S901 and S902 will no longer be able to obtain the end node identifier before the update.

[0172] Specifically, after storing the subtask information of a subtask in an idle task node, the subtask stored in the idle task node is updated to become the last subtask in the task list. Therefore, the node index of the idle task node is used as the end node identifier.

[0173] Accordingly, based on the end node identifier and the forward and backward indices of each task node, the subtask sequence information of the subtasks is stored in the task linked list, thereby enabling the execution order of each subtask to be determined from other subtasks by querying the task linked list.

[0174] For example, the original last subtask in the task list is the 5th subtask, and the subtask information of the 5th subtask is stored in the 7th task node, with the end node identifier being the index of the 7th task node; at this time, the 6th subtask is received, and the idle task node for the 6th subtask is determined to be the 4th task node, then the end node identifier is updated to the index of the 4th task node.

[0175] In this embodiment, by setting an end node identifier in the task chain and setting forward and backward indices for each task node, and updating the end node identifier and the forward and backward indices of each task node according to the dynamic changes of the subtasks contained in the task chain, the preemption management device can update the subtask order information in a timely manner according to the received subtasks, so as to obtain the execution order of the subtasks of the backup computing task. This allows the execution order of the subtasks to be directly obtained from the task chain when the subtasks are resumed, thus improving the efficiency of resuming the execution of subtasks.

[0176] In some implementations, the task list further includes a starting node identifier, which is used to store the node index of the task node where the first subtask is stored in the preemption management device, and step S801 may also include step S904.

[0177] Step S904: When all task nodes in the task list are idle, store the node index of the idle task node in the start node identifier and the end node identifier; store the default value in the idle task node as a forward index; the subtask order information also includes the start node identifier.

[0178] The condition that all task nodes are idle can be defined as follows: all subtasks in the task list have been completed, or the preemptive management device has been initialized or restarted. When a subtask is received while all task nodes are idle, it is the only subtask in the current task list. That is, it is both the first and last subtask in the task list. Therefore, the node index of the idle task node storing the subtask is stored in the start node identifier and end node identifier.

[0179] Accordingly, if the subtask is the first subtask in the task list, and there is no preceding subtask, then the forward index of the free task node storing the subtask is determined to be the default value.

[0180] In this way, based on the start node identifier, end node identifier, and the forward and backward indices of each task node, the subtask sequence information of the subtasks is stored in the task linked list. This allows the first subtask in the task linked list to be determined by querying the start node identifier, and the execution order of each subtask with other subtasks can also be determined.

[0181] For example, if all tasks in the task list are idle, and the 0th subtask is received, the idle task node for the 0th subtask is determined to be the 4th task node. Then, the index of the 4th task node is used as the start node identifier and the end node identifier.

[0182] In this embodiment, by setting a starting node identifier in the task chain, when resuming the execution of a subtask, the first subtask in the task chain can be determined directly by querying the starting node identifier, thereby resuming the execution of the subtask and improving the efficiency of resuming the execution of the subtask.

[0183] In some embodiments, the subtask information further includes other task information; the preemption management method further includes:

[0184] Store the other task information of the subtask in the idle task node;

[0185] The other task information includes at least one of the following: the task identifier, task type, and sub-location information of the subtask.

[0186] The task identifier of a subtask uniquely identifies it. When updating the task information of a subtask, the task identifier carried by the subtask can be matched with the task identifiers stored in the task chain to determine the task node of the subtask that needs to be updated. The task type stores whether the subtask is an initialization task or a working subtask. When the execution status of a subtask is received, the task type of the subtask can be used to determine whether to update the task information of the subtask. The sub-location information can be referred to the description in step S2021 above.

[0187] Figure 10 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 10 ,like Figure 10 As shown, in some embodiments, step S103 may include steps S1001 and S1002.

[0188] Step S1001: If the execution status characterization indicates that a subtask in execution has not finished normally, obtain the sub-interruption data of the subtask in execution.

[0189] The technical solution for "obtaining the sub-interrupt data of the executing subtask" can refer to the implementation method of "obtaining the sub-interrupt data of the executing subtask" in the aforementioned step S2011.

[0190] Step S1002: Based on the sub-interruption data of the executing sub-task, update the sub-location information stored in the task node of the executing sub-task.

[0191] Here, updating the sub-location information stored in the task node of the executing subtask can be done by storing the sub-interrupt data in the task node of the executing subtask to update the sub-location information of the obtained subtask.

[0192] For example, the computation task includes subtasks 1 to 5. If subtask 3 is a subtask that has not finished executing normally, and the sub-interruption data of subtask 3 includes the location of the interrupted instruction, then the location of the interrupted instruction is stored in the task node of subtask 3.

[0193] Here, the technical solution for updating the sub-location information stored in the task node of the executing sub-task can refer to the technical solution in step S2021.

[0194] In some implementations, the sub-interruption data includes the instruction position of the interrupted instruction in the executing subtask; the sub-position information includes the instruction offset information of the subtask, and the sub-position information can be updated in the following way: when the executing subtask is a working subtask, the instruction offset information is updated based on the instruction position of the interrupted instruction in the executing subtask to obtain the updated instruction offset information.

[0195] The technical solution for updating instruction offset information can refer to the implementation method of step S301.

[0196] In this embodiment, the sub-interrupt data is stored in the task node of the subtask, so that when the subtask resumes execution, the sub-interrupt data can be directly read, and execution can be resumed from the interrupted instruction based on the sub-interrupt data, thereby improving the efficiency of resuming the execution of the subtask.

[0197] In some other embodiments, step S103 may also include steps S1003 and S1004.

[0198] Step S1003: If the execution status indicates that the subtask in execution is an initialization task and has ended normally, the subtask sequence information and the sub-position information of the subtask in execution are not updated.

[0199] Here, since the initialization task in the computation task is a prerequisite for executing the working subtasks within the computation task, if the computation task is preempted by other computation tasks, the initialization task needs to be executed again before the subsequent working subtasks can resume execution. Therefore, the task information of the initialization subtask is not updated after its execution is complete. In other words, the task information of the initialization task in the computation task is only updated after the working subtasks within the computation task have been completed.

[0200] Step S1004: If the execution status indicates that the subtask in execution is a working subtask and has ended normally, delete the task node of the subtask in execution from the task chain list and update the subtask sequence information.

[0201] Here, since execution of a computational task resumes from the interrupted subtask based on its sub-location information, subtasks that ended normally do not need to be executed again upon resumption. Therefore, if a subtask ends normally, there is no need to back up its task information. In this embodiment, the backup of other task information for the subtask is disabled by deleting its task node from the task list.

[0202] Accordingly, the backup of the subtask sequence information for that task is removed. In this embodiment, the task is removed from the subtask sequence information by updating the forward index, backward index, start node identifier, and end node identifier of the relevant subtask.

[0203] In this embodiment, for subtasks that have finished executing normally, their task information is selectively updated in the task list according to the task type of the subtask. This allows the latest execution status of the computation task to be obtained by reading the task list, which is beneficial for directly resuming the execution of the computation task based on the task list and improves the efficiency of resuming the execution of the computation task.

[0204] In some embodiments, step S1004 can be implemented through step S10041, step S10042, or step S10043.

[0205] Step S10041: If the subtask is not the last subtask of the computation task, use the node index of the next task node of the subtask as the backward index of the previous task node of the subtask, and use the node index of the previous task node of the subtask as the forward index of the next task node of the subtask.

[0206] Here, since the working subtask is not the last working subtask of the computation task, it is not necessary to delete the initialization task corresponding to the working subtask. Therefore, the subtask order information needs to be updated to: the next subtask of the initialization task corresponding to the working subtask is the next subtask of the working subtask, so as to remove the working subtask from the execution order indicated by the subtask order information.

[0207] Accordingly, the next subtask of the initialization task corresponding to the work subtask includes: updating the backward index of the initialization task corresponding to the work subtask, and updating the forward index of the next subtask of the work subtask.

[0208] For example, the computation task includes a 0th initialization task, a 1st subtask, and a 2nd subtask. The 0th initialization task is stored in the 0th task node, the 1st subtask is stored in the 2nd task node, and the 2nd subtask is stored in the 3rd task node. Then, when the execution status indicates that the 1st subtask has been completed, the backward index of the 0th task node is updated to the index of the 3rd task node; the forward index of the 3rd task node is updated to the index of the 0th task node; and the other task information of the 1st subtask is deleted from the 1st task node.

[0209] Step S10042: If the subtask is the last subtask of the computation task, update the forward index of the next task node of the last subtask.

[0210] Here, if the last subtask of the computation task is the working subtask, it means that the last subtask of the computation task has ended normally. In this case, the working subtask and its corresponding initialization task are removed from the task list to remove the backup of the task information of the working subtask and its corresponding initialization task.

[0211] Accordingly, the subtask order information needs to be updated as follows: the next subtask of the previous subtask of the initialization task corresponding to the working subtask is the next subtask of the working subtask, and the previous subtask of the next subtask of the working subtask is the previous subtask of the initialization task corresponding to the working subtask, so as to remove the working subtask from the execution order indicated by the subtask order information.

[0212] Accordingly, the next subtask of the previous subtask of the initialization task corresponding to the work subtask is the next subtask of the work subtask, and the previous subtask of the next subtask of the work subtask is the previous subtask of the initialization task corresponding to the work subtask, including: updating the backward index of the previous subtask of the initialization task corresponding to the work subtask, and updating the forward index of the next subtask of the work subtask.

[0213] For example, the computation task includes a 0th initialization task, a 1st working subtask, a 2nd working subtask, a 1st initialization task, a 3rd working subtask, a 2nd initialization task, and a 4th working subtask. The 0th initialization task is stored in the 0th task node, the 1st working subtask is stored in the 2nd task node, the 2nd working subtask is stored in the 3rd task node, the 1st initialization task is stored in the 4th task node, the 3rd working subtask is stored in the 5th task node, the 2nd initialization task is stored in the 5th task node, and the 4th working subtask is stored in the 6th task node. Then, when the execution status indicates that the 3rd working subtask has been completed, the other subtask information of the 1st initialization task and the 3rd working subtask is deleted, the backward index of the 3rd task node is updated to the index of the 5th task node, and the forward index of the 5th task node is updated to the index of the 3rd task node.

[0214] Step S10043: If the subtask is the last subtask of the computation task, and the previous task node of the last subtask is the task node pointed to by the starting node identifier, then the node index of the next task node of the last subtask is used as the starting node identifier.

[0215] Understandably, when each subtask of the computation task is completed, its task node is removed from the task list. The previous task node of the last subtask is the task node of its corresponding initialization task. Therefore, the subtask and its previous task node must both be removed from the task list. Furthermore, the fact that the previous task node is pointed to by the start node indicates that the initialization task is the first task in the task list. Therefore, after deleting the initialization task, the first task in the task list needs to be redefined to update the task node pointed to by the start node.

[0216] Accordingly, after deleting the initialization task, it is necessary to redetermine the first task in the task chain as the next subtask of the normally completed work subtask. Therefore, it is necessary to update the node index of the node whose starting node is identified as the next task node of the work subtask.

[0217] For example, the computation task includes a first initialization task, a third working subtask, a second initialization task, and a fourth working subtask; the first initialization task is stored in the 0th task node, the first working subtask is stored in the 2nd task node, the second working subtask is stored in the 3rd task node, the first initialization task is stored in the 4th task node, the third working subtask is stored in the 5th task node, the second initialization task is stored in the 5th task node, and the fourth working subtask is stored in the 6th task node. Then, if the execution status indicates that the third working subtask has been completed, the other subtask information of the first initialization task and the third working subtask is deleted, and the starting node index is updated to the index of the 5th task node.

[0218] Figure 11 A schematic diagram of the implementation process of a preemption management method provided in this application embodiment. Figure 10 First, such as Figure 11 As shown, in some embodiments, step S104 may include steps S1101 and S1102.

[0219] Step S1101: Based on the starting node identifier, execute the subtask of the task node pointed to by the starting node identifier to start resuming the execution of the computation task of the task chain.

[0220] In this embodiment of the application, the starting node identifier is read to execute the subtask of the task node pointed to by the starting node identifier, and then the next subtask is executed sequentially based on the backward index of the subtask.

[0221] Step S1102: In response to the completion of the subtask of the task node pointed to by the end node identifier, generate an event indicating that all task nodes in the task list are idle.

[0222] In this embodiment of the application, when the subtask of the task node pointed to by the end node identifier is completed, it means that all subtasks in the task chain have been completed, and the task chain is idle according to the update method of the task chain.

[0223] This application also provides a preemption management device. Figure 12 This is a schematic diagram of the composition structure of a preemption management device provided in an embodiment of this application, as shown below. Figure 12 As shown, the preemption management device 1200 includes a receiving unit 1210, a storage unit 1220, an update unit 1230, and an execution unit 1240, wherein,

[0224] The receiving unit 1210 is used to receive computing tasks issued by the front-end module;

[0225] The storage unit 1220 is used to store the task information of the computing task in the preemption management device;

[0226] The updating unit 1230 is used to update the task information based on the execution status of the computing task during the execution of the computing task, so as to obtain the updated task information.

[0227] The execution unit 1240 is configured to resume execution of the computing task based on updated task information when the execution situation includes being preempted by other computing tasks and the other computing tasks have completed execution; the execution priority of the other computing tasks is higher than that of the computing task.

[0228] In some embodiments, the updating unit 1230 is further configured to, when the execution status indicates that the computing task has not ended normally, obtain execution interruption data of the computing task; update the execution location information based on the execution interruption data to obtain updated execution location information.

[0229] In some embodiments, the updating unit 1230 is further configured to: acquire sub-interruption data of the executing sub-task when the execution status characterization indicates that the executing sub-task has not ended normally; the execution interruption data includes the sub-interruption data; and update the sub-position information of the executing sub-task among the multiple sub-tasks based on the sub-interruption data of the executing sub-task to obtain the updated sub-position information corresponding to each of the sub-tasks.

[0230] In some embodiments, the updating unit 1230 is further configured to, when the executing subtask is a working subtask, update the instruction offset information based on the position of the instruction that was interrupted in the executing subtask to obtain the updated instruction offset information; and when the executing subtask is an initialization task, not update the instruction offset information.

[0231] In some embodiments, the update unit 1230 is further configured to add the storage information of the source operand to the task information to obtain the updated task information; the storage information of the source operand is generated by the stream processor when storing the source operand in response to the preemption of the executing subtask.

[0232] In some embodiments, the updating unit 1230 is further configured to update the subtask sequence information based on the normally completed subtask when the execution status indicates that the subtask has ended normally, so as to obtain the updated subtask sequence information.

[0233] In some embodiments, the updating unit 1230 is further configured to delete the task information corresponding to the computing task when the execution status indicates that the computing task has been completed normally.

[0234] In some embodiments, the execution unit 1240 is further configured to resume the execution of the computing task based on the updated execution location information.

[0235] In some embodiments, the execution unit 1240 is further configured to resume execution of the corresponding sub-task based on the updated sub-location information corresponding to each of the sub-tasks.

[0236] In some embodiments, the execution unit 1240 is further configured to, when the subtask is a working subtask, determine the instruction position of the instruction to be executed in the subtask based on the updated instruction offset information, execute the corresponding initialization task, and resume execution of the subtask from the instruction to be executed based on the instruction position; and when the subtask is an initialization task, resume execution of the initialization task based on the unupdated instruction offset information.

[0237] In some embodiments, the execution unit 1240 is further configured to send the instruction location and the storage information to the stream processor, so that the stream processor loads the source operand based on the storage information and resumes execution of the subtask from the execution instruction.

[0238] In some embodiments, the execution unit 1240 is further configured to execute each of the abnormally terminated subtasks sequentially based on the updated relative order between the various abnormally terminated subtasks.

[0239] In some embodiments, when the execution situation includes being preempted by other computing tasks and the other computing tasks have completed their execution, the execution priority of the computing task to be resumed is higher than the execution priority of the new computing task issued by the front-end module.

[0240] In some embodiments, the receiving unit 1210 is further configured to mark the resumed computing task as non-preemptible in response to the resumption of execution of the computing task based on the updated task information.

[0241] In some embodiments, the storage unit 1220 is further configured to store the subtask information of each subtask in the task information in an idle task node of the task linked list.

[0242] In some embodiments, the storage unit 1220 is further configured to store the node index of the idle task node to the task node stored in the last subtask as a backward index, the backward index being used to point to the next task node of the task node; store the node index of the task node stored in the last subtask to the idle task node as a forward index, the forward index being used to point to the previous task node of the task node; and use the node index of the idle task node as the end node identifier; wherein, the subtask order information includes the end node identifier, the forward index and the backward index of each task node.

[0243] In some embodiments, the storage unit 1220 is further configured to, when all task nodes in the task list are idle, store the node index of the idle task node in the start node identifier and the end node identifier; store the default value in the idle task node as a forward index; and the subtask order information further includes the start node identifier.

[0244] In some embodiments, the storage unit 1220 is further configured to store other task information of the subtask in the idle task node; the other task information includes at least one of the following: the task identifier, task type, and sublocation information of the subtask.

[0245] In some embodiments, the updating unit 1230 is further configured to obtain sub-interruption data of the executing sub-task when the execution status characterization indicates that the executing sub-task has not ended normally among the plurality of sub-tasks;

[0246] Based on the sub-interruption data of the executing sub-task, update the sub-location information stored in the task node of the executing sub-task.

[0247] In some embodiments, the updating unit 1230 is further configured to: not update the subtask order information of the initialization subtask and the sub-position information of the subtask in execution when the execution status indicates that the subtask in execution is an initialization subtask and has ended normally; and delete the task node of the subtask in execution from the task list and update the subtask order information when the execution status indicates that the subtask in execution is a working subtask and has ended normally.

[0248] In some embodiments, the updating unit 1230 is further configured to, when the subtask is not the last subtask of the computation task, use the node index of the next task node of the subtask as the backward index of the previous task node of the subtask, and use the node index of the previous task node of the subtask as the forward index of the next task node of the subtask.

[0249] If the subtask is the last subtask in a computation task, update the forward index of the next task node of the last subtask.

[0250] If the subtask is the last subtask in a computation task, and the previous task node of the last subtask is the task node pointed to by the starting node identifier, then the node index of the next task node of the last subtask is used as the starting node identifier.

[0251] In some embodiments, the execution unit 1240 is further configured to execute a subtask of the task node pointed to by the starting node identifier based on the starting node identifier, so as to begin resuming the execution of the computation task of the task list;

[0252] In response to the completion of the subtask of the task node pointed to by the end node identifier, an event is generated indicating that all task nodes in the task list are idle.

[0253] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0254] It should be noted that, in the embodiments of this application, if the above-mentioned preemption management method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the preemption management method of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0255] The following examples illustrate the application of the preemption management method provided in this application in real-world scenarios. This application relates to GPU design, stream multiprocessor (SM), general-purpose processor design, digital chip design, and instruction-level execution preemption.

[0256] Figure 13 This is a schematic diagram of the preemption management device provided in an embodiment of this application. Figure 13 As shown, the preemption management device 1300 includes an arbitration module 1320, a preemption management module 1330, a resource application module 1340, a resource management module 1350, and a thread source data initialization module 1360 (corresponding to the resource initialization module in the aforementioned embodiment). The arbitration module 1320 communicates with the front-end module 1310, and the thread source data initialization module 1360 communicates with the stream processor 1370. The front-end module 1310 is used to obtain control information from the software side to schedule the threads of the stream processor 1370 to perform computing tasks through the preemption management device 1300.

[0257] In this embodiment, the front-end module 1310 obtains the control stream from an external source, performs concurrent control based on the control stream, decomposes the obtained control stream data into workitem-level data, and assembles the workitems into computational tasks within the front-end module 1310. The front-end module 1310 also transmits the assembled tasks to the arbitration module 1320 in the form of task information. Each task contains a certain number of workitems.

[0258] The preemption management module 1330 is used to store task information and also to send the task information of the computation task to the arbitration module 1320.

[0259] The arbitration module 1320 is used to broadcast between the front-end module 1310 and the preemption management module 1330, so that the front-end module 1310 or the preemption management module 1330 sends task information to it. The arbitration module 1320 is also used to receive task information from the front-end module 1310 or the preemption management module 1330, and transmit the received task information to the resource request module 1340.

[0260] The resource request module 1340 receives task information transmitted by the arbitration module 1320, requests shared data required for task execution from the resource management module 1350 based on the received task information, and sends the task information and the requested shared data to the thread source data initialization module 1360. The shared data refers to the source data used by each thread during the execution of a task through multiple threads.

[0261] In this embodiment, the resource request module 1340 is further configured to determine whether a task supports preemption based on task information, and selectively transmit the task information to the preemption management module 1330 so that the preemption management module 1330 stores the task information of tasks that support preemption.

[0262] The thread source data initialization module 1360 is used to receive shared data and task information transmitted by the resource request module 1340, and initialize the shared data to obtain an initialization result. The thread source data initialization module 1360 is also used to transmit the initialization result and task information to the stream processor 1370. The initialization result can be directly used by each thread during the execution of tasks by multiple threads.

[0263] In this embodiment of the application, the stream processor 1370 includes multiple threads, and the stream processor 1370 is also used to transmit the execution status of tasks in each thread to the stream processor 1370, so that the preemption management module 1330 updates the stored task information based on the task execution status.

[0264] In other words, the arbitration module 1320 determines whether the task to be executed by the stream processor comes from the front-end module 1310 or the preemption management module 1330; this determination can be based on configuration registers. The resource management module 1350 manages the resources of threads at the task level. The preemption management module 1330 records the context data of the stream processor's tasks and maintains this context data during the execution of preemption requests. The stream processor is used to perform instruction fetching, decoding, and task execution operations in parallel through multiple threads.

[0265] Figure 14 This is a flowchart illustrating the preemption management method provided in an embodiment of this application. Figure 14 As shown in the embodiments of this application, the preemption management method includes steps S1401 to S1410.

[0266] Step S1401: The arbitration module 1320 makes a decision, causing the front-end module 1310 to send a calculation task to the arbitration module 1320.

[0267] In the embodiments of this application, a computing task includes at least one initialization task and at least one working subtask. Within a computing task, a working task can only begin execution after the initialization task has been completed. It should be noted that there is no such dependency between the initialization task of one computing task and the working subtask of another computing task.

[0268] Here, the front-end module 1310 needs to decompose the received control flow into workitem-level data, then assemble it into the aforementioned calculation task, and send it to the arbitration module 1320 in the form of a calculation task.

[0269] In some embodiments of this application, a logic module may be set between the front-end module 1310 and the arbitration module 1320. The front-end module receives the control flow and decomposes the control flow into workitem-level data. The logic module then assembles a certain number of workitem-level data into a calculation task and sends the assembled calculation task to the arbitration module 1320.

[0270] For example, multiple computational tasks can be represented as a task data stream, including: initialization task 0 (task 0), subtask 0.0 (task 0_0), subtask 0.1 (task 0_1), ..., subtask 0.N (task 0_N); initialization task 1 (task 1), subtask 1.0 (task 1_0), subtask 1.1 (task 1_1), ..., subtask 1.N (task 1_N), ...

[0271] In step S1402, the arbitration module 1320 transmits the received task to the resource request module 1340.

[0272] In step S1403, the resource application module 1340 requests the shared data required for the task from the resource management module 1350, and if the task is a preemptible task, it transmits the task to the preemption management module 1330.

[0273] Step S1404: The preemption management module 1330 receives the task and stores the task information in a doubly linked list.

[0274] The preemption management module is used to record the task context of the stream processor (MP) and ensure related functions during instruction-level preemption.

[0275] In this embodiment, the preemption management module 1330 stores the task information of the computing tasks through a doubly linked list. It is understood that the preemption management module 1330 implements the establishment of the doubly linked list and the maintenance of the task sequence within the list. The establishment of the doubly linked list mainly occurs when receiving computing tasks transmitted from the front-end module, while the maintenance of the list mainly occurs during the execution of the computing tasks.

[0276] In other embodiments, the doubly linked list can also be a queue, and this application does not limit this.

[0277] Figure 15 for Figure 14 This is a partial diagram of a linked list used in the preemptive management method. A doubly linked list contains multiple data structures (entries), a head pointer structure (oldest_entry_index), and a tail pointer structure (current_index). For example... Figure 15 As shown, each entry corresponds to a valid bit (entry_valid) and a position identifier (entry index). The valid bit indicates whether the entry is empty, and the position identifier indicates the entry's position in the doubly linked list. Each entry includes multiple bit fields for storing task information, which may include: task identifier (task_id), task type (task_type), preceding task (earlier_index), following task (later_index), and miscellaneous data (misc_data). The task identifier is used to match received tasks to determine the target data structure from multiple data structures; the task type identifies the task type; the preceding task queries the entry corresponding to the previous task of the task corresponding to this entry, and the following task queries the entry corresponding to the next task of the task corresponding to this entry. The task identifier, task type, preceding task, and following task can all be used to implement operations such as updating task information. Miscellaneous data may include common data for computation tasks and can be used to resume the execution of preempted tasks.

[0278] The head task pointer structure stores the head pointer, which points to the entry corresponding to the first task in the doubly linked list, indicating the position of the oldest entry in the list where task information is stored. It's understood that the first task in the doubly linked list is generally the initialization task. The tail task pointer structure stores the tail pointer, which points to the entry corresponding to the last task in the doubly linked list, indicating the position of the most recently stored entry in the list. In other words, the tail pointer indicates which entry the next task should be inserted into.

[0279] The 0th computation task includes the 0th initialization task, the 0.1st working subtask, the 0.2nd working subtask, ..., and the 0.Nth working subtask. The 1st computation task includes the 1st initialization task, the 1.1st working subtask, the 1.2nd working subtask, ..., and the 1.Nth working subtask.

[0280] In this embodiment, the number of threads in the stream processor may be less than the number of data structures in the doubly linked list. Therefore, when the stream processor is fully loaded, the computation task received by the arbitration module 1320 is a non-preemptible task. In other embodiments, if the number of threads in the stream processor is greater than or equal to the number of data structures in the doubly linked list, then when the stream processor is fully loaded or the linked list is full, the computation task received by the arbitration module 1320 is a non-preemptible task. Accordingly, non-preemptible tasks will be executed through the stream processor.

[0281] Figure 16 for Figure 14 A flowchart illustrating step S1404 in the preemptive management method. (See attached diagram.) Figure 16 As shown in the embodiments of this application, step S1404 may include at least steps S1601 to S1609.

[0282] In this embodiment of the application, steps S1601 to S1609 are executed by the preemption management module 1330. It can be understood that before executing step S1601, the preemption management module 1330 is powered on (step S1610) and put into a standby state, waiting for the work subtask (step S1611). The work subtask here can be understood as storing the task information of the task that supports preemption.

[0283] Step S1601: Receive the task, wherein the task is a preemptive task.

[0284] Step S1602: Determine if the doubly linked list is empty.

[0285] If yes, proceed to step S1603; otherwise, proceed to step S1606.

[0286] Step S1603: Determine an empty data structure in the doubly linked list.

[0287] Step S1604: Store the position identifier of the free data structure into the head pointer structure and tail pointer structure of the doubly linked list.

[0288] Step S1605: Store the task information of the task in an idle data structure, where there is no forward task.

[0289] Step S1606: Determine an empty data structure in the doubly linked list.

[0290] Step S1607: Store the location identifier of the idle data structure into the backward task of the forward data structure, wherein the forward data structure is the data structure pointed to by the tail pointer structure of the doubly linked list.

[0291] Step S1608: Store the task information of the task in the idle data structure, wherein the forward task of the idle data structure is the position identifier of the forward data structure.

[0292] Step S1609: Store the position identifier of the free data structure into the tail pointer structure.

[0293] Specifically, step S1609 should be executed only after step S1607 has been completed. This is because executing step S1607 requires obtaining the data structure pointed to by the tail pointer structure of the doubly linked list. If step S1609 is executed first, then the forward data structure of the free data structure cannot be obtained when executing step S1607.

[0294] In step S1405, the resource application module 1340 receives the shared data returned by the resource management module 1350 and transmits the shared data and the task together to the thread source data initialization module 1360.

[0295] Step S1406: The thread source data initialization module 1360 receives the common data and tasks, initializes the common data, and transmits the initialization results and tasks to the stream processor 1370.

[0296] In step S1407, the stream processor 1370 receives the initialization result and the task, obtains the private data of the task from outside the chip based on the task, executes the task through multiple threads of the stream processor 1370 based on the initialization result and the private data, and transmits the execution status of the task to the preemption management module 1330.

[0297] The stream processor is used to implement parallel instruction fetching, decoding, and execution operations for multiple tasks.

[0298] Step S1408: The preemption management module 1330 receives the execution status of the task and updates the task information based on the execution status.

[0299] Figure 17 for Figure 14 A flowchart illustrating step S1408 in the preemptive management method. (See attached diagram.) Figure 17 As shown in the embodiments of this application, step S1408 may include at least steps S1701 to S1711.

[0300] In this embodiment of the application, steps S1701 to S1711 are executed by the preemption management module 1330. It can be understood that before executing step S1701, the preemption management module 1330 is powered on (step S1712) and put into a waiting state (step S1713) to wait for a task. The task here can be understood as updating the task information of a non-preemptive task.

[0301] Step S1701: Receive the task, wherein the task is a non-preemptive task.

[0302] Step S1702: Based on the task identifier, determine the target data structure corresponding to the location identifier that matches the task identifier.

[0303] Step S1703: Determine whether the received task has been executed normally.

[0304] If yes, proceed to step S1705; otherwise, proceed to step S1704.

[0305] Step S1704: Update the miscellaneous data in the target data structure.

[0306] After step S1704 is completed, the update of the task information for the task ends, and the preemption management module 1330 enters a waiting state.

[0307] Step S1705: Based on the task type of the target data structure, determine whether the task is a working subtask.

[0308] If yes, then proceed to step S1706; otherwise, the process ends, meaning the update of the task information for this task is complete, and the preemption management module 1330 enters a waiting state.

[0309] Step S1706: Based on the forward and backward tasks of the target data structure, determine the forward and backward data structures corresponding to the tasks.

[0310] Step S1707: Based on the task types of the forward data structure and the backward data structure, determine whether the forward task and the backward task of the task are both initialization tasks.

[0311] If yes, proceed to step S1709; otherwise, proceed to step S1708.

[0312] Step S1708: Delete the task information from the target data structure.

[0313] After step S1708 is completed, the update of the task information for the task ends, and the preemption management module 1330 enters a waiting state.

[0314] Step S1709: Based on the head pointer, determine whether the forward task is the first task of the doubly linked list.

[0315] If yes, proceed to step S1711; otherwise, proceed to step S1710.

[0316] Step S1710: Delete the task information of the task from the target data structure, and delete the task information of the forward task from the forward data structure.

[0317] Step S1711: Delete the task information of the task from the target data structure, delete the task information of the preceding task from the preceding data structure, and update the head pointer.

[0318] Upon completion of step S1710 or step S1711, the update of the task information for the task ends, and the preemption management module 1330 enters a waiting state.

[0319] In this embodiment, in the event of instruction-level preemption, the task sequence (which can be understood as the aforementioned data structure) of tasks that have not been completed normally in the preemption management module 1330 will only update miscellaneous data. The updated miscellaneous data is used for subsequent resumption of computational task execution (restore context). The updated miscellaneous data is necessary information for the thread to resume execution of the computational task, and may include, but is not limited to, one or more of the following: the PC pointer of the interrupt instruction, private data for resuming the execution of the computational task, and data of the called code segment. The data of the called code segment may be stored in the code segment PC. The code segment is called based on the code segment PC to execute the initialization task of the computational task to initialize the computational task.

[0320] Step S1409: Upon receiving a preempted task, the arbitration module 1320 makes a decision, causing the preemption management module 1330 to send the task to the arbitration module 1320 based on the task information.

[0321] In this embodiment of the application, when all task information of the preemption management module 1330 has been sent, step S701 is executed.

[0322] Figure 18 for Figure 14 A flowchart illustrating step S1409 in the preemption management method. In this embodiment, during subsequent context restoration, the preemption management module 1330 starts with the head pointer data structure, reads the stored task information from the doubly linked list, parses the task information of each data structure one by one, and sends it to the arbitration module. For example... Figure 18 As shown, Figure 18As shown in the embodiments of this application, step S1409 may include at least steps S1801 to S1805.

[0323] In this embodiment of the application, steps S1801 to S1805 are executed by the preemption management module 1330. It can be understood that before executing step S1801, the preemption management module 1330 is powered on (step S1806).

[0324] Step S1801: Determine the data structure pointed to by the head pointer.

[0325] Step S1802: Determine whether the data structure is the data structure pointed to by the tail pointer.

[0326] If not, proceed to step S1803; if yes, proceed to step S1805.

[0327] Step S1803: Read and parse the task information stored in the data structure.

[0328] The information obtained from parsing may include: the task type of the computation task, the source data, the storage address, and the storage size.

[0329] Step S1804: Obtain the next data structure based on the location identifier of the backward task storage in the data structure.

[0330] Step S1805: Analysis complete.

[0331] In this embodiment, the arbitration module receives the parsed task and does not distinguish the source of the task, thus performing the same processing on the received tasks and simplifying the system design.

[0332] Figure 19 for Figure 14 The diagram illustrates an exemplary representation of the computational task within a stream processor in the preemption management method. Figure 19 As shown, computation task 0 includes initialization task 0, working subtask 0.1, working subtask 0.2, ..., and working subtask 0.N. Computation task 1 includes initialization task 1, working subtask 1.1, working subtask 1.2, ..., and working subtask 1.N. When the stream processor receives initialization task 0, it executes it. After initialization task 0 is completed, working subtasks 0.1, 0.2, ..., and working subtask 0.N are executed by multiple threads of the stream processor. Computation task 1 is similar to computation task 0 and can refer to the aforementioned lifecycle relationship of computation task 0.

[0333] Next, we will use an example to illustrate the process of preempting the management module 1330 to update the doubly linked list.

[0334] For example, the front-end module issues the following non-preemptive task sequence, including a 0th computation task and a 1st computation task: a 0th initialization task (init_task0) with a task ID (task_id) of 0; a 0.1st working subtask (work_task0_0) with a task ID of 1; a 0.2nd working subtask (work_task0_1) with a task ID of 2; a 1st initialization task (init_task1) with a task ID of 3; a 1.1st working subtask (work_task1_0) with a task ID of 4; and a 1.2nd working subtask (work_task1_1) with a task ID of 5. This task sequence is arbitrated by the arbitration module 1320 and obtains shared data for executing the computation tasks from the resource management module 1350 through the resource request module 1340. The shared data is data shared by all working subtasks of the computation task, while the private data is the source operands for each thread executing the computation task.

[0335] like Figure 20 The diagram shows the storage status of the task sequence in the preemption management module 1330. It is understandable that... Figure 20 The storage state can correspond to Figure 19 At the first moment T1, i.e., before the 0.1 working subtask has been completed, the 0th initialization task is stored in a data structure with position identifier 0. In this data structure, the valid bit is 1, the task identifier is 0, the task type is init, there are no preceding tasks, and there are 3 following tasks. The position identifier of this data structure is stored in the head pointer structure. The 0.1 working subtask is stored in a data structure with position identifier 3. In this data structure, the valid bit is 1, the task identifier is 1, the task type is work, there are 0 preceding tasks, and there are 4 following tasks. For details on the storage status of subsequent tasks, see [link to documentation]. Figure 20 .

[0336] It should be noted that even after the 0th initialization task has been completed, since the work subtasks of that computation task have not yet finished executing, if the computation task is preempted, resuming its execution requires re-executing the 0th initialization task. Therefore, the task information of the 0th initialization task is not removed from the doubly linked list. In other words, if the initialization task has ended but the work tasks following it have not yet finished executing, the initialization task still needs to be redone to ensure that subsequent work subtasks can run normally after restoration. This is to prepare shared data for subsequent work tasks.

[0337] In this embodiment, the preemption management module 603 receives the 0.1st working subtask and the task information indicating that the 0.1st working subtask has been completed. The preemption management module 1330 updates the doubly linked list based on this task information. Figure 21 This shows the storage state of the task sequence after it has been updated in the preemption management module 1330. It can be understood that the time when the 0.1 work subtask completes execution can correspond to... Figure 19 At the second moment T2, that is, the 0.1 subtask has been completed, but the 0.2 subtask has not yet been completed.

[0338] like Figure 21 As shown, the task information for subtask 0.1 is deleted from the data structure at position 3. The backward task in the forward task structure of subtask 0.1 is updated to 4, where the forward task structure stores the task information for initialization task 0, and the backward task 4 points to the data structure at position 4. The forward task in the backward task structure of subtask 0.1 is updated to 0, where the backward task structure stores the task information for subtask 0.2, and the forward task 0 points to the data structure at position 0. In this example, since neither the forward nor backward task storing subtask 0.1 is an initialization task, the head pointer of the head pointer structure is not updated.

[0339] Understandably, if a work task has already finished, it means its calculation results have been written to off-chip memory, so there's no need to start it again. Off-chip memory refers to memory outside the graphics processor.

[0340] It should be noted that if the computation task is preempted at the second time T2, then the miscellaneous data in the task information of the 0.2 working subtask will be updated.

[0341] by Figure 21For example, the process of restoring the computation task can be described as follows: read the oldest entry_index from the oldest_entry_index, which is the data structure with position identifier 0; read the task information from the 0th data structure (entry(0)); parse the task information and transmit it to the arbitration module; according to the backward task in entry(0), read the task information of the 4th data structure (entry(4)); parse the task information and transmit it to the arbitration module; according to the backward task in entry(4), read the task information of the 11th data structure (entry(11)); parse the task information and transmit it to the arbitration module; according to the backward task in entry(11), read the task information of the 8th data structure (entry(8)); parse the task information and transmit it to the arbitration module; according to the backward task in entry(8), read the task information of the 6th data structure (entry(6)); parse the task information and transmit it to the arbitration module; if the backward task of entry(6) is invalid, it means that the parsing is complete.

[0342] In this application embodiment, the need to save the thread's current data varies depending on the circumstances under which a preemption request is received, and may include the following situations:

[0343] If the initialization task of the computation task has not been completed, both the initialization task and the working subtasks of the computation task will be saved.

[0344] If the initialization task of a computation task has been completed, but the working subtasks of the computation task have not been completed, both the initialization task and the working subtasks of the computation task are saved. This is because the working subtasks of the computation task can only be executed after the initialization task has been completed.

[0345] If a computational task has completed subtasks, both the initialization task and the incomplete subtasks need to be saved. This is because the data processing results from the completed subtasks have already been stored in off-chip space, so there is no need to save the subtasks again.

[0346] In this embodiment, the arbitration module 1320 makes a decision in the following way: The arbitration module 1320 includes a configuration register. Driven by software, it sends broadcast information to the front-end module 1310 and the preemption management module 1330 via the configuration register. The broadcast information includes information instructing either the front-end module 1310 or the preemption management module 1330 to issue a task. The front-end module 1310 receives and recognizes the broadcast information. If the broadcast information includes information instructing the front-end module 1310 to issue a task, the front-end module 1310 sends the task to the arbitration module 1320. The preemption management module 1330 receives and recognizes the broadcast information. If the broadcast information includes information instructing the preemption management module 1330 to issue a task, the preemption management module 1330 sends the task to the arbitration module 1320.

[0347] Accordingly, when the preemption management module 1330 sends the task completion message to the arbitration module 1320, it reports the data transmission completion event to the software side. The software side receives the data transmission completion event and schedules the front-end module 1310 to send the task to the arbitration module 1320 through the configuration register.

[0348] In some other embodiments, the arbitration module 1320 may also make a decision in the following way: the arbitration module 1320 includes a configuration register, the software sends driving information to the front-end module 1310, the front-end module 1310 receives the driving information, and if the driving information includes information instructing the front-end module 1310 to issue a task, the front-end module 1310 sends a task to the arbitration module 1320 based on the driving information; if the driving information includes information instructing the preemption management module 1330 to issue a task, the front-end module 1310 sends a driving instruction to the preemption management module 1330 based on the driving information, so that the preemption management module 1330 sends the task information to the arbitration module 1320 based on the driving instruction.

[0349] The communication between the front-end module 1310 and the preemption management module 1330 can be achieved through configuration registers. Accordingly, when the preemption management module 1330 sends a task completion message to the arbitration module 1320, it reports a data transmission completion event to the software side. The software side receives the data transmission completion event and schedules the front-end module 1310 to send the task to the arbitration module 1320 through the configuration registers.

[0350] In step S1410, the arbitration module 1320 transmits the received task to the resource request module 1340. This application embodiment provides a graphics processor, which includes the aforementioned preemption management device.

[0351] In this embodiment of the application, the provided graphics processor has the following characteristics:

[0352] 1) At the task management module level, handle the process of preemption for instruction-level execution.

[0353] 2) In the preemption management module, a method is used to record the order of tasks to be restored using a doubly linked list, including the steps of creating, maintaining, and parsing the linked list.

[0354] 3) Storing the task information to be restored on-chip can reduce the time required to load data from off-chip during the restoration process. Specifically, compared to related technologies where misc_data is stored off-chip, requiring multi-level caching during task restoration and resulting in time delays, this embodiment stores misc_data on-chip, enabling faster decoding and eliminating the time spent searching through each level, thus saving time.

[0355] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0356] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0357] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0358] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

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

[0360] Figure 22 This application provides a hardware entity diagram of a computer device as an embodiment of the present application, such as... Figure 22 As shown, the hardware entity of the computer device 2200 includes a processor 2201 and a memory 2202, wherein the memory 2202 stores a computer program that can run on the processor 2201, and the processor 2201 executes the program to implement the steps in the method of any of the above embodiments.

[0361] The memory 2202 stores computer programs that can run on the processor. The memory 2202 is configured to store instructions and applications that can be executed by the processor 2201. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 2201 and various modules in the computer device 2200. It can be implemented by flash memory or random access memory (RAM).

[0362] The processor 2201 implements the preemptive management method steps described above when executing a program. The processor 2201 typically controls the overall operation of the computer device 2200.

[0363] This application provides a computer storage medium that stores one or more programs, which can be executed by one or more processors to implement the steps of the preemption management method as described in any of the above embodiments.

[0364] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0365] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0366] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

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

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

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

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

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

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

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

Claims

1. A preemptive management method, characterized in that, The preemption management method, applied to a preemption management device located within a graphics processor, includes: Receive computing tasks from the front-end module; The task information of the computing task is stored in the preemption management device; During the execution of the computing task, the stored task information is updated based on the execution status of the computing task to obtain updated task information; the updated task information is located in the preemption management device. If the execution is preempted by other computing tasks and those other computing tasks have completed their execution, the execution of the computing task shall be resumed based on the updated task information; the execution priority of the other computing tasks shall be higher than that of the computing task.

2. The preemption management method according to claim 1, characterized in that, The task information includes execution location information; updating the task information based on the execution status of the computation task to obtain updated task information includes: If the execution status indicates that the computing task has not ended normally, obtain the execution interruption data of the computing task; The execution location information is updated based on the execution interruption data to obtain the updated execution location information.

3. The preemption management method according to claim 2, characterized in that, The computation task includes multiple subtasks, and the execution location information includes the sub-location information of each subtask; The step of obtaining execution interruption data of the computing task when the execution status indicates that the computing task has not ended normally includes: obtaining sub-interruption data of the executing sub-task when the execution status indicates that the executing sub-task among the plurality of sub-tasks has not ended normally; the execution interruption data includes the sub-interruption data. The step of updating the execution location information based on the execution interruption data to obtain the updated execution location information includes: updating the sub-location information of the executing sub-tasks among the plurality of sub-tasks based on the sub-interruption data of the executing sub-tasks to obtain the updated sub-location information corresponding to each of the sub-tasks.

4. The preemption management method according to claim 3, characterized in that, The sub-interrupt data includes the instruction position of the interrupted instruction in the executing subtask; the sub-position information includes the instruction offset information of the subtask; the step of updating the sub-position information of the executing subtask among the plurality of subtasks based on the sub-interrupt data of the executing subtask to obtain the updated sub-position information corresponding to each of the subtasks includes: If the subtask being executed is a working subtask, the instruction offset information is updated based on the position of the instruction that was interrupted in the subtask being executed, to obtain the updated instruction offset information; If the subtask being executed is an initialization task, the instruction offset information is not updated.

5. The preemption management method according to claim 4, characterized in that, When the subtask being executed is a working subtask, the task information further includes storage information of the source operands; the method further includes: The storage information of the source operands is added to the task information to obtain the updated task information; the storage information of the source operands is generated by the stream processor when it stores the source operands in response to the preemption of the executing subtask.

6. The preemption management method according to claim 2, characterized in that, The computation task includes multiple subtasks; the task information includes subtask sequence information, which is used to characterize the relative order among the various subtasks that have not ended normally. The step of updating the task information based on the execution status of the computation task to obtain updated task information includes: If the execution status indicates that the subtask has ended normally, the subtask sequence information is updated based on the normally ended subtask to obtain the updated subtask sequence information.

7. The preemption management method according to claim 2, characterized in that, The step of updating the task information based on the execution status of the computation task to obtain updated task information further includes: If the execution status indicates that the computation task has been completed normally, the task information corresponding to the computation task is deleted.

8. The preemption management method according to any one of claims 1 to 7, characterized in that, The updated task information includes updated execution location information; resuming execution of the computation task based on the updated task information includes: Based on the updated execution location information, the computation task is resumed.

9. The preemption management method according to claim 8, characterized in that, The computation task includes multiple subtasks; the updated execution location information includes updated sub-location information corresponding to each of the subtasks; the step of resuming execution of the computation task based on the updated execution location information includes: Based on the updated sub-location information corresponding to each sub-task, the execution of the corresponding sub-task is resumed.

10. The preemption management method according to claim 9, characterized in that, The sub-location information includes the instruction offset information of the sub-task; the step of resuming execution of the corresponding sub-task based on the updated sub-location information of each sub-task includes: When the subtask is a working subtask, the instruction position of the instruction to be executed in the subtask is determined based on the updated instruction offset information, the corresponding initialization task is executed, and the execution of the subtask is resumed from the instruction to be executed based on the instruction position; If the subtask is an initialization task, the initialization task is resumed based on the unupdated instruction offset information.

11. The preemption management method according to claim 10, characterized in that, The updated task information also includes the storage information of the source operands; Resuming execution of the subtask from the point of the instruction to be executed based on the instruction position includes: The instruction location and the storage information are sent to the stream processor so that the stream processor loads the source operand based on the storage information and resumes execution of the subtask from the execution instruction.

12. The preemption management method according to claim 8, characterized in that, The computation task includes multiple subtasks; the task information includes subtask sequence information, which is used to characterize the relative order among the various subtasks that have not ended normally. The step of resuming the execution of the computation task based on the updated task information includes: Based on the updated relative order among the various subtasks that did not end normally, each of the subtasks that did not end normally is executed sequentially.

13. The preemption management method according to any one of claims 9 to 12, characterized in that, In cases where the execution is preempted by other computing tasks and those other computing tasks have completed their execution, the execution priority of the computing task to be resumed is higher than the execution priority of the new computing task issued by the front-end module.

14. The preemption management method according to any one of claims 9 to 12, characterized in that, The method further includes: In response to resuming the execution of the computation task based on the updated task information, the resumed computation task is marked as non-preemptible.

15. The preemption management method according to any one of claims 1 to 7, characterized in that, The computing task includes multiple subtasks, and the preemption management device is provided with a task linked list including multiple task nodes; storing the task information of the computing task in the preemption management device includes: storing the subtask information of each subtask in the task information in the idle task nodes of the task linked list.

16. The preemption management method according to claim 15, characterized in that, The subtask information includes subtask sequence information, which represents the relative order of the subtask with other subtasks. The task list includes an end node identifier, and each task node includes a node index. The end node identifier stores the node index of the task node where the last subtask is stored in the preemption management device. Storing the subtask information of each subtask in the task information in an idle task node of the task list includes: The node index of the idle task node is stored in the task node of the last subtask as a backward index, which is used to point to the next task node of the task node. The node index of the task node where the last subtask is stored is stored in the idle task node as a forward index, which is used to point to the previous task node of the task node. The node index of the idle task node is used as the end node identifier; wherein, the subtask sequence information includes the end node identifier, the forward index and the backward index of each task node.

17. The preemption management method according to claim 16, characterized in that, The task list further includes a starting node identifier, which is used to store the node index of the task node where the first subtask is stored in the preemption management device; storing the subtask information of each subtask in the task information in an idle task node of the task list further includes: When all task nodes in the task list are idle, the node index of the idle task node is stored in the start node identifier and the end node identifier; the default value is stored in the idle task node as a forward index; the subtask order information also includes the start node identifier.

18. The preemption management method according to claim 17, characterized in that, The subtask information also includes other task information; the method further includes: Store the other task information of the subtask in the idle task node; The other task information includes at least one of the following: the task identifier, task type, and sub-location information of the subtask.

19. The preemption management method according to claim 18, characterized in that, The step of updating the task information based on the execution status of the computation task to obtain updated task information includes: If the execution status characterizes the situation where a subtask in execution has not completed normally, the sub-interruption data of the subtask in execution is obtained. Based on the sub-interruption data of the executing sub-task, update the sub-location information stored in the task node of the executing sub-task.

20. The preemption management method according to claim 18, characterized in that, The step of updating the task information based on the execution status of the computation task to obtain updated task information further includes: If the execution status indicates that the subtask in execution is an initialization task and it ends normally, the subtask sequence information and the sub-position information of the subtask in execution will not be updated. If the execution status indicates that the subtask in progress is a working subtask and has completed normally, the task node of the subtask in progress is deleted from the task chain, and the subtask sequence information is updated.

21. The preemption management method according to claim 20, characterized in that, Updating the subtask order information includes: If the subtask is not the last subtask of the computation task, the node index of the next task node of the subtask is used as the backward index of the previous task node of the subtask, and the node index of the previous task node of the subtask is used as the forward index of the next task node of the subtask. If the subtask is the last subtask in a computation task, update the forward index of the next task node of the last subtask. If the subtask is the last subtask in a computation task, and the previous task node of the last subtask is the task node pointed to by the starting node identifier, then the node index of the next task node of the last subtask is used as the starting node identifier.

22. The preemption management method according to claim 17, characterized in that, The step of resuming the execution of the computation task based on the updated task information includes: Based on the starting node identifier, execute the subtask of the task node pointed to by the starting node identifier to resume the execution of the computation task of the task list; In response to the completion of the subtask of the task node pointed to by the end node identifier, an event is generated indicating that all task nodes in the task list are idle.

23. A preemption management device, characterized in that, The preemption management device includes a receiving unit, a storage unit, an updating unit, and an execution unit, wherein... The receiving unit is used to receive computing tasks issued by the front-end module; The storage unit is used to store the task information of the computing task in the preemption management device; The updating unit is used to update the stored task information based on the execution status of the computing task during the execution of the computing task, so as to obtain the updated task information; the updated task information is located in the preemption management device. The execution unit is configured to resume execution of the computing task based on updated task information when the execution situation includes being preempted by other computing tasks and the other computing tasks have completed execution; the execution priority of the other computing tasks is higher than that of the computing task.

24. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the preemption management method according to any one of claims 1 to 22.

25. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps in the preemption management method according to any one of claims 1 to 22.

26. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the steps in the preemption management method according to any one of claims 1 to 22.

Images