CN117827451A - Task processing method, multi-core graphics processor, electronic device and storage medium - Google Patents

Abstract

The embodiment of the application discloses a task processing method of a multi-core Graphics Processor (GPU), a multi-core graphics processor, electronic equipment and a computer storage medium, wherein the method comprises the following steps: in the process of processing the first task by the GPU, determining a target subtask of the first core from the first task based on the current processing capacity of the first core and the number of the allocated subtasks allocated to each core in the first task; the first core is one of multiple cores; and acquiring and processing the target subtasks through the first core.

Description

Task processing method, multi-core graphics processor, electronic device and storage medium

Technical Field

The present application relates to but is not limited to the field of computer technology, and in particular to a task processing method, a multi-core graphics processor, an electronic device and a storage medium.

Background technique

Large-scale graphics processing units (GPUs) are usually composed of multiple cores. The tasks processed by the GPU can be divided into multiple subtasks and assigned to each core for execution. However, the process of assigning subtasks to each core requires a globally unique scheduling module to execute, which will cause the GPU processing efficiency to be limited by the scheduling efficiency of the scheduling module. Alternatively, this process requires pre-setting the set of subtasks that the core needs to execute. Since each core has a different execution time for its own set of subtasks, the running time of each core varies greatly, resulting in poor GPU processing performance.

Summary of the invention

The embodiments of the present application provide a task processing method, a multi-core graphics processor, an electronic device and a storage medium, which can enable each core to actively acquire subtasks according to its own processing capability, implement subtask scheduling, make the subtasks of multiple cores more balanced, and improve GPU processing performance.

The technical solution of this application is implemented as follows:

The present application embodiment provides a task processing method, including:

During the process of the graphics processor processing the first task, based on checking the number of processable subtasks of the subtask and the number of allocated subtasks in the first task that have been allocated to the core, a target subtask of the core is determined from the first task; and the target subtask is obtained and processed by the core.

The present application embodiment provides a graphics processor, including:

Multiple cores; wherein the core is used to determine the target subtask of the core from the first task based on the number of processable subtasks of the core subtask and the number of allocated subtasks in the first task that have been allocated to the core during the process of the graphics processor processing the first task; obtain the target subtask and process it.

An embodiment of the present application provides an electronic device, comprising the multi-core graphics processor described above.

An embodiment of the present application provides a computer-readable storage medium having executable instructions stored thereon for implementing the above-mentioned task processing method when executed by a processor.

The embodiments of the present application provide a task processing method, a multi-core graphics processor, an electronic device, and a computer storage medium. Since the cores in the GPU can determine and promptly acquire the target subtask in the first task based on the number of subtasks that can be processed for the subtask and the number of allocated subtasks that have been allocated to the cores; in this way, the faster the core processes the subtasks and the more subtasks are completed, the more subtasks can be acquired, thereby reducing the accumulation of subtasks in some cores, improving the balance of load between cores, and thereby improving the task processing performance of the GPU.

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 the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.

FIG1 is a schematic diagram of an optional global scheduling process provided in an embodiment of the present application;

FIG2 is a schematic diagram of an optional autonomous scheduling process in a related technology provided in an embodiment of the present application;

FIG3 is a process diagram 1 of an optional task processing method provided in an embodiment of the present application;

FIG4 is a second process diagram of an optional task processing method provided in an embodiment of the present application;

FIG5 is a schematic diagram of an optional multi-core autonomous scheduling process provided in an embodiment of the present application;

FIG6 is a third process diagram of an optional task processing method provided in an embodiment of the present application;

FIG. 7 is a fourth process diagram of an optional task processing method provided in an embodiment of the present application;

FIG8 is a schematic diagram of the hardware structure of an optional electronic device provided in an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

To facilitate understanding of the present solution, before describing the embodiments of the present application, the application background of the embodiments of the present application is described.

In the related art, subtask scheduling between GPU multi-cores can include global scheduling and autonomous scheduling. Global scheduling requires setting a unified hardware module for subtask scheduling in the GPU, and using this module to assign subtasks to all cores in the GPU. As shown in Figure 1, after the central processing unit (CPU) 2 sends a task to GPU1, the task is stored in the memory 13 of the GPU. The task includes multiple subtasks. The global scheduling module 11 can read the subtasks from the memory 13 and assign the subtasks to multiple cores (cores 12-1, 12-2, 12-3 and 12-4 are shown as examples). Since the number of cores in the GPU far exceeds the number shown in the figure, the global scheduling module 11 may not keep up with the processing capacity of the cores when assigning tasks to multiple cores, resulting in the subtasks of some cores being processed and completed, and the global scheduling module 11 has not yet assigned new subtasks to it, resulting in GPU performance loss. Autonomous scheduling does not have a global scheduling module, and each core in the GPU needs to determine its own subtask set and process it in a pre-agreed manner. As shown in FIG2 , after CPU4 sends a task to GPU3, the task is stored in the memory 33 of the GPU, and the task includes multiple subtasks. Multiple cores in GPU3 (exemplarily showing core 32-1, core 32-2, core 32-3 and core 32-4) can obtain a subtask set from the memory 33 and process the subtasks in the subtask set. It should be noted that there is no dependency between subtasks, and each core can independently process the subtasks in its own subtask set. Here, each core can obtain a subtask set based on the position of the subtask in the vector space, or can obtain a subtask set in combination with the position of the vector space and the subtask identifier; for example, the subtask set of core 32-1 can include subtasks whose subtask identifiers in the upper left position are even numbers. Since the number of subtasks in the subtask set of each core can be different, and the processing time of each subtask can also be different, the time required for each core to complete the processing of the subtasks in the subtask set may also be very different; in this way, the total running time of each core is different, and the gap may be large. The core with the longest running time will become the performance bottleneck of the GPU, affecting the processing performance of the GPU.

