Method for controlling GPU load in virtualization system

By analyzing and managing the GPU load weight of OpenGL commands in the virtualized system, disassembling heavy load instructions and priority scheduling, the problem of difficult GPU load in the virtualized system is solved, and the certainty, reliability and security of the system are improved sex.

CN119396566APending Publication Date: 2025-02-07CHINESE AERONAUTICAL RADIO ELECTRONICS RES INST
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411321664.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-23
Publication Date
2025-02-07

AI Technical Summary

Technical Problem

The GPU load in the virtualized system is difficult to control, resulting in excessive use of the GPU by the client, causing the graphics processing time to be extended or timed out, and in severe cases, it may cause failures, affecting the certainty, reliability and security of the system.

Method used

Through testing and analysis, confirm the GPU load weight values ​​of each OpenGL command, disassemble the heavy load instructions into low load instructions, analyze and manage the GPU load of the OpenGL command sequence, schedule and monitor the GPU load according to priority levels, and ensure that it is within a predetermined range.

Benefits of technology

Effectively control the GPU load of each client in the virtualized system, ensure that high-security graphics processing tasks can be completed in a timely manner, improve the certainty, reliability and safety of the system, and adapt to the strictness of the aerospace, rail transit, industrial control and other fields. Demanding requirements.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119396566A_ABST
    Figure CN119396566A_ABST
Patent Text Reader

Abstract

The invention discloses a method for controlling GPU (Graphics Processing Unit) load in a virtualization system, which comprises the following steps of: determining a GPU load weight value of each OpenGL (Open Graphics Library) command by testing and analyzing, judging the GPU load of the OpenGL command according to the GPU load weight value, and disassembling a heavy load command into a plurality of low load commands; the GPU load of the OpenGL command sequence is analyzed, management is carried out based on the load weight value, and it is ensured that the GPU load of the OpenGL command sequence submitted to the GPU every time is not too heavy; each OpenGL command sequence is scheduled according to the priority, the execution time of each group of submitted uninterruptible command sequences is monitored, and the GPU load is limited in a preset range. According to the method, GPU hardware virtualization support is not needed, the GPU can provide resources for clients in a balanced mode, graphic processing tasks can be completed timely and accurately, and the strict requirements for certainty, reliability and safety of a system are met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer graphics, and in particular to a technology for improving the certainty, reliability and security of real-time graphics processing by controlling GPU load in a virtualization system. Background Art

[0002] In the past twenty years, the virtualization technology of computer systems has made great progress and has been more widely used. From cloud computing servers to edge computing devices, from general processing to embedded processing, virtualization systems are widely used. Aerospace, rail transportation, industrial control and other fields with high certainty, reliability and security requirements have also begun to use virtualization systems for real-time graphics processing.

[0003] Modern GPUs used in server fields such as cloud computing usually have dedicated hardware units that support virtualization, which can allocate fixed GPU processing resources to clients that need to use GPUs in virtualized systems, and effectively isolate the mutual influence between clients. GPUs used in embedded fields usually do not have hardware virtualization support, and generally provide GPU resources to clients that need to use GPUs in virtualized systems through software virtualization technologies such as API forwarding.

[0004] GPU sharing achieved through software virtualization technologies such as API forwarding has variable length inherent in GPU instructions and a very wide processing load span. After a set of instructions is submitted, resources can only be switched after they are executed. This makes it difficult to control the GPU load of each client, and it is difficult to effectively prevent clients from overusing the GPU. Once a client overuses the GPU, it can easily lead to extended or even timeout graphics processing time for all clients using the GPU, and in severe cases, it may cause failures, posing serious challenges to the determinism, reliability, and security of the system. Summary of the invention

[0005] The purpose of the present invention is to provide a method for controlling the GPU load in a virtualization system, which can improve the certainty, reliability and security of the virtualization system for real-time graphics processing, so as to meet the stringent requirements of certainty, reliability and security in the fields of aerospace, rail transportation and industrial control. The application of the present invention can control the GPU load of each client in the virtualization system within the expected range, ensure that the client involved in high-security level graphics processing can obtain GPU resources in time to accurately complete the graphics processing task within a certain time limit, achieve the improvement of certainty, reliability and security, improve the competitiveness of virtualization system products, and be more conducive to promotion and application.

