GPU task scheduling method and device and computer readable storage medium
By sorting and scheduling task requests based on execution time limits in the vehicle system, the most urgent tasks are given priority access to GPU resources, which solves the resource conflict problem caused by multi-task contention and improves the user experience.
Patent Information
- Application Number
- CN202511012926.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-22
- Publication Date
- 2025-11-07
AI Technical Summary
In vehicle infotainment systems, when multiple application processes use GPU resources simultaneously, resource contention occurs, leading to frame drops, stuttering, and other issues that negatively impact user experience.
When a task request is received, the execution time limit of the task request is determined, and the task request is added to the sorted task queue based on the execution time limit. In response to the task submission instruction, the first task request in the task queue is submitted to the GPU for execution, ensuring that the most urgent task gets resources first and avoiding multiple tasks competing for resources at the same time.
It reduces task latency, avoids frame drops and stuttering, and improves the user experience.
Smart Images
Figure CN120909720A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Embodiments of the present application relate to the field of car machine technology, and particularly relate to a GPU task scheduling method and device and a computer readable storage medium. BACKGROUND
[0002] A graphics processing unit (GPU) is a key component in a car machine system, and is responsible for functions such as interface rendering, dynamic UI drawing, and high-definition multimedia content playing.
[0003] When multiple application processes are running simultaneously in the car machine system, the multiple application processes can simultaneously require the use of GPU resources, resulting in GPU resource competition, and phenomena such as frame loss and lag, which affect the user experience. SUMMARY
[0004] In view of the above problems, embodiments of the present application provide a GPU task scheduling method, device and computer readable storage medium, to solve the problem of GPU resource competition in the prior art.
[0005] According to an aspect of an embodiment of the present application, a GPU task scheduling method is provided, and the method comprises:
[0006] Upon receiving a task request, determining an execution time limit of the received task request;
[0007] Based on the execution time limit of the task request, adding the task request to a task queue; wherein the task requests in the task queue are sorted in ascending order according to the values of the execution time limit;
[0008] In response to a task submission instruction, submitting a first task request in the task queue to the GPU for execution; wherein the GPU executes the task requests corresponding to each task submission instruction in sequence.
[0009] According to another aspect of an embodiment of the present application, a GPU task scheduling device is provided, comprising:
[0010] A determination module is configured to, upon receiving a task request, determine an execution time limit of the received task request;
[0011] An adding module is configured to, based on the execution time limit of the task request, add the task request to a task queue; wherein the task requests in the task queue are sorted in ascending order according to the values of the execution time limit;
[0012] A submission module is configured to, in response to a task submission instruction, submit a first task request in the task queue to the GPU for execution; wherein the GPU executes the task requests corresponding to each task submission instruction in sequence.
[0013] According to another aspect of the embodiments of the present application, an electronic device is provided, comprising: a processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete communication with each other through the communication bus;
[0014] The memory is configured to store at least one executable instruction, and the executable instruction causes the processor to perform the operations of the GPU task scheduling method.
[0015] According to still another aspect of the embodiments of the present application, a car machine is provided, comprising: an electronic device and a GPU; the electronic device and the GPU are communicatively connected; and the electronic device performs the following operations:
[0016] Upon receiving a task request, determining an execution time limit of the received task request;
[0017] Based on the execution time limit of the task request, adding the task request to a task queue; wherein the task requests in the task queue are sorted in ascending order according to the values of the execution time limit;
[0018] In response to a task submission instruction, submitting a first task request in the task queue to the GPU for execution; wherein the GPU executes the task requests corresponding to each task submission instruction in sequence.
[0019] According to still another aspect of the embodiments of the present application, a computer readable storage medium is provided, the storage medium stores at least one executable instruction, and the executable instruction causes the electronic device / GPU task scheduling device to perform the following operations:
[0020] Upon receiving a task request, determining an execution time limit of the received task request;
[0021] Based on the execution time limit of the task request, adding the task request to a task queue; wherein the task requests in the task queue are sorted in ascending order according to the values of the execution time limit;
[0022] In response to a task submission instruction, submitting a first task request in the task queue to the GPU for execution; wherein the GPU executes the task requests corresponding to each task submission instruction in sequence.
[0023] The embodiment of the application can determine the execution time limit of the task request when the task request is received, and then add the received task request to the sorted task queue based on the execution time limit, and in response to the task submission instruction, submit the first task request in the task queue to the GPU for execution, and then the GPU can execute the task request corresponding to each task submission instruction in turn, can quantify the urgency of the task request by the execution time limit, and sort the task request based on the execution time limit, ensure that the most urgent task obtains the GPU resource first, and reduce the delay of the task; and the GPU processes only one task at the same time, converts the parallel request into an ordered serial execution through the queue mechanism, avoids frame loss and lag caused by multiple tasks simultaneously occupying resources, and improves user experience.
[0024] The above description is only a summary of the technical solutions of the embodiments of the application, in order to more clearly understand the technical means of the embodiments of the application, the content of the specification can be implemented, and in order to make the above and other purposes, characteristics and advantages of the embodiments of the application more obvious and easy to understand, the specific embodiments of the application are described below. BRIEF DESCRIPTION OF DRAWINGS
[0025] The drawings are only used to show the embodiments and are not considered as limitations of the application. Moreover, the same reference signs are used to represent the same parts throughout the drawings. In the drawings:
[0026] Figure 1 A schematic diagram of an application scenario provided by the application is shown;
[0027] Figure 2 A flowchart of a first embodiment of the GPU task scheduling method provided by the application is shown;
[0028] Figure 3 A division diagram of a GPU usage interval provided by the application is shown;
[0029] Figure 4 A flowchart of a second embodiment of the GPU task scheduling method provided by the application is shown;
[0030] Figure 5 A schematic diagram of another application scenario provided by the application is shown;
[0031] Figure 6 A structural diagram of a first embodiment of the GPU task scheduling device provided by the application is shown;
[0032] Figure 7 A structural diagram of an embodiment of the electronic device provided by the application is shown. DETAILED DESCRIPTION
[0033] Exemplary embodiments of the present application will be described in greater detail below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it is understood that the present application can be embodied in various forms and should not be limited by the embodiments set forth herein.
[0034] In the related art, when multiple application processes request resources from the GPU within the same time period, due to the physical upper limit of the hardware computing power of the GPU, the GPU cannot simultaneously process multiple tasks exceeding its carrying capacity in parallel, and the calling demands of different application processes on the GPU are different, resulting in competition for GPU resources. In this case, it may occur that the GPU cannot complete task processing within the specified time window due to being preempted by other tasks, and thus phenomena such as screen freezing, map dragging delay, etc. may occur; or even, multiple task concurrency may cause the instantaneous peak value of the GPU load to exceed the threshold, triggering the hardware protection mechanism, causing the application to crash or the system to be temporarily unresponsive. However, for users, such phenomena not only destroy the smoothness of operation, but also may cause safety hazards in driving scenarios, therefore, how to resolve the resource competition of multiple tasks through a reasonable GPU task scheduling mechanism has become a key to guarantee the stability of the car machine system and the user experience.
[0035] Therefore, the embodiment of the present application provides a GPU task scheduling method, quantifies the urgency of the task request, sorts the task requests based on the urgency of the task request, submits the task with the highest urgency to the GPU for execution, and controls the GPU to perform the task exclusively, thereby avoiding the frame loss and freezing phenomenon caused by resource competition due to parallel processing, and improving the user experience.
[0036] The execution subject of the embodiment of the present application can be a scheduling controller, which can be a controller independent of the GPU, for example, a central processing unit (CPU), a microcontroller unit (MCU), etc., or a controller provided in the GPU, which is not limited in the embodiment of the present application.
[0037] Figure 1 A schematic diagram of an application scenario provided by the present application is shown, and the scheduling controller can include a framework layer, a policy layer, a task queue, and a scheduling layer.
[0038] The framework layer is used to register each new task, including registering at least one task parameter such as the client identifier of the task, the task type, the time consumption per frame, and the frame loss type. After the task is registered, a task identifier is generated, and the task identifier is returned to the client, establishing a mapping relationship between the task identifier and the task parameter.
[0039] A policy layer is configured to calculate an execution deadline for each task request based on a task parameter, and add the task request into a task queue based on the execution deadline.
[0040] A task queue is configured to cache the task requests in sequence.
[0041] A scheduling layer is configured to monitor a task submission instruction, obtain a first task request from the task queue, and submit the task request to a GPU for execution.
[0042] Figure 2 A flowchart of a first embodiment of a GPU task scheduling method provided by the application is shown in FIG. 1. Figure 2 As shown in FIG. 1, the method comprises the following steps:
[0043] Step 110: Upon receiving a task request, determine an execution deadline of the received task request.
[0044] By way of example, the task request represents a task submitted by an application (a client) to the scheduling controller, which needs to be calculated or rendered by the GPU, such as rendering a frame, performing AI inference, etc. The execution deadline represents a time interval from the current time to the deadline of the task request, which is used to quantify the urgency of the task. The deadline represents the latest time for executing the task request, and if the task request is executed after the deadline, the task may have a frame loss phenomenon.
[0045] In one example, the task request carries a task parameter, which includes the deadline. Therefore, the scheduling controller can obtain the deadline by analyzing the task request after receiving the task request, and then calculate the time interval between the deadline and the current time to obtain the execution deadline.
[0046] In another example, the task request carries a task parameter, which includes the per-frame time consumption, i.e., the maximum time consumption for executing the task request. Therefore, the scheduling controller can obtain the per-frame time consumption by analyzing the task request after receiving the task request, and then take the sum of the receiving time of the task request and the per-frame time consumption as the deadline, and then calculate the time interval between the deadline and the current time to obtain the execution deadline.
[0047] In another example, the task request carries a task identifier, such as a task ID, and the scheduling controller is preconfigured with a mapping relationship between the task identifier and the task parameter. Therefore, the scheduling controller can obtain the task identifier by analyzing the task request after receiving the task request, determine the task parameter based on the task identifier, and then calculate the execution deadline by the method in the foregoing example.
[0048] Step 120: Based on the execution deadline of the task request, add the task request into a task queue.
[0049] Exemplarily, the task queue refers to an ordered list storing task requests to be executed, and the task requests in the task queue are sorted in ascending order according to the execution time limit.
[0050] In one example, the scheduling controller can traverse each task request in the task queue, find a position where the first execution time limit is greater than the execution time limit of the received task request, and add the received task request to the position to add the task request to the task queue, and can ensure that the task requests in the task queue are sorted in ascending order according to the execution time limit.
[0051] Step 130: In response to the task submission instruction, the first task request in the task queue is submitted to the GPU for execution.
[0052] Exemplarily, the task submission instruction represents a signal for submitting a task request from the queue to the GPU. The GPU executes each task request corresponding to the task submission instruction in turn, in other words, the GPU executes only one task at the same time, and processes the request in serial according to the submission order, that is, exclusive execution.
[0053] Optionally, the task submission instruction can be an instruction triggered by the arrival of a timing period, or an instruction triggered after the GPU finishes executing the previous task request.
[0054] Exemplarily, Figure 3 A division diagram of a GPU usage interval provided by the present application is shown, as shown in Figure 3 Taking the screen refresh rate of the car machine as 60 Hz as an example, that is, the screen will update 60 images per second, and then the GPU can be divided into 60 usage intervals in a period of 1 second, that is, each usage interval is 16.6 milliseconds, and each usage interval corresponds to a screen refresh. It should be noted that, Figure 3 Taking 2 usage intervals as an example.
[0055] Referring to Figure 3 The timing period can be the time point at the end or beginning of each usage interval, that is, Figure 3 As shown by the dashed line, the task submission instruction will be triggered when each timing period arrives. It can also be an instruction triggered after each task request is executed.
[0056] In one example, in response to the triggered task submission instruction in the timing period, the scheduling controller can submit the first task request in the task queue to the GPU for execution, regardless of whether the task being executed by the GPU at the moment is completed or not, if not, the task can be suspended and re-joined in the task queue, waiting for the next execution. Alternatively, in each usage interval, in response to the task submission instruction triggered after the GPU finishes executing the previous task request, the scheduling controller can submit the first task request in the task queue to the GPU for execution. In this implementation, in each usage interval, as shown in FIG. 13, the GPU can execute a plurality of task requests in sequence, and each task request is executed in an exclusive manner, which can maximize the utilization of GPU resources to complete the task request and avoid resource competition caused by simultaneous execution of multiple tasks. Figure 3
[0057] In this embodiment, when the scheduling controller receives a task request, it can determine the execution time limit of the task request, and then add the received task request to the sorted task queue based on the execution time limit, and in response to the task submission instruction, submit the first task request in the task queue to the GPU for execution, and then the GPU can execute the task request corresponding to each task submission instruction in sequence. In this way, the urgency of the task request can be quantified by the execution time limit, and the task request can be sorted based on the execution time limit to ensure that the most urgent task obtains GPU resources first and reduces the delay of the task. Moreover, the GPU only processes one task at a time, and the queue mechanism is used to convert parallel requests into ordered serial execution, avoiding frame loss and lag caused by multiple tasks simultaneously occupying resources, and improving user experience.
[0058] Figure 4 FIG. 13 shows a flowchart of a second embodiment of the GPU task scheduling method provided by the present application, Figure 5 FIG. 14 shows a schematic diagram of another application scenario provided by the present application, as shown in Figure 4 and Figure 5 The method comprises the following steps:
[0059] Step 210: When receiving a task request, determining the task parameters corresponding to the task request according to the task identifier carried in the task request.
[0060] For example, as described above, the framework layer can register each new task to obtain a task identifier and establish a mapping relationship between the task identifier and the task parameters. Therefore, the scheduling controller can analyze the received task request to obtain the task identifier carried in the task request, and determine the task parameters corresponding to the task request based on the pre-established mapping relationship between the task identifier and the task parameters. The task identifier is used to uniquely represent the task request.
[0061] Optionally, the task parameter comprises one or more of the following: a task type, a per-frame time consumption, and a frame loss type; wherein the task type can be a real-time periodic task (such as picture display and video playing), a single real-time task (such as real-time image processing), and a single non-real-time task (such as image processing with low real-time requirement and AI computing), and the task type corresponds to a task priority, that is, the priority of the real-time periodic task is higher than that of the single real-time task, the priority of the single real-time task is higher than that of the single non-real-time task, and it should be noted that the types of the task type are not limited in the embodiments of the present application.
[0062] The per-frame time consumption represents a maximum time length required for completing the task request, and the per-frame time consumption is determined by a frame rate of the task; for example, if the frame rate of the task is 30 frames per second, the per-frame time consumption is 33.3 milliseconds, and if the frame rate of the task is 60 frames per second, the per-frame time consumption is 16.6 milliseconds. The frame loss type can be loss allowed or loss not allowed; for example, if the frame loss type is loss allowed, the task request of the next frame can be actively discarded in the case of GPU processing timeout.
[0063] Step 220: determining an execution time limit of the task request according to the task parameter.
[0064] In some possible implementation manners, the task parameter comprises the per-frame time consumption, the task request has a receiving time, and then a sum of the receiving time and the per-frame time consumption can be determined as a deadline of the task request; and an execution time limit of the task request is determined according to the deadline and a current time.
[0065] Specifically, a difference between the deadline and the current time can be determined as the execution time limit of the task request.
[0066] Alternatively, a predicted value of GPU time consumption of the task request can be obtained first; and a difference between the deadline and the current time is subtracted by the predicted value of the GPU time consumption, and a result obtained is taken as the execution time limit of the task request.
[0067] Exemplarily, the scheduling controller further comprises a computing power tracking layer, which can obtain the GPU usage duration, i.e., GPU time consumption, of each task request as historical data after the task request is completed, and predict the predicted value of the GPU time consumption of the task request based on the historical data by using a regression algorithm. For example, the regression algorithm can be a decision tree algorithm, a neural network algorithm, etc., which is not limited in the embodiments of the present application. Then, the scheduling controller can calculate the execution time limit of the task request according to the formula execution time limit = deadline - current time - predicted value of GPU time consumption. In this way, the time consumption of the task itself can be considered when determining the execution time limit, so that a more accurate execution time limit can be calculated, and the timeout caused by submitting the GPU execution too late to complete the task request before the deadline can be avoided. In other words, the scheduling controller can not only pay attention to the time interval of the task request from the deadline, but also pay attention to how long the execution needs to be started to catch up with the deadline, so as to ensure that the task can be completed on time, reduce the lag and frame loss caused by the misjudgment of the starting time, and improve the user experience.
[0068] Step 230: based on the execution time limit of the task request, the task request is added to the task queue.
[0069] It should be noted that this step is similar to the foregoing step S120, which will not be described here.
[0070] In some possible implementations, in the process of adding the task request to the task queue, if there is a task request with the same execution time limit in the task queue, i.e., there is a task request with the same execution time limit as the received task request in the task queue, then the task type in the task parameters of the task request is determined, and the task requests with the same execution time limit are sorted and added to the task queue based on the priority corresponding to the task type.
[0071] Exemplarily, the task parameters can include a task type, as shown in Figure 5 As shown in the figure, the task request 1 is the received task request, and the task request 2 already exists in the task queue, and the execution time limit of the task request 2 is the same as that of the task request 1. At this time, the task type in the task parameters of the task request 1 and the task type in the task parameters of the task request 2 can be determined respectively. As mentioned before, the task type corresponds to the priority, and then the task request 1 and the task request 2 can be sorted based on the priority and added to the task queue. For example, if the priority of the task request 2 is higher than that of the task request 1, the task request 1 is added to the position behind the task request 2.
[0072] In this way, when the execution time limit is the same, the high-priority task can be guaranteed to be executed first, and resource competition can be avoided.
[0073] Step 240: in response to the task submission instruction, submitting the first task request in the task queue to the GPU for execution.
[0074] It should be noted that this step is similar to the aforementioned step S130, and will not be repeated here.
[0075] It can be understood that when the scheduling controller submits the first task request in the task queue to the GPU in response to the task submission instruction, the task request currently being executed by the GPU can not be executed, and the task request currently being executed needs to be suspended and re-joined to the task queue for continued execution. For example, as shown in FIG. 3 and FIG. 4, task request 3 is being executed, and at this time, the timing period arrives to trigger the task submission instruction. Next, the GPU will execute the task request 4 ranked first in the task queue, and the task request 3 will be re-joined to the task queue. The following describes how to re-join the task request being executed to the task queue. Figure 3 Figure 5 As shown in FIG. 3 and FIG. 4, task request 3 is being executed, and at this time, the timing period arrives to trigger the task submission instruction. Next, the GPU will execute the task request 4 ranked first in the task queue, and the task request 3 will be re-joined to the task queue. The following describes how to re-join the task request being executed to the task queue.
[0076] In some embodiments, in response to the task submission instruction, if it is determined that the GPU has not executed the task request currently being executed, it is determined whether there is a same task request as the task request not yet executed in the task queue.
[0077] For example, the scheduling controller can determine that the task request currently being executed has not been executed by obtaining the execution state identifier of the GPU, such as “running” or “not completed”, and the like. Further, based on the task identifier of the task request not yet executed, it can be determined whether there is a task request with the same task identifier as the task request not yet executed in the task queue, to determine whether there is a same task request as the task request not yet executed in the task queue. It can be understood that if there is a task request with the same task identifier, the task request not yet executed can be regarded as the task request of the i-th frame, and the same task request existing in the task queue can be regarded as the task request of the i+1-th frame.
[0078] (1) If yes, it means that there is a same task request as the task request not yet executed in the task queue, and the task request not yet executed is added to the task queue according to the frame loss type in the task parameters of the task request not yet executed.
[0079] Specifically, if the frame loss type is allowed frame loss, the same task request already existing in the task queue is deleted, the execution time limit of the task request not yet executed is updated, and the task request not yet executed is added to the task queue based on the updated execution time limit.
[0080] For example, as mentioned above, if the frame dropping type is "frame dropping allowed," the task request for the next frame can be actively discarded. In other words, the task result of the incomplete task request (frame i) can be used as the task result of the task request for frame i+1, which is equivalent to losing the task request for frame i+1. In this implementation, the scheduling controller can first determine whether the original deadline of the incomplete task request has expired. If it has not expired, the execution time limit is updated based on the original deadline and the current time; if the original deadline has expired, the next timing period (…) can be… Figure 3 The timestamp of the next dashed line (as shown) is used as the new deadline. Based on the new deadline, the execution time limit of unfinished task requests is updated, and then the unfinished task requests can be added to the task queue based on the updated execution time limit. For example, in scenarios where frame dropping is allowed (such as video playback and animation transitions), the reuse of adjacent frames is usually not noticeable to the user.
[0081] In this way, when a task that allows frame dropping is the same as an incomplete task, the duplicate task in the queue is directly deleted, avoiding the GPU from repeatedly calculating similar content, avoiding resource waste, improving GPU utilization, and reducing queue congestion.
[0082] If the frame loss type is "frame loss not allowed", then the unfinished task request is added to the preceding position of the existing identical task request in the task queue, and the execution time limit of the unfinished task request is updated.
[0083] For example, if the frame loss type is "frame loss not allowed," it means that if this type of task is lost (or delayed), it will directly affect core functionality or user experience. Therefore, the position of the existing identical task request in the task queue is determined, and the incomplete task request is added before that position, as long as it is before that position, ensuring that the incomplete task is scheduled before existing identical tasks. Simultaneously, the execution time limit of the incomplete task request is calculated by subtracting a preset value from the execution time limit of the existing identical task request, ensuring that during subsequent task queue updates, the incomplete task remains ahead of existing identical tasks. In this way, when a "frame loss not allowed" task is incomplete and the queue contains identical tasks, it can be ensured that tasks are not lost and the execution order is correct, guaranteeing the stability of core functionality and the consistency of user experience.
[0084] (2) If not, it means that there is no task request in the task queue that is the same as the unfinished task request. Then update the execution time limit of the unfinished task request and add the unfinished task request to the task queue.
[0085] Exemplarily, the scheduling controller can first determine whether the original deadline of the unexecuted task request is expired, if not, update the execution time limit based on the original deadline and the current time; if the original deadline is expired, take the timestamp of the next timing period (as shown by the next dashed line) as a new deadline, update the execution time limit of the unexecuted task request based on the new deadline, and then add the unexecuted task request to the task queue based on the updated execution time limit. Figure 3
[0086] In some embodiments, the scheduling controller can directly trigger a task submission instruction when receiving a special task request, and preempt the GPU resources for execution. Specifically, if it is determined that a task request carrying a preset task identifier is received, a task submission instruction is triggered, and the task request carrying the preset task identifier is submitted to the GPU for execution. In this way, the emergency task can be directly submitted to the GPU for execution without queuing and waiting for the trigger period, thereby ensuring the real-time performance of the emergency task.
[0087] In this embodiment, the scheduling controller can determine the task parameters corresponding to the task request according to the task identifier carried in the task request, determine the execution time limit of the task request based on the time consumption of each frame in the task parameters, add the task request to the task queue based on the execution time limit, and submit the first task request in the task queue to the GPU for execution in response to the task submission instruction. In this way, on the one hand, the task identifier is carried in the task request instead of the task parameters, which can reduce the data transmission amount, improve the communication efficiency, and be more suitable for the trigger scenario of high-frequency task requests; on the other hand, the more accurate execution time limit is calculated based on the task parameters, and the task queue is sorted more accurately, so that the most urgent task can obtain the GPU resources first, and the delay of the task is reduced; on the other hand, the GPU utilization is improved by processing the unexecuted task, and the stability of the core function and the continuity of the user experience are ensured while reducing the queue blocking.
[0088] Figure 6 A structure diagram of a first embodiment of a GPU task scheduling device provided by the application is shown. As shown in the figure, Figure 6 The GPU task scheduling device 300 includes a determination module 310, an adding module 320, and a submission module 330.
[0089] The determination module 310 is configured to determine the execution time limit of the received task request when receiving the task request.
[0090] The adding module 320 is configured to add the task request to a task queue based on the execution time limit of the task request, and the task requests in the task queue are sorted in ascending order of the execution time limit.
[0091] The submitting module 330 is configured to submit a first task request in the task queue to the GPU for execution in response to a task submitting instruction, and the GPU executes the task requests corresponding to the task submitting instructions in sequence.
[0092] In an optional manner, the determining module 310 is configured to:
[0093] determine the task parameter corresponding to the task request according to the task identifier carried in the task request, wherein the task parameter comprises one or more of the following: task type, per-frame time consumption, frame loss type;
[0094] determine the execution time limit of the task request according to the task parameter.
[0095] In an optional manner, the task parameter comprises per-frame time consumption, and the task request has a receiving time; the determining module 310 is configured to:
[0096] determine the sum of the receiving time and the per-frame time consumption as the deadline of the task request;
[0097] determine the execution time limit of the task request according to the deadline and the current time.
[0098] In an optional manner, the determining module 310 is configured to:
[0099] determine the difference between the deadline and the current time as the execution time limit of the task request; or
[0100] obtain a predicted value of GPU time consumption of the task request, and subtract the predicted value of the GPU time consumption from the difference between the deadline and the current time, and the result is taken as the execution time limit of the task request.
[0101] In an optional manner, the task parameter comprises a task type; the adding module 320 is configured to:
[0102] if there are task requests with the same execution time limit in the task queue, determine the task type in the task parameter of the task request, and sort the task requests with the same execution time limit based on the priority corresponding to the task type and then add the task requests to the task queue.
[0103] In an optional manner, the task parameter comprises a frame loss type; the adding module 320 is configured to:
[0104] In response to the task submission instruction, if it is determined that the GPU has not completed execution of a current task request being executed, and if it is determined that there is a same task request as the uncompleted task request in the task queue, the uncompleted task request is added to the task queue according to a frame loss type in a task parameter of the uncompleted task request.
[0105] If it is determined that there is no same task request as the uncompleted task request in the task queue, an execution time limit of the uncompleted task request is updated, and the uncompleted task request is added to the task queue.
[0106] In an optional manner, the adding module 320 is configured to:
[0107] If the frame loss type is a frame loss allowed type, the same task request already existing in the task queue is deleted, the execution time limit of the uncompleted task request is updated, and the uncompleted task request is added to the task queue based on the updated execution time limit.
[0108] If the frame loss type is a frame loss not allowed type, the uncompleted task request is added to a front position of the same task request already existing in the task queue, and the execution time limit of the uncompleted task request is updated.
[0109] In an optional manner, the task submission instruction is:
[0110] a timing period arrival triggered instruction; or
[0111] an instruction triggered after the GPU completes execution of a previous task request.
[0112] In an optional manner, the submitting module 330 is configured to:
[0113] If it is determined that a task request carrying a preset task identifier is received, the task submission instruction is triggered, and the task request carrying the preset task identifier is submitted to the GPU for execution.
[0114] As can be seen from the above, the GPU task scheduling device provided by the embodiment of the application can quantify the urgency of a task request by using an execution time limit, and sort the task requests based on the execution time limit, so as to ensure that the most urgent task obtains GPU resources first and reduce the delay of the task; and the GPU processes only one task at the same time, and converts parallel requests into ordered serial execution through a queue mechanism, so as to avoid frame loss and lag caused by multiple tasks simultaneously occupying resources, and improve user experience.
[0115] Figure 7Fig. 1 shows a structural schematic diagram of an embodiment of an electronic device provided by the present application, and the embodiments of the present application do not limit the specific implementation of the electronic device. The electronic device can be the aforementioned dispatch controller.
[0116] As shown in Fig. 1, the electronic device can include a processor 402, a communications interface 404, a memory 406, and a communications bus 408. Figure 7
[0117] The processor 402, the communications interface 404, and the memory 406 can communicate with each other through the communications bus 408. The communications interface 404 is configured to communicate with network elements such as clients or other servers. The processor 402 is configured to execute a program 410, and specifically can execute the related steps in the aforementioned embodiments of the method for dispatching GPU tasks.
[0118] Specifically, the program 410 can include program code including computer-executable instructions.
[0119] The processor 402 can be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present application. The one or more processors included in the electronic device can be processors of the same type, such as one or more CPUs; or can be processors of different types, such as one or more CPUs and one or more ASICs.
[0120] The memory 406 is configured to store the program 410. The memory 406 can include a high-speed RAM memory, and can also include a non-volatile memory such as at least one disk memory.
[0121] The program 410 can be specifically invoked by the processor 402 to cause the electronic device to perform the following operations:
[0122] Upon receiving a task request, determining an execution time limit of the received task request;
[0123] Based on the execution time limit of the task request, adding the task request to a task queue; wherein the task requests in the task queue are sorted in ascending order according to the values of the execution time limits;
[0124] In response to a task submission instruction, submitting a first task request in the task queue to the GPU for execution; wherein the GPU executes the task requests corresponding to the task submission instructions in sequence.
[0125] In an optional mode, the determining of the execution time limit of the received task request comprises:
[0126] According to the task identifier carried in the task request, the task parameter corresponding to the task request is determined; wherein the task parameter comprises one or more of the following: task type, per-frame time consumption, frame loss type;
[0127] According to the task parameter, the execution time limit of the task request is determined.
[0128] In an optional mode, the task parameter comprises per-frame time consumption, and the task request has a receiving time; the determining of the execution time limit of the task request according to the task parameter comprises:
[0129] The sum of the receiving time and the per-frame time consumption is determined as the deadline of the task request;
[0130] According to the deadline and the current time, the execution time limit of the task request is determined.
[0131] In an optional mode, the determining of the execution time limit of the task request according to the deadline and the current time comprises:
[0132] The difference between the deadline and the current time is determined as the execution time limit of the task request; or,
[0133] The predicted value of the GPU time consumption of the task request is obtained; and the difference between the deadline and the current time is subtracted by the predicted value of the GPU time consumption, and the result is taken as the execution time limit of the task request.
[0134] In an optional mode, the task parameter comprises a task type; the adding of the task request to the task queue based on the execution time limit of the task request comprises:
[0135] If there is a task request with the same execution time limit in the task queue, the task type in the task parameter of the task request is determined, and the task requests with the same execution time limit are sorted and added to the task queue based on the priority corresponding to the task type.
[0136] In an optional mode, the task parameter comprises a frame loss type; the method further comprises:
[0137] In response to the task submission instruction, if it is determined that the GPU has not executed a task request that is currently being executed, then if it is determined that there is a same task request as the unexecuted task request in the task queue, the unexecuted task request is added to the task queue according to a frame loss type in a task parameter of the unexecuted task request.
[0138] If it is determined that there is no same task request as the unexecuted task request in the task queue, the execution time limit of the unexecuted task request is updated, and the unexecuted task request is added to the task queue.
[0139] In an optional manner, the adding of the unexecuted task request to the task queue according to the frame loss type in the task parameter of the unexecuted task request comprises:
[0140] If the frame loss type is a frame loss allowed type, the same task request that already exists in the task queue is deleted, the execution time limit of the unexecuted task request is updated, and the unexecuted task request is added to the task queue based on the updated execution time limit;
[0141] If the frame loss type is a frame loss disallowed type, the unexecuted task request is added to a position in front of the same task request that already exists in the task queue, and the execution time limit of the unexecuted task request is updated.
[0142] In an optional manner, the task submission instruction is:
[0143] a timing period arrival triggered instruction; or
[0144] an instruction triggered after the GPU finishes executing a previous task request.
[0145] In an optional manner, the method further comprises:
[0146] If it is determined that a task request carrying a preset task identifier is received, the task submission instruction is triggered, and the task request carrying the preset task identifier is submitted to the GPU for execution.
[0147] As can be seen from the above, the electronic device provided by the embodiment of the application can quantify the urgency of a task request by using an execution time limit, and sort the task requests based on the execution time limit, so as to ensure that the most urgent task obtains GPU resources first and reduce the delay of the task; and the GPU processes only one task at the same time, and converts parallel requests into ordered serial execution through a queue mechanism, so as to avoid frame loss and lag caused by simultaneous occupation of resources by multiple tasks, and improve user experience.
[0148] The vehicle machine provided by the embodiment of the present application can utilize the urgency of the time limit for execution task request, and sort the task request based on the time limit for execution, so as to ensure that the most urgent task can obtain GPU resource preferentially, and reduce the delay of the task; and the GPU can only process one task at the same time, and the parallel request can be converted into ordered serial execution through the queue mechanism, so as to avoid frame loss and lag caused by multiple tasks simultaneously occupying resources, and improve the user experience.
[0149] The vehicle machine provided by the embodiment of the present application can utilize the urgency of the time limit for execution task request, and sort the task request based on the time limit for execution, so as to ensure that the most urgent task can obtain GPU resource preferentially, and reduce the delay of the task; and the GPU can only process one task at the same time, and the parallel request can be converted into ordered serial execution through the queue mechanism, so as to avoid frame loss and lag caused by multiple tasks simultaneously occupying resources, and improve the user experience.
[0150] The computer readable storage medium provided by the embodiment of the present application stores at least one executable instruction, and the executable instruction can make the electronic device / GPU task scheduling device execute the GPU task scheduling method in any method embodiment.
[0151] The executable instruction can be used to make the electronic device / GPU task scheduling device execute the following operations:
[0152] When the task request is received, the time limit for execution of the received task request is determined;
[0153] Based on the time limit for execution of the task request, the task request is added to the task queue; wherein the task requests in the task queue are sorted from small to large according to the value of the time limit for execution;
[0154] In response to the task submission instruction, the first task request in the task queue is submitted to the GPU for execution; wherein the GPU executes the task request corresponding to each task submission instruction in turn.
[0155] In an optional manner, the determination of the time limit for execution of the received task request comprises:
[0156] According to the task identifier carried in the task request, the task parameter corresponding to the task request is determined; wherein the task parameter comprises one or more of the following: task type, time consumption per frame, frame loss type;
[0157] According to the task parameter, the time limit for execution of the task request is determined.
[0158] In an optional manner, the task parameter comprises the time consumption per frame, and the task request has a receiving time; and the determination of the time limit for execution of the task request according to the task parameter comprises:
[0159] determining a sum of the receiving time and the per-frame time consumption as a deadline of the task request;
[0160] determining an execution time limit of the task request according to the deadline and a current time.
[0161] In an optional manner, the determining the execution time limit of the task request according to the deadline and the current time comprises:
[0162] determining a difference between the deadline and the current time as the execution time limit of the task request; or
[0163] obtaining a predicted value of GPU time consumption of the task request; and subtracting the predicted value of the GPU time consumption from a difference between the deadline and the current time, to obtain the execution time limit of the task request.
[0164] In an optional manner, the task parameter comprises a task type; and the adding the task request to the task queue based on the execution time limit of the task request comprises:
[0165] determining a task type in the task parameter of the task request, and adding the task requests with the same execution time limit to the task queue in sequence based on a priority corresponding to the task type.
[0166] In an optional manner, the task parameter comprises a frame loss type; and the method further comprises:
[0167] in response to a task submission instruction, if it is determined that the GPU has not executed a task request being executed currently, and if it is determined that there is a task request same as the task request not executed in the task queue, adding the task request not executed to the task queue according to a frame loss type in the task parameter of the task request not executed;
[0168] if it is determined that there is no task request same as the task request not executed in the task queue, updating the execution time limit of the task request not executed, and adding the task request not executed to the task queue.
[0169] In an optional manner, the adding the task request not executed to the task queue according to the frame loss type in the task parameter of the task request not executed comprises:
[0170] If the frame loss type is allowed frame loss, a same task request existing in the task queue is deleted, an execution time limit of the unexecuted task request is updated, and the unexecuted task request is added to the task queue based on the updated execution time limit;
[0171] If the frame loss type is not allowed frame loss, the unexecuted task request is added to a front position of the same task request existing in the task queue, and the execution time limit of the unexecuted task request is updated.
[0172] In an optional mode, the task submission instruction is:
[0173] a timing cycle arrival triggered instruction; or
[0174] an instruction triggered after the GPU executes a previous task request.
[0175] In an optional mode, the method further comprises:
[0176] If it is determined that a task request carrying a preset task identifier is received, the task submission instruction is triggered, and the task request carrying the preset task identifier is submitted to the GPU for execution.
[0177] As can be seen from the above, the computer readable storage medium provided by the embodiment of the application stores at least one executable instruction, which, when running on the scheduling device of the electronic device / GPU task, can quantify the urgency of a task request by using an execution time limit, sort the task request based on the execution time limit, ensure that the most urgent task obtains GPU resources first, and reduce the delay of the task; and the GPU processes only one task at the same time, converts parallel requests into ordered serial execution through a queue mechanism, avoids frame loss and lag caused by multiple tasks simultaneously occupying resources, and improves user experience.
[0178] The algorithms and displays presented herein are not inherently related to any particular computer, virtual system, or other apparatus. Furthermore, the embodiments of the application are not described with reference to any particular programming language.
[0179] In the specification provided herein, a large number of specific details are described. However, it can be understood that the embodiments of the application can be practiced without these specific details. Similarly, in order to simplify the application and help understand one or more of the various inventive aspects, in the above description of the exemplary embodiments of the application, various features of the embodiments of the application are sometimes grouped together into a single embodiment, figure, or description thereof. Among them, the claims following the detailed description are hereby expressly incorporated into the detailed description, wherein each claim itself is a separate embodiment of the application.
[0180] Those skilled in the art will appreciate that modules in the apparatus in the embodiments can be adapted and placed in one or more apparatuses other than that of the embodiments. Modules or units or components in the embodiments can be combined into one module or unit or component and furthermore can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive.
[0181] It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that one skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in a claim. The word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The application can be implemented by means of both hardware and software, and any combination thereof. In a unit claim, any reference to 'composition' should not be construed as a limitation unless the composition is a product of manufacturing. The use of the word 'about' in relation to a numerical value preferably means ± 10 % of the value. The use of the word 'optionally' in relation to an event or circumstance means that the event or circumstance can or can not occur, and that the description includes instances where the event or circumstance occurs and instances where it does not. The use of the terms first, second and third, and the like, does not imply any order but rather are used for naming purposes only. The use of the word 'at least one' in relation to an event or circumstance means that the event or circumstance can occur once or more than once. The use of the word 'one' in relation to an event or circumstance means that the event or circumstance can occur once only. The use of the word 'only' in relation to an event or circumstance means that the event or circumstance can occur once only. The use of the word 'each' in relation to an event or circumstance means that the event or circumstance can occur once or more than once. The use of the word 'first' in relation to an event or circumstance means that the event or circumstance can occur once only. The use of the word'second' in relation to an event or circumstance means that the event or circumstance can occur once only. The use of the word 'third' in relation to an event or circumstance means that the event or circumstance can occur once only. The use of the word'substantially' in relation to a numerical value preferably means ± 15 % of the value. The use of the word 'comprise', and variations such as 'comprising', 'comprises' or 'comprised of' are not intended to exclude other additives, components, elements or steps.
Claims
1. A method for scheduling a GPU task, the method comprising: The method comprises: Upon receiving a task request, determining an execution time limit of the received task request; Based on the execution time limit of the task request, adding the task request to a task queue; wherein the task requests in the task queue are sorted in ascending order according to the values of the execution time limit; In response to a task submission instruction, submitting a first task request in the task queue to the GPU for execution; wherein the GPU executes the task requests corresponding to the task submission instructions in sequence.
2. The method of claim 1, wherein, The determination of the execution time limit of the received task request comprises: According to the task identifier carried in the task request, determining the task parameters corresponding to the task request; wherein the task parameters comprise one or more of the following: task type, per-frame time consumption, frame loss type; According to the task parameters, determining the execution time limit of the task request.
3. The method of claim 2, wherein, The task parameters comprise per-frame time consumption, and the task request has a receiving time; The determination of the execution time limit of the task request according to the task parameters comprises: Determining the sum of the receiving time and the per-frame time consumption as the deadline of the task request; According to the deadline and the current time, determining the execution time limit of the task request.
4. The method of claim 3, wherein, The determination of the execution time limit of the task request according to the deadline and the current time comprises: Determining the difference between the deadline and the current time as the execution time limit of the task request; or Obtaining a predicted value of the GPU time consumption of the task request; and subtracting the predicted value of the GPU time consumption from the difference between the deadline and the current time, and taking the result as the execution time limit of the task request.
5. The method of claim 2, wherein, The task parameters comprise a task type; and the adding of the task request to the task queue based on the execution time limit of the task request comprises: If there are task requests with the same execution time limit in the task queue, determining the task type in the task parameters of the task request, and sorting the task requests with the same execution time limit based on the priority corresponding to the task type, and then adding the task requests to the task queue.
6. The method of claim 2, wherein, The task parameters comprise a frame loss type; and the method further comprises: In response to a task submission instruction, if it is determined that the GPU has not executed a task request being executed, when it is determined that there is a task request same as the task request being executed in the task queue, adding the task request being executed to the task queue according to the frame loss type in the task parameters of the task request being executed; When it is determined that there is no task request same as the task request being executed in the task queue, updating the execution time limit of the task request being executed, and adding the task request being executed to the task queue.
7. The method of claim 6, wherein, The adding of the task request being executed to the task queue according to the frame loss type in the task parameters of the task request being executed comprises: If the frame loss type is a permitted frame loss, a same task request existing in the task queue is deleted, an execution time limit of the unexecuted task request is updated, and the unexecuted task request is added to the task queue based on the updated execution time limit; If the frame loss type is a non-permitted frame loss, the unexecuted task request is added to a front position of a same task request existing in the task queue, and an execution time limit of the unexecuted task request is updated.
8. The method according to any one of claims 1 to 7, characterized in that, The task submission instruction is: an instruction triggered by arrival of a timing period; or an instruction triggered by the GPU after execution of a previous task request.
9. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: If it is determined that a task request carrying a preset task identifier is received, the task submission instruction is triggered, and the task request carrying the preset task identifier is submitted to the GPU for execution.
10. An electronic device, comprising: Comprise: a processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete communication among each other through the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the operations of the GPU task scheduling method according to any one of claims 1-9.