In order to solve the above problems, an embodiment of the present application provides a task processing method, which can be executed by a multi-core graphics processor of an electronic device. The electronic device may refer to a server, a laptop, a tablet computer, a desktop computer, a smart TV, a mobile device (such as a mobile phone, a portable video player, a personal digital assistant, a portable gaming device), etc., which has a display function and requires a graphics processor to process tasks. Figure 3 is a process schematic diagram of an optional task processing method provided in an embodiment of the present application. As shown in Figure 3, the method includes: S101-S102.

S101. During the process of GPU processing a first task, based on the current processing capability of the first core and the number of allocated subtasks in the first task that have been allocated to each core, determine a target subtask of the first core from the first task; the first core is one of the multiple cores.

In the embodiment of the present application, when the graphics processor GPU processes the first task, it is achieved by processing the subtasks of the first task through multiple cores of the GPU. The processing capacity of each core for subtasks can be characterized by its own preset maximum number of tasks, that is, the maximum number of tasks that can be processed simultaneously; here, the processing capacity of each core can be the same or different; this can be set as needed, and the embodiment of the present application does not limit it. During the process of each core processing subtasks, subtasks are continuously completed. At this time, the current processing capacity of each core is the number of subtasks that can be processed at present.

In the embodiment of the present application, after the GPU obtains the first task sent by the CPU, each core in the GPU can obtain subtasks from the first task and process them. Among them, the first core can determine its own target subtask from the first task according to its current processing capacity and the number of assigned subtasks, obtain the target subtask and process it; here, the first core is one of the multiple cores.

In the embodiment of the present application, the subtasks acquired in the first core, whether they are tasks being processed or tasks to be processed, are all unfinished tasks of the first core; the number of unfinished tasks should be less than or equal to the maximum number of tasks of the first core. The number of subtasks that can be processed by the first core can be determined based on the maximum number of tasks and the number of unfinished tasks; here, the sum of the number of processable subtasks and the number of unfinished tasks should be less than or equal to the maximum number of tasks.

In some embodiments, the difference between the maximum number of tasks and the number of uncompleted tasks is equal to the number of processable subtasks.

Exemplarily, the multiple cores include 4 cores: core 1 to core 4; wherein the maximum number of tasks of core 1 is 5, and when the number of subtasks in core 1 is 0, the number of unfinished tasks in core 1 is also 0, and at this time, the number of processable subtasks is 5. After core 1 obtains 5 subtasks and starts processing, if 1 subtask is processed, the number of unfinished tasks of core 1 is 4, and at this time, the number of processable subtasks is 1.

In an embodiment of the present application, after the GPU receives the first task sent by the CPU, the first task can be stored in the memory of the GPU; the multiple cores in the GPU need to obtain subtasks from the memory. Here, the subtasks that have been obtained by each core are the allocated subtasks in the first task, and the subtasks that have not yet been allocated to each core are the unallocated subtasks. The electronic device needs to maintain the operating performance of each core so that the number of subtasks in each core can continue to maintain the maximum task volume. Therefore, in the process of the GPU processing the first task, each core needs to obtain and execute subtasks from the unallocated subtasks in a timely manner according to the status of its own processing subtasks.

In an embodiment of the present application, the total number of subtasks of the first task is determined, and the allocation order of all subtasks is determined. The first core can obtain subtasks of the number of processable subtasks from the unallocated subtasks of the first task. In the case where the number of allocated subtasks can be determined, the first core can determine the number of processable subtasks that can be allocated to the core from the unallocated subtasks according to the allocation order.

It should be noted that each subtask has its own task identifier. The task identifier can represent the order in which the subtasks are assigned. In some embodiments, the task identifier can be represented by letters, and the order of assignment can be arranged in the order of letters. In some embodiments, the task identifier can be represented by numbers, and the order of assignment can be arranged according to the size of the numbers.