[0006] The object of the present invention is achieved through the following technical solutions:

[0007] A method for controlling GPU load in a virtualization system comprises the following steps:

[0008] Step 1: Confirm the GPU load weight value of each OpenGL command through testing and analysis, and save it to the GPU load weight table;

[0009] Step 2: Determine the GPU load of the OpenGL command according to the GPU load weight value of the OpenGL command. If it is heavy, decompose it first, decompose a heavy load command into multiple low load commands and then enter step 3. Otherwise, directly enter step 3.

[0010] Step 3: Based on the low-load OpenGL commands to be submitted to the GPU for execution determined in the above steps, the GPU load of the OpenGL command sequence is analyzed, and managed based on the load weight value to ensure that the GPU load of each OpenGL command sequence submitted to the GPU is not too heavy;

[0011] Step 4: Schedule each OpenGL command sequence according to priority, and monitor the execution time of each group of submitted non-interruptible command sequences to limit the GPU load within a predetermined range.

[0012] Preferably, the GPU load weight of the OpenGL command is divided into a fixed weight and a variable weight. Each OpenGL command in the GPU load weight table has a table entry for recording the weight, and each table entry has a flag indicating whether the weight is variable, a basic weight value, a parameter dependency of the variable weight, and a coefficient of the variable weight. When the "variable flag" indicates that the GPU load weight of the OpenGL command corresponding to the table entry is a fixed weight, the "basic weight value" of the table entry is the GPU load weight value of the OpenGL command. When the "variable flag" indicates that the GPU load weight of the OpenGL command corresponding to the table entry is a variable weight, the corresponding GPU load weight value of the OpenGL command is the basic weight value in the table entry + the parameter dependency of the variable weight * the coefficient of the variable weight.

[0013] In step 2, OpenGL command decomposition only occurs for OpenGL commands with variable weights.

[0014] Preferably, in step 2, whether the load is too heavy is determined by comparing the GPU load weight value of the evaluated OpenGL command with a load weight threshold.

[0015] Preferably, in step three, the evaluation of the GPU load weight of each command sequence submitted to the GPU is characterized by a cumulative weight value: each time a command sequence is submitted to the GPU, the GPU load weight cumulative value returns to zero, and each time an OpenGL command is added, the GPU load weight cumulative value increases the GPU load weight value of the corresponding OpenGL command; if the current OpenGL command is neither a glFinish command nor a glFlush command, and the GPU load weight cumulative value plus the GPU load weight cumulative value of the current OpenGL command exceeds a threshold, then a glFlush command is inserted into the OpenGL command sequence to send the previous OpenGL command sequence for execution, the current OpenGL command is retained in a new command sequence, the GPU load weight cumulative value is set to zero, the GPU load weight value is added to the GPU load weight cumulative value, and subsequent OpenGL command processing continues.

[0016] Preferably, step 2 and step 3 are executed in a client in the virtualization system, and step 4 is executed in a virtualization manager in the virtualization system.

[0017] The beneficial effects of the present invention are:

[0018] The purpose of the present invention is to provide a method for controlling GPU load in a virtualization system, by quantifying the GPU load of a graphics rendering command, realizing the detection and splitting of GPU overload commands from the aspect of a single graphics rendering command, realizing the control of the GPU load of a rendering command stream from the aspect of a rendering command stream, controlling the GPU load of the rendering command stream submitted to the GPU within a moderate range, creating conditions for priority-based scheduling and GPU command sequence submission, and finally solving the early detection and control flow limiting of the risk of GPU over-occupancy based on priority GPU command sequence submission and GPU monitoring, solving the deterministic, reliability and security risks such as stuttering and freezing caused by excessive GPU occupation by a single client in a virtualization system, improving the deterministic, reliability and security of real-time graphics processing in a virtualization system, so as to adapt to the strict requirements of deterministic, reliability and security in the fields of aerospace, rail transportation and industrial control. The present invention can effectively control the GPU load in a virtualization system without GPU hardware virtualization support, so that the GPU can evenly provide resources for each client to complete graphics processing tasks in a timely and accurate manner, meeting the strict deterministic, reliability and security requirements of the system. The present invention can be applied to airborne cockpit systems in the aviation field to improve product integration, system quality and product competitiveness. It can also be promoted and applied to aerospace, rail transportation, industrial control and other fields, with significant economic benefits. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1A schematic diagram of the principle of a method for controlling GPU load in a virtualization system. DETAILED DESCRIPTION