For example, task A includes M subtasks, and the task identifiers of the subtasks may be: a ₀ -am _-1 ; thus, the subtasks may be allocated in ascending order of the subscripts of the task identifiers. If 3 subtasks have been allocated, and the unallocated subtasks include a ₃ -am _-1 , at this time, if one of the multi-cores needs 2 subtasks, the core needs to obtain a ₃ and a ₄ .

In some embodiments, the task identifier may be a 64-bit integer identifier; in this way, all subtasks may have a globally unique task identifier.

In the embodiment of the present application, the first task acquired by the GPU may be split, that is, the first task acquired by the GPU is a plurality of subtasks, and the first core may read the subtasks one by one as needed. The first task acquired by the GPU may also be unsplit, and the first core may split and read the subtasks as needed; this may be set as needed, and the embodiment of the present application does not limit this.

In some embodiments, multiple subtasks of the first task can be stored in a first-in-first-out queue (FIFO) in the order of allocation, so that the number of processable subtasks arranged at the front in the FIFO is the target subtask, and the first core can obtain the subtask from the first-in-first-out queue according to the number of processable subtasks. In some embodiments, the GPU can record the number of allocated subtasks, and the first core can obtain the number of allocated subtasks, and determine the target subtask from the first task in combination with the number of processable subtasks. In some embodiments, the first core can determine the identifier of the target subtask from the first task based on the number of processable subtasks and the number of allocated subtasks, and then determine the target subtask.

S102: Obtain and process the target subtask through the first core.

In the embodiment of the present application, after determining the target subtask, the first core may obtain the target subtask in the first task and process the target subtask.

In the embodiment of the present application, as long as all subtasks in the first task are not allocated to each core, that is, there are unallocated subtasks in the GPU, the first core can obtain the target subtask from the unallocated subtask when the number of subtasks being processed is less than the maximum task amount. When all subtasks of the first task are allocated and all cores in the GPU have processed the subtasks of the first task, the processing of the first task is completed.

It can be understood that since the first core in the GPU can determine and promptly obtain the target subtask in the first task based on the number of processable subtasks and the number of allocated subtasks that have been allocated to each core; in this way, among the cores in the GPU, the faster the core that processes subtasks, the more subtasks it completes and the more subtasks it can obtain, thereby reducing the possibility of subtasks piling up in some cores, improving the load balance between multiple cores, and thereby improving the GPU's ability to process tasks.

In some embodiments of the present application, the multi-core GPU includes a task counting module, and the number of allocated subtasks of each core is determined by a count value of the task counting module.

In the embodiment of the present application, the multi-core GPU is provided with a task counting module, and the number of allocated subtasks that have been allocated to each core in the first task can be determined by the task counting module. Here, in the process of each core acquiring the subtasks of the first task, the task counting module can conveniently accumulate the number of subtasks acquired by the core, thereby obtaining the number of allocated subtasks, thereby improving the efficiency of determining the number of allocated subtasks.

In some embodiments, the task counting module can be set in the memory of the GPU, so that when each core obtains the subtasks in the first task from the memory, the task counting module can quickly accumulate the count value, thereby improving the efficiency of determining the number of assigned subtasks. In some embodiments, the task counting module can be set in any core, or in other components of the GPU other than the memory and the core; in this regard, it can be set as needed, and the embodiments of the present application are not limited. In some embodiments, the task counting module can be a counter set in the GPU.

In some embodiments of the present application, determining the implementation of the target subtask of the first core from the first task in S101, as shown in FIG. 4 , may include: S201 - S203 .

S201. Send a subtask acquisition instruction to a task counting module through the first core. The subtask acquisition instruction includes the current processing capability of the first core, and the current processing capability is represented by the number of processable subtasks.

In the embodiment of the present application, when the first core needs to obtain a subtask of the first task, it can send a subtask acquisition instruction to the task counting module, and inform the task counting module of the current processing capacity of the first core through the subtask acquisition instruction, so that the task counting module can accumulate the number of assigned subtasks. Here, the current processing capacity of the first core is the number of subtasks that the first core can process; the first core can carry the number of subtasks that can be processed in the task acquisition instruction and send it to the task counting module.

In the embodiment of the present application, when the CPU sends the first task to the GPU, the subtasks are usually not acquired in each core. At this time, the first core needs to acquire the subtask, and can detect the number of processable subtasks of the subtask of the first core at a preset acquisition time interval. When the number of processable subtasks is greater than 0, it is determined that the subtask needs to be acquired; the first core can also determine that the subtask needs to be acquired when it is detected that a subtask in the first core has been processed. This can be set as needed, and the embodiment of the present application does not limit it.

S202: Respond to the task acquisition instruction through the task counting module and send the count value to the first core.

In the embodiment of the present application, the task counting module records the number of assigned subtasks, that is, the count value. After receiving the subtask acquisition instruction, the task counting module responds to the subtask acquisition instruction and can send the count value to the first core.

S203 . Determine, by the first core, a target subtask from unassigned subtasks in the first task according to the count value and the current processing capability.

In an embodiment of the present application, after receiving the count value from the task counting module, the first core can determine the target subtask from the unassigned subtasks based on the count value and the number of processable subtasks, where the number of target subtasks is the number of processable subtasks.

Exemplarily, as shown in FIG5 , after CPU 6 sends a task to GPU 5, the task is stored in GPU memory 53, and the task includes multiple subtasks. Multiple cores in GPU 5 (exemplarily showing core 52-1, core 52-2, core 52-3, and core 52-4) can send a subtask acquisition instruction to task counting module 54, receive the count value returned by task counting module 54, and acquire and process the subtask from memory 53 according to the count value and the number of processable subtasks.

It can be understood that the GPU can record the number of allocated subtasks through the task counting module, and the core can obtain the number of allocated subtasks from the task counting module, and determine the target subtasks that can be allocated to the core among the unallocated tasks based on the number of allocated subtasks; in this way, the accuracy of the core in determining the target subtasks can be improved.

In some embodiments of the present application, after receiving the subtask acquisition instruction and sending the count value to the first core, the task counting module may also increase the count value by the number of processable subtasks to obtain an updated count value.

In the embodiment of the present application, after receiving a task acquisition instruction and obtaining the number of processable subtasks from a core, the task counting module needs to feed back the count value to the core; then, the number of processable subtasks is added to the count value to obtain an updated count value; that is, the first core can obtain the number of processable subtasks, and at the same time, the number of assigned subtasks recorded by the task counting module is increased by the number of processable subtasks. In this way, the count value can be updated in time to improve the accuracy of the count value.

In some embodiments of the present application, the first core may send a subtask acquisition instruction to the task counting module when receiving subtask acquisition indication information from the central processing unit.

In an embodiment of the present application, when the CPU sends the first task to the GPU, it will send subtask acquisition indication information to each core; thus, when the first core receives the subtask acquisition indication information, it determines that it needs to acquire the subtask of the first task and sends the subtask acquisition instruction to the task acquisition module.

In the embodiment of the present application, before the CPU issues the first task, there is no subtask of the first task in each core of the GPU. When the CPU issues the first task and the first core receives the subtask acquisition indication information, the first core can set the number of processable subtasks to the preset maximum number of tasks.

In some embodiments, the CPU sends the first task to the GPU, and the CPU may send subtasks to each core to obtain indication information by broadcasting.

It is understandable that the first core can determine that the CPU sends the first task to the GPU through the subtask acquisition indication information, thereby determining that the number of processable subtasks is the preset maximum number of tasks, and starts to acquire and process the target subtask. In this way, the core can acquire the subtasks of the first task in a timely manner, thereby improving the processing efficiency of the first task.

In some embodiments of the present application, when a first number of subtasks in the first core are processed, a subtask acquisition instruction can be sent to the task counting module through the first core; the number of processable subtasks is the number of the first number of subtasks that have been processed.

In an embodiment of the present application, the first core can process multiple subtasks at the same time, but the processing time of each subtask is different and the processing completion time is different; as long as there are subtasks that have been processed, the resources of the processed subtasks can be freed up to process newly acquired subtasks.

In an embodiment of the present application, the first core can detect the processing status of the subtasks, and when it is determined that the first number of subtasks in the first core has been processed, it is determined that the first core needs to obtain a new subtask, and a subtask acquisition instruction is sent to the task counting module. Here, the first number is less than or equal to the preset maximum number of tasks, and the embodiment of the present application does not limit the value of the first number.

In some embodiments, the first core can detect the subtask processing status in real time, and when detecting that the subtask processing is completed, determine the number of subtasks that have been processed as the first number; then, send a subtask acquisition instruction to the task counting module to start acquiring subtasks. Here, the first number can be one or more, and the first number is less than or equal to the preset maximum number of tasks.

It is understandable that the first core can obtain and process subtasks in a timely manner when subtasks have been processed and there are idle resources to process new subtasks. In this way, the first core can obtain the target subtask in a timely manner, reduce the possibility of idle core resources, and thus improve the processing efficiency of the first task.

In some embodiments of the present application, the first core may send a subtask acquisition instruction to the subtask counting module if the time interval between the last time the task acquisition instruction was sent is greater than or equal to the preset acquisition time interval and the number of processable subtasks is greater than 0; the number of processable subtasks is the number of subtasks processed and completed after the last time the task acquisition instruction was sent.

In an embodiment of the present application, after sending a subtask acquisition instruction, the first core can record the time interval between the subtask acquisition instruction and the subtask acquisition instruction, obtain the number of processable subtasks once at a preset acquisition time interval, and send a subtask acquisition instruction to the subtask counting module based on the number of processable subtasks. The number of processable subtasks is the number of subtasks that have been processed and completed between two subtask acquisition instructions.

In some embodiments, each time the first core sends a subtask acquisition instruction, the timer can be reset to zero. At this time, the time recorded by the timer is the time interval between the last sending of the task acquisition instruction. When the time of the timer is greater than or equal to the preset acquisition time interval, the first core can obtain the number of processable subtasks and send a subtask acquisition instruction to the task counting module based on the number of processable subtasks.