[0020] The present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0021] See also Figure 1 As shown, a method for controlling GPU load in a virtualized system shown in this embodiment includes main links such as GPU load weight quantification of OpenGL commands, OpenGL command disassembly based on GPU load weight, OpenGL command sequence balancing based on GPU load weight, priority-based GPU command sequence submission, GPU load monitoring, etc., and each link is described in detail below.

[0022] Step 1: Quantification of GPU load weight of OpenGL commands: Confirm the GPU load weight value of each OpenGL command through testing and analysis, and save it to the GPU load weight table.

[0023] The GPU load weights of OpenGL commands are divided into fixed weights and variable weights. Each OpenGL command has a table entry that records the weight. Each table entry has a flag indicating whether the weight is variable, a basic weight value, a parameter dependency of the variable weight, and a coefficient of the variable weight. If the "variable flag" is 0, it means that the GPU load weight of the OpenGL command corresponding to the table entry is a fixed weight, and the "basic weight value" of the table entry is the GPU load weight value of the OpenGL command. If the "variable flag" is 1, it means that the GPU load weight of the OpenGL command corresponding to the table entry is a variable weight, and the corresponding GPU load weight value of the OpenGL command is the basic weight value in the table entry + the parameter dependency of the variable weight * the coefficient of the variable weight.

[0024] Take the glDrawArrays command as an example. In the table corresponding to the glDrawArrays command in the GPU load weight table of OpenGL commands, the "Variable Flag" is 1, indicating that the GPU load weight of the glDrawArrays command is variable and depends on the specific parameters of the call. The "Basic Weight Value" of this table item is 30, the "Parameter Dependency of Variable Weight" of this table item is the third parameter, and the "Variable Weight Coefficient" of this table item is 0.2. If the third parameter number of vertices is 4096 when calling glDrawArrays, then the GPU load weight of this glDrawArrays command = 30 + 0.2 * 4096 = 849.2, rounded up to 850.

[0025] Step 2: Decomposing OpenGL commands based on GPU load weight: Determine the GPU load of the OpenGL command based on the GPU load weight value of the OpenGL command. If it is heavy, decompose it first, decompose a heavy-load command into multiple low-load commands and then proceed to step 3. Otherwise, proceed directly to step 3.

[0026] Whether the load is too heavy is determined by comparing the GPU load weight value of the evaluated OpenGL command with the load weight threshold. OpenGL command disassembly based on GPU load weight only occurs when an OpenGL command with a variable GPU load weight is found and the evaluated GPU load weight exceeds the threshold. This step avoids the problem of a single GPU command sequence occupying the GPU for an unexpectedly long time from the source.

[0027] Take the glDrawArrays command as an example. Assume that the GPU load weight quantification link of the OpenGL command is established through testing and analysis. In the glDrawArrays command table of the GPU load weight table of the OpenGL command, the "variable flag" is 1, the "basic weight value" is 30, the "variable weight parameter dependency" is the third parameter, and the "variable weight coefficient" is 0.2; the GPU load weight value and load weight threshold of the OpenGL command are 1000, and the glDrawArrays command renders a triangle this time, and the third parameter is 30000. Then the GPU load weight of this glDrawArrays command = 30 + 0.2 * 30000 = 6030, which is greater than the GPU load weight value and load weight threshold of the OpenGL command of 1000, and should be disassembled. When disassembling, it cannot be directly disassembled according to the threshold of 1000. It is more robust to leave a certain margin. We split it at about 60% of the threshold, that is, about 600, and 6030 / 600 is about 10. We split this glDrawArrays command into 10 times on average, each time glDrawArrays renders a triangle, and the number of rendered vertices (that is, the third parameter) is 30000 / 10=3000. In this way, a glDrawArrays command with a GPU load weight of 6030 is split into 10 glDrawArrays commands with a GPU load weight of 630. This avoids the problem of a single GPU command sequence occupying the GPU for an unexpectedly long time.