It should be noted that when the time interval between the last time a task acquisition instruction was sent is greater than or equal to the preset acquisition time interval, if the number of processable subtasks is 0, the core can send a subtask acquisition instruction to the task counting module to obtain 0 target subtasks; in this way, after receiving the subtask acquisition instruction, the task counting module can ignore the subtask acquisition instruction.

It can be understood that the core can determine the number of processable subtasks according to a preset acquisition time interval, send a subtask acquisition instruction to the task counting module according to the number of processable subtasks, and obtain the target subtasks of the number of processable subtasks; in this way, the core can obtain the target subtasks in a timely manner, reduce the possibility of idle core resources, and thus improve the processing efficiency of the first task.

In some embodiments of the present application, the first core can determine the number of processable subtasks when the number of processed subtasks is greater than or equal to the preset number of processable subtasks, and send a subtask acquisition instruction to the task counting module based on the number of processable subtasks to start acquiring subtasks. The number of processable subtasks is the number of processed subtasks. The preset number of processable subtasks is less than the preset maximum number of tasks, and the preset number of processable subtasks can be set as needed, which is not limited by the embodiments of the present application. In this way, while achieving load balancing within the core, the frequency of the first core sending subtask acquisition instructions to the task counting module is reduced, thereby reducing the resource consumption of the first core.

In some embodiments of the present application, in S203, based on the count value and the current processing capacity, the implementation of the target subtask is determined from the unassigned subtasks in the first task, as shown in FIG. 6 , which may include: S301 - S302 .

S301: When the count value is less than the total number of subtasks of the first task, determine a target task identifier of a target subtask according to the count value and the number of processable subtasks.

In the embodiment of the present application, the task counting module continuously updates the count value as the subtask acquisition instruction is received, and the count value continuously increases. After receiving the count value fed back by the task counting module, the first core can first determine whether there is an unassigned subtask in the first task according to the count value. In the embodiment of the present application, the first core can compare the count value with the total number of subtasks of the first task; when the count value is less than the total number of subtasks of the first task, it is determined that the number of unassigned subtasks is greater than 0, that is, there are unassigned subtasks in the first task; at this time, the first core can determine the target task identifier from the unassigned subtasks according to the count value and the number of processable subtasks. When the count value is greater than or equal to the total number of subtasks of the first task, the number of unassigned subtasks is equal to 0, that is, there are no unassigned subtasks in the first task; at this time, the first core can determine that the target subtask does not exist. In the case where the target task does not exist, the first core does not need to determine the target subtask identifier and stops acquiring the target subtask. In this way, the first core will only acquire the target subtask when there are still unassigned subtasks in the first task, which can improve the accuracy of the core acquiring the target subtask.

In the embodiment of the present application, the first core can determine the identifier of the next subtask waiting to be assigned according to the count value, and then determine the number of processable subtasks and the identifier of the target subtask, that is, the target task identifier.

In some embodiments of the present application, the subtasks of the first task include task identifiers; the order of the task identifiers is used to characterize the allocation order of the subtasks of the first task; the first core can determine the starting identifier in the target task identifier based on the count value, and obtain the number of task identifiers of processable subtasks in the allocation order as the target task identifier.

In an embodiment of the present application, the subtasks of the first task are provided with task identifiers, and the order of the task identifiers can characterize the order of allocation of the subtasks. In some embodiments, the task identifier can be a number, and the order of allocation of the subtasks is to allocate in order from small to large numbers. In some embodiments, the task identifier can be an even number, and the order of allocation of the subtasks is to allocate in order from small to large even numbers. In some embodiments, the task identifier can be a letter, and the order of allocation of the subtasks is to allocate in order from first to last in the order of arrangement of the letters; this can be set as needed, and the embodiment of the present application does not limit it.

In the embodiment of the present application, after obtaining the count value, the first core can determine the starting identifier in the target task identifier, and sequentially obtain the identifiers of the number of processable subtasks in the allocation order as the target task identifier.

Exemplarily, task A includes M subtasks, which are a ₀ -a _M-1 respectively. When N subtasks have been allocated, the unallocated subtasks include a _N -a _M-1 , where N is a positive integer less than M-1. The first core sends a subtask acquisition instruction to the counter, and when the number of processable subtasks is 2, the counter updates the count value from N to N+2, and feeds N back to the first core. The first core can determine that the identifier of the first subtask of the target subtask is a _N , and the identifier of the next subtask is a _N+1 , so that the target task identifiers include: a _N and a _N+1 .

It can be understood that since the task identifier can represent the allocation order of subtasks, the first core can determine the starting identifier of the target subtask based on the count value, and then determine the target task identifier based on the number of processable subtasks, which can improve the efficiency of determining the identifier of the target subtask.

S302: Determine the subtask corresponding to the target task identifier among the unassigned subtasks as the target subtask.

In the embodiment of the present application, after determining the target task identifier, the first core may obtain a subtask with the same task identifier as the target task identifier from unassigned subtasks, which is the target subtask.

It is understandable that the first core may first determine the target task identifier, and then obtain the target subtask according to the target task identifier, thereby improving the accuracy of obtaining the target subtask.

In some embodiments of the present application, when a task counting module receives multiple task acquisition instructions from multiple cores, it sorts them according to the number of processable subtasks in the task acquisition instructions to obtain a response order; and responds to the task acquisition instructions in sequence according to the response order.

In an embodiment of the present application, multiple cores in a GPU may simultaneously send subtask acquisition instructions to a task counting module. At this time, the task counting module may obtain the number of processable subtasks of each core, sort the number of processable subtasks of each core by size, and obtain a response order. Then, according to the response order, respond to the subtask acquisition instruction one by one. Here, the response order may be the order of the number of processable subtasks from small to large, or the order of the number of processable subtasks from large to small. This may be set as needed, and the embodiment of the present application does not limit it.

It can be understood that the task counting module can only respond to one subtask acquisition instruction at a time. When multiple subtask acquisition instructions are received at the same time, the response order is determined according to the number of processable subtasks, thereby reducing response errors and improving the accuracy of the core acquiring the target subtask, thereby improving the performance of processing tasks.

In some embodiments, the task counting module may respond to multiple cores in order of the number of processable subtasks from small to large. That is, the task counting module may first respond to the core with a small number of processable subtasks, so that the core with a small number of processable subtasks can first obtain a small number of target subtasks, reducing the probability that a single core obtains a large number of subtasks while other cores have no subtasks to obtain, thereby improving the load balancing of the cores.

In some embodiments of the present application, the implementation of obtaining and processing the target subtask in S102 may include: feeding back idle information to the central processing unit through the first core when all subtasks of the first core are processed.

In an embodiment of the present application, during the process of processing subtasks, the first core will promptly obtain unassigned subtasks in the first task for processing until all subtasks of the first task are assigned; the first core will not be able to obtain new subtasks until all subtasks are processed. If the first core has no subtasks to process, it can feedback idle information to the CPU.

In an embodiment of the present application, all cores in the GPU feed back idle information to the CPU, indicating that the GPU has completed processing the first task and is in an idle state; that is, the first core can inform the CPU of its own processing status by feeding back idle information, and then inform the CPU of the processing status of the GPU; in this way, the CPU can continue to issue the next task when the GPU is idle, thereby improving the efficiency of the CPU in issuing tasks.

In some embodiments of the present application, in S101, during the process of the GPU processing the first task, based on the current processing capability of the first core and the number of allocated subtasks allocated to each core in the first task, the implementation of the target subtask of the first core is determined from the first task, and it may also include: receiving the first task issued from the central processing unit; the first task includes the total number of subtasks in the first task.

In the embodiment of the present application, the GPU receives the first task sent by the CPU, which includes the total number of subtasks of the first task. In this way, the GPU can determine the total number of subtasks of the first task while receiving the first task, and the first core can determine whether there are any unassigned subtasks of the first task according to the total number of subtasks and the count value, so as to stop acquiring the target subtask in time when the first task is assigned, which can reduce the resource consumption of the core.

In some embodiments of the present application, in S101, during the process of the GPU processing the first task, based on the current processing capability of the first core and the number of allocated subtasks allocated to each core in the first task, determining the implementation of the target subtask of the first core from the first task may include: clearing the count value in response to a clear instruction from the central processing unit through a task counting module.

In the embodiment of the present application, the GPU may receive a reset instruction from the CPU, the reset instruction being used to instruct the GPU to reset the count value of the task counting module. The GPU responds to the reset instruction and resets the count value of the task counting module, so that the count value is updated to 0.

In some embodiments, the clear instruction and the first task may be received at the same time, and the GPU receives the clear instruction at the same time as receiving the first task. Then, in response to the clear instruction, the count value is cleared. In some embodiments, the clear instruction may be received after or before the first task; in some embodiments, the clear instruction may also be the first task issued; this may be set as needed, and the embodiments of the present application do not limit this.

It is understandable that the GPU needs to clear the count value every time it receives a first task. In this way, the count value of the task counting module is the count value of the number of tasks assigned to the first task, which can improve the accuracy of the count value.

Based on the above task processing method, the embodiment of the present application shows a process of a task processing method; as shown in FIG7 , the method may include:

S11, the CPU sends a first task and a clear instruction to the GPU, and sends a broadcast subtask acquisition instruction information to each core in the GPU; wherein the first task includes the total number of subtasks;

S12, the GPU responds to the reset instruction through the task counting module and resets the count value to zero;

S13, the GPU responds to the subtask acquisition indication information through the first core, and sends a subtask acquisition instruction to the task counting module; the number of processable subtasks carried in the subtask acquisition instruction is the preset maximum number of tasks;