[0028] Step 3, OpenGL command sequence balancing based on GPU load weight: Based on the low-load OpenGL commands to be submitted to the GPU for execution determined in the above steps, the GPU load of the OpenGL command sequence is analyzed and managed based on the load weight value to ensure that the GPU load of each OpenGL command sequence submitted to the GPU will not be too heavy. We use the cumulative weight value to characterize the evaluation of the GPU load weight of each command sequence submitted to the GPU. Each time a command sequence is submitted to the GPU, the cumulative value of the GPU load weight returns to zero. For each additional OpenGL command, the cumulative value of the GPU load weight increases the GPU load weight value of the corresponding OpenGL command. The glFinish command and glFlush command in the OpenGL command will trigger the forced submission of commands to the GPU. If the current OpenGL command is neither a glFinish command nor a glFlush command, and the cumulative value of the GPU load weight plus the cumulative value of the GPU load weight of the current OpenGL command exceeds the threshold, then it is necessary to immediately insert the glFlush command into the OpenGL command sequence to send the previous OpenGL command sequence for execution. The current OpenGL command is retained until a new command sequence, the GPU load weight accumulation value is set to zero, the GPU load weight value is accumulated to the GPU load weight accumulation value, and then the subsequent OpenGL command processing is continued.

[0029] Step 4: Priority-based GPU command sequence submission and GPU load monitoring: Schedule each OpenGL command sequence according to priority, submit the ones with high priority first, ensure the execution of high-criticality processing tasks, and monitor the execution time of each group of submitted uninterruptible command sequences to limit the GPU load to a predetermined range.

[0030] A virtualization system usually includes computer hardware, a virtualization manager, and several clients. The computer hardware of a virtualization system is the physical computer component that has virtualization support capabilities; the virtualization manager runs on the computer hardware of the virtualized computer system and provides resource management, client creation and management, and other functions; the client is mainly composed of system software, driver software, and application software.

[0031] The GPU load weight quantification of OpenGL commands is carried out during the design and evaluation phase. The results of the GPU load weight quantification of OpenGL commands are used at runtime and exist in the form of a GPU load weight table of OpenGL commands. OpenGL command decomposition based on GPU load weight and OpenGL command sequence balancing based on GPU load weight are usually executed in the client. A virtualization system usually has multiple clients, and each client may have different priorities depending on the criticality of the resident function. Priority-based GPU command sequence submission and GPU load monitoring are executed in the virtualization manager.

[0032] The priority is determined based on the criticality of the processing tasks undertaken by each client. The higher the criticality, the higher the priority. When the virtualization manager submits the command sequence from the client to the GPU, it schedules it based on the priority, submitting the high-priority tasks first to ensure the execution of the high-criticality processing tasks.

[0033] The GPU load monitoring link monitors the execution time of each group of submitted uninterruptible command sequences, and updates the GPU load of each client based on the monitoring data statistics. When the GPU load of a client is monitored to exceed the limit, the corresponding partition GPU overload information will be reported to the system, and the system will decide to increase the GPU load limit range or limit the command flow submitted to the GPU by the corresponding partition to limit the GPU load within the predetermined range.