S14, the GPU responds to the subtask acquisition instruction through the task counting module, sends the count value to the first core, and increases the count value by the number of processable subtasks to obtain an updated count value;

S15, the GPU determines whether the count value is less than the total number of subtasks through the first core; if yes, execute S16; otherwise, execute S19;

S16, the GPU determines the target task identifier through the first core according to the count value and the number of processable subtasks;

S17, the GPU obtains, through the first core, a subtask with a task identifier identical to the target task identifier from the unassigned subtasks as the target subtask;

S18, the GPU determines whether a subtask in the core has been processed through the first core; if yes, execute S14; otherwise, continue to execute S18;

S19. The GPU sends idle information to the CPU through the first core after completing processing of all subtasks of the first core.

In the embodiment of the present application, after receiving the idle information of all cores, the CPU can determine that the first task processing is completed and can send the next task to the GPU.

An embodiment of the present application provides a multi-core graphics processor (GPU), wherein a first core is used to determine a target subtask of the first core from the first task based on a current processing capability of the first core and the number of allocated subtasks in the first task that have been allocated to each core during processing of a first task by the GPU; the first core is one of the multiple cores; and the first core is further used to obtain and process the target subtask.

In some embodiments, the GPU further includes a task counting module, which is used to determine a count value; the count value is used to characterize the number of allocated subtasks of each core.

In some embodiments, the first core is further used to send a subtask acquisition instruction to the task counting module; the subtask acquisition instruction includes the current processing capability of the first core, and the current processing capability is represented by the number of processable subtasks; the task counting module is further used to respond to the subtask acquisition instruction and send the count value to the first core; the first core is further used to determine the target subtask from the unallocated subtasks in the first task based on the count value and the current processing capability.

In some embodiments, the task counting module is further used to increase the count value by the number of processable subtasks to obtain an updated count value.

In some embodiments, the first core is further configured to send the subtask acquisition instruction to the task counting module upon receiving subtask acquisition indication information from the central processing unit.

In some embodiments, the first core is further used to send the subtask acquisition instruction to the task counting module when a first number of subtasks in the first core are processed; the number of processable subtasks is the number of the first number of subtasks that have been processed.

In some embodiments, the first core is also used to send the subtask acquisition instruction to the task counting module when the time interval between the last sending of the subtask acquisition instruction is greater than or equal to the preset acquisition time interval and the number of processable subtasks is greater than 0; the number of processable subtasks is the number of subtasks processed and completed after the last sending of the task acquisition instruction.

In some embodiments, the first core is further used to determine the target task identifier of the target subtask based on the count value and the number of processable subtasks when the count value is less than the total number of subtasks of the first task; and determine the subtask corresponding to the target task identifier in the unassigned subtasks as the target subtask.

In some embodiments, the subtasks of the first task include task identifiers; the order of the task identifiers is used to characterize the allocation order of the subtasks of the first task; the first core is also used to determine the starting identifier in the target task identifier according to the count value, and obtain the number of task identifiers of the processable subtasks in turn according to the allocation order as the target task identifier.

In some embodiments, the first core is further configured to determine that the number of unallocated subtasks is 0 and the target subtask does not exist when the count value is greater than or equal to the total number of subtasks of the first task.

In some embodiments, the task counting module is also used to, when receiving multiple subtask acquisition instructions from multiple cores, sort them according to the number of processable subtasks in the subtask acquisition instructions to obtain a response order; and respond to the subtask acquisition instructions in sequence according to the response order.

In some embodiments, the first core is further configured to feed back idle information to the central processing unit when all subtasks of the first core are processed.

In some embodiments, the task counting module is further configured to respond to a clear instruction from the central processing unit to clear the count value.

In some embodiments, the task counting module is located in the memory of the GPU

It should be noted that, in the embodiment of the present application, the above-mentioned task processing method can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to enable a graphics processor of an electronic device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific hardware, software or firmware, or any combination of hardware, software, and firmware.

The embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, some or all of the steps in the above method are implemented. The computer-readable storage medium can be transient or non-transient.

An embodiment of the present application provides a computer program, including a computer-readable code. When the computer-readable code is executed in an electronic device, a graphics processor in the electronic device executes some or all of the steps for implementing the above method.

The embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented specifically by hardware, software or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

It should be noted here that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. The description of the above device, storage medium, computer program and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. 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 description of the method embodiment of this application for understanding.

The present application also provides a structure of an electronic device, as shown in FIG8 , where the electronic device 700 includes a processor 701, a communication interface 702, and a memory 703; wherein the processor 701 includes a central processing unit 7011 and a multi-core graphics processor 7012.

The central processing unit 7011 is used to send the first task to the multi-core graphics processor 7012.

The multi-core graphics processor 7012 is used to execute the above task processing method.

The communication interface 702 enables the electronic device to communicate with other terminals or servers through a network.

The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or processed by the processor 701 and each module in the electronic device 700 (for example, image data, audio data, voice communication data, and video communication data), which can be implemented by flash memory (FLASH) or random access memory (Random Access Memory, RAM). Data transmission can be performed between the processor 701, the communication interface 702, and the memory 703 through the bus 704.

It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step/process mentioned above does not mean the order of execution, and 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 embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

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

The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

A person of ordinary skill in the art can understand that: all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, read-only memories (ROM), magnetic disks or optical disks.

Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function 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 present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims (19)

1. A task processing method for a multi-core graphics processor GPU, characterized by comprising: In a process of the GPU processing a first task, based on a current processing capability of the first core and a number of allocated subtasks in the first task that have been allocated to each core, determining a target subtask of the first core from the first task; the first core is one of the multiple cores; The target subtask is obtained and processed through the first core. 2. The method according to claim 1 is characterized in that the multi-core GPU includes a task counting module, and the number of allocated subtasks of each core is determined by a count value of the task counting module. 3. The method according to claim 2, wherein determining the target subtask of the first core from the first task comprises: Sending a subtask acquisition instruction to a task counting module through the first core; the subtask acquisition instruction includes a current processing capability of the first core, and the current processing capability is represented by the number of subtasks that can be processed; Responding to the subtask acquisition instruction through the task counting module, sending the count value to the first core; The target subtask is determined from unassigned subtasks in the first task according to the count value and the current processing capability by the first core. 4 . The method according to claim 3 , further comprising: increasing the count value by the number of processable subtasks through the task counting module to obtain an updated count value. 5. The method according to claim 3, characterized in that the sending of the subtask acquisition instruction to the task counting module comprises: When receiving the subtask acquisition instruction information from the central processing unit, the subtask acquisition instruction is sent to the task counting module. 6. The method according to claim 3, characterized in that the sending of the subtask acquisition instruction to the task counting module comprises: When a first number of subtasks in the first core are processed, the subtask acquisition instruction is sent to the task counting module; the number of processable subtasks is the number of the first number of subtasks that have been processed. 7. The method according to claim 3, characterized in that the sending of the subtask acquisition instruction to the task counting module comprises: When the time interval between the last sending of the subtask acquisition instruction is greater than or equal to the preset acquisition time interval, and the number of processable subtasks is greater than 0, the subtask acquisition instruction is sent to the task counting module; the number of processable subtasks is the number of subtasks processed and completed after the last sending of the task acquisition instruction. 8. The method according to claim 3, characterized in that the step of determining the target subtask from unassigned subtasks in the first task according to the count value and the current processing capacity comprises: In a case where the count value is less than the total number of subtasks of the first task, determining a target task identifier of the target subtask according to the count value and the number of processable subtasks; A subtask among the unassigned subtasks corresponding to the target task identifier is determined as the target subtask. 9. The method according to claim 8, characterized in that the subtasks of the first task include task identifiers; the order of the task identifiers is used to characterize the order of allocation of the subtasks of the first task; and the determining of the target task identifier of the target subtask according to the count value and the number of processable subtasks comprises: The starting identifier in the target task identifier is determined according to the count value, and the task identifiers of the number of processable subtasks are acquired in sequence according to the allocation order as the target task identifier. 10. The method according to claim 3, characterized in that the step of determining the target subtask from unassigned subtasks in the first task according to the count value and the current processing capacity comprises: When the count value is greater than or equal to the total number of subtasks of the first task, it is determined that the number of unassigned subtasks is 0 and the target subtask does not exist. 11. The method according to claim 3, characterized in that the method further comprises: When receiving multiple subtask acquisition instructions from multiple cores, the task counting module sorts the subtask acquisition instructions according to the number of processable subtasks in the subtask acquisition instructions to obtain a response order; and responds to the subtask acquisition instructions in sequence according to the response order. 12. The method according to any one of claims 1 to 11, characterized in that the method further comprises: Through the first core, when all subtasks of the first core are processed completely, idle information is fed back to the central processing unit. 13. The method according to any one of claims 1 to 11, characterized in that the method further comprises: The first task is received from a central processing unit; the first task includes the total number of subtasks of the first task. 14. The method according to claim 13, characterized in that the method further comprises: The task counting module responds to a clear instruction from the central processing unit to clear the count value. 15. The method according to claim 9, characterized in that the task identifier is represented by a 64-bit integer. 16. The method according to claim 2, characterized in that the task counting module is located in the memory of the GPU. 17. A multi-core graphics processor GPU, comprising: a first core, configured to determine, during processing of a first task by the GPU, a target subtask of the first core from the first task based on a current processing capability of the first core and a number of allocated subtasks in the first task that have been allocated to each core; the first core being one of the multiple cores; The first core is further configured to obtain and process the target subtask. 18. An electronic device, comprising: a multi-core graphics processor GPU as claimed in claim 17. 19. A computer storage medium, characterized in that executable instructions are stored thereon, and are used to implement the task processing method according to any one of claims 1 to 16 when executed by a graphics processor.