[0034] The GPU load weight quantification link of the OpenGL command of the present invention solves the problem of quantitatively characterizing and evaluating the GPU load of different OpenGL commands in the form of load weight, and provides a premise for balancing and monitoring the GPU load; the OpenGL command disassembly link based on the GPU load weight solves the problem of discovering and disassembling the OpenGL commands with excessive GPU load, and splits the OpenGL commands with excessive GPU load into multiple OpenGL commands with moderate GPU load, so that the subsequent link load balancing link can control the GPU load of each submitted command sequence; the OpenGL command sequence balancing link based on the GPU load weight solves the problem of excessive GPU occupancy caused by the OpenGL command sequence with excessive GPU load being sent to the GPU, and after the processing of this link , OpenGL command sequences with heavy GPU load will be divided into several command sequences with moderate GPU load for submission; the priority-based GPU command sequence submission link will ensure that GPU command sequences from clients with higher criticality and higher security levels are submitted to the GPU for execution in a limited manner. GPU load monitoring ensures the reliability of key functions. For GPU command sequences from clients with lower criticality and security levels, combined with GPU load monitoring, it is ensured that they do not occupy the GPU excessively to avoid serious problems such as stuttering and freezing. If the GPU occupancy exceeds the system preset range, the GPU command sequence from the corresponding client will be limited. At this time, the corresponding basic functions can still be guaranteed, but the graphics performance will be reduced. The functions and performance of other clients with higher criticality and security levels can continue to be guaranteed.

[0035] It is understandable that those skilled in the art can make equivalent substitutions or changes based on the technical solution and inventive concept of the present invention, and all these changes or substitutions should fall within the protection scope of the claims attached to the present invention.

Claims

1. A method for controlling GPU load in a virtualization system, characterized in that The following steps are involved: Step 1: Confirm the GPU load weight value of each OpenGL command through testing and analysis, and save it to the GPU load weight table; Step 2: Determine the GPU load of the OpenGL command according to the GPU load weight value of the OpenGL command. If it is heavy, decompose it first, decompose a heavy load command into multiple low load commands and then enter step 3. Otherwise, directly enter step 3. Step 3: Based on the low-load OpenGL commands to be submitted to the GPU for execution determined in the above steps, the GPU load of the OpenGL command sequence is analyzed, and managed based on the load weight value to ensure that the GPU load of each OpenGL command sequence submitted to the GPU is not too heavy; Step 4: Schedule each OpenGL command sequence according to priority, and monitor the execution time of each group of submitted non-interruptible command sequences to limit the GPU load within a predetermined range.

2. The method for controlling GPU load in a virtualization system according to claim 1, characterized in that The GPU load weight of OpenGL commands is divided into fixed weight and variable weight. Each OpenGL command in the GPU load weight table has a table entry recording the weight. Each table entry has a variable weight flag, a basic weight value, a variable weight parameter dependency, and a variable weight coefficient. When the "variable flag" indicates that the GPU load weight of the OpenGL command corresponding to the table entry is a fixed weight, the "basic weight value" of the table entry is the GPU load weight value of the OpenGL command. When the "variable flag" indicates that the GPU load weight of the OpenGL command corresponding to the table entry is a variable weight, the corresponding GPU load weight value of the OpenGL command is the basic weight value in the table entry + the variable weight parameter dependency * the variable weight coefficient. In step 2, OpenGL command decomposition only occurs for OpenGL commands with variable weights.

3. The method for controlling GPU load in a virtualization system according to claim 1, characterized in that In step 2, whether the load is too heavy is determined by comparing the GPU load weight value of the evaluated OpenGL command with the load weight threshold.

4. The method for controlling GPU load in a virtualization system according to claim 1, characterized in that In step three, the evaluation of the GPU load weight of each command sequence submitted to the GPU is characterized by the cumulative weight value: after each command sequence is submitted to the GPU, the GPU load weight cumulative value returns to zero, and each time an OpenGL command is added, the GPU load weight cumulative value increases the GPU load weight value of the corresponding OpenGL command; if the current OpenGL command is neither a glFinish command nor a glFlush command, and the GPU load weight cumulative value plus the GPU load weight cumulative value of the current OpenGL command exceeds the threshold, then the glFlush command is inserted into the OpenGL command sequence to send the previous OpenGL command sequence for execution, the current OpenGL command is retained in a new command sequence, the GPU load weight cumulative value is set to zero, the GPU load weight value is added to the GPU load weight cumulative value, and then the subsequent OpenGL command processing continues.

5. The method for controlling GPU load in a virtualization system according to claim 1, characterized in that Step 2 and step 3 are executed in the client in the virtualization system, and step 4 is executed in the virtualization manager in the virtualization system.