Video memory processing method and device, storage medium and program product

By introducing a memory controller subsystem and a memory control group to manage memory resources, the problems of waste and contention between tasks in GPU memory resource allocation are solved, and fine-grained isolation and on-demand allocation of memory are achieved, thereby improving resource utilization.

CN121785804APending Publication Date: 2026-04-03ALIBABA CLOUD COMPUTING CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-03-04
Publication Date
2026-04-03

AI Technical Summary

Technical Problem

In existing technologies, GPU memory resource allocation suffers from waste and resource contention between tasks, resulting in low resource utilization.

Method used

A video memory controller subsystem is introduced to manage video memory resources through a video memory control group, enabling fine-grained isolation and on-demand allocation, and preventing resource contention and waste between tasks.

Benefits of technology

It improves the utilization of GPU memory resources, ensuring that multiple tasks can safely and efficiently share the memory resources of the same physical GPU card, and avoids the waste of the entire card's resources being monopolized by small tasks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121785804A_ABST
    Figure CN121785804A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a video memory processing method and device, a storage medium and a program product, and relates to the technical field of GPUs. The method comprises the following steps: when a first video memory capacity corresponding to a target task needs to be applied, calling a first video memory allocation interface function registered in an operating system to execute the following video memory allocation process: acquiring video memory use information of a target video memory control group to which an application process belongs through a video memory controller subsystem pre-registered in the operating system; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the video memory capacity upper limit constraint of the target video memory control group; according to the video memory usage information, performing allocation processing on the first video memory capacity to obtain a video memory allocation result; and updating the video memory use information of the target video memory control group according to the video memory allocation result. According to the scheme, resource scrambling among multiple tasks is prevented, the waste that resources of the whole card are exclusively occupied by small tasks is avoided, and the utilization rate of the video memory is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of GPU technology, and in particular to a method, device, storage medium and program product for processing video memory. Background Technology

[0002] With the rapid development of artificial intelligence, deep learning, and high-performance computing, graphics processing units (GPUs) have become the core computing power resource supporting large-scale model training and inference tasks. In practical applications, GPU memory resources are currently allocated on a whole-card basis, treating the physical GPU card as an indivisible unit and allocating it to one or more tasks. However, this approach presents the following problems: When allocating the entire physical GPU card to a single task, if the task's memory requirements are much lower than the card's total memory resources, it will result in a waste of memory resources and low resource utilization.

[0003] When a physical GPU card is allocated to multiple tasks, the shared resources of the entire card can easily lead to contention for video memory resources among the tasks, thus affecting the execution efficiency of the tasks. Summary of the Invention

[0004] This application provides a method, device, storage medium, and program product for processing video memory, which not only prevents resource contention between multiple tasks but also avoids the waste of the entire card's resources being monopolized by small tasks, thereby improving the utilization rate of GPU video memory resources.

[0005] In a first aspect, embodiments of this application provide a video memory processing method applied to an application process, the method comprising: When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to perform the following video memory allocation process: The video memory usage information of the target video memory control group to which the application process belongs is obtained by pre-registering the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result. Update the memory usage information of the target memory control group based on the memory allocation results.

[0006] Secondly, embodiments of this application provide a video memory processing device for use in an application process. The device includes: a calling module, an acquisition module, an allocation module, and an update module. The calling module is used to call the first video memory allocation interface function registered in the operating system when it is necessary to request the first video memory capacity corresponding to the target task, so that the acquisition module, the allocation module and the update module can perform the corresponding video memory allocation operation; The acquisition module is used to acquire video memory usage information of the target video memory control group to which the application process belongs by pre-registering with the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group. The allocation module is used to trigger the graphics processor driver to allocate the first video memory capacity according to the video memory usage information, so as to obtain the video memory allocation result. The update module is used to update the video memory usage information of the target video memory control group according to the video memory allocation result.

[0007] Thirdly, embodiments of this application provide a video memory processing method applied to a graphics processor driver, the method comprising: The system retrieves the video memory usage information of the target video memory control group to which the application process belongs. This video memory usage information is obtained by the application process when it needs to request the first video memory capacity corresponding to the target task, by calling a first video memory allocation interface function registered in the operating system and then accessing the video memory controller subsystem pre-registered in the operating system. The video memory controller subsystem includes the target video memory control group generated in response to the creation of a target container group, to which the application process belongs. The video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group, under the upper limit constraint of the video memory capacity of the target video memory control group. The first video memory capacity is allocated according to the video memory usage information, and the obtained video memory allocation result is sent to the application process so that the application process updates the video memory usage information of the target video memory control group according to the video memory allocation result.

[0008] Fourthly, embodiments of this application provide a video memory processing device, applied to a driver program for a graphics processor, the device comprising: The acquisition module is used to acquire video memory usage information of the target video memory control group to which the application process belongs. This video memory usage information is obtained by the application process when it needs to request first video memory capacity corresponding to the target task, by calling a first video memory allocation interface function registered in the operating system through a video memory controller subsystem pre-registered in the operating system. The video memory controller subsystem includes the target video memory control group generated in response to the creation of a target container group, to which the application process belongs. The video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group, under the upper limit constraint of the target video memory control group's video memory capacity. The sending module is used to allocate the first video memory capacity according to the video memory usage information, and send the obtained video memory allocation result to the application process, so that the application process updates the video memory usage information of the target video memory control group according to the video memory allocation result.

[0009] Fifthly, embodiments of this application provide a video memory processing method applied to an application process on a server, the method comprising: Receive the target task sent by the client; When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to perform the following video memory allocation process: The video memory usage information of the target video memory control group to which the application process belongs is obtained by pre-registering the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result. Update the memory usage information of the target memory control group according to the memory allocation result; The target task is processed according to the allocated video memory capacity, and the task processing result is sent to the client.

[0010] Sixthly, embodiments of this application provide a video memory processing device for use in an application process on a server. The device includes: a receiving module, a calling module, an obtaining module, an allocating module, an updating module, and a sending module. The receiving module is used to receive the target task sent by the client; The calling module is used to call the first video memory allocation interface function registered in the operating system when it is necessary to apply for the first video memory capacity corresponding to the target task, so that the acquisition module, the allocation module, the update module and the sending module can perform the corresponding video memory allocation operation. The acquisition module is used to acquire video memory usage information of the target video memory control group to which the application process belongs by pre-registering with the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group. The allocation module is used to trigger the graphics processor driver to allocate the first video memory capacity according to the video memory usage information, so as to obtain the video memory allocation result. The update module is used to update the video memory usage information of the target video memory control group according to the video memory allocation result; The sending module is used to process the target task according to the allocated video memory capacity and send the task processing result to the client.

[0011] In a seventh aspect, embodiments of this application provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor performs the method as described in the first aspect, the third aspect, or the fifth aspect.

[0012] Eighthly, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the methods described in the first, third, or fifth aspects.

[0013] Ninthly, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, can implement the methods described in the first, third, or fifth aspects.

[0014] In the video memory processing scheme provided in this application embodiment, a video memory controller subsystem is pre-registered in the operating system. This subsystem manages multiple video memory control groups, each corresponding to a container group, thereby dividing and isolating tasks by container group. When an application process needs to request the first video memory capacity corresponding to the target task, it calls the registered first video memory allocation interface function and queries the video memory usage information of its target video memory control group through the video memory controller subsystem. This ensures that each task can only allocate video memory within the resource limit of its respective video memory control group, achieving video memory isolation at the system level and effectively preventing video memory contention and mutual interference between multiple tasks.

[0015] During the memory allocation process, the first memory capacity is allocated based on the current usage of the target memory control group, and the memory usage information of the target memory control group is precisely updated according to the allocation results after allocation. This fine-grained, real-time quota management mechanism based on memory control groups enables multiple tasks to safely and efficiently share the memory resources of the same physical GPU card. It prevents resource contention between multiple tasks and avoids the waste of the entire card's resources being monopolized by small tasks, thereby improving the utilization rate of GPU memory resources. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a video memory processing method provided in an embodiment of this application; Figure 2 Another flowchart of a video memory processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the application of a video memory processing method provided in an embodiment of this application; Figure 4 Another flowchart of a video memory processing method provided in an embodiment of this application; Figure 5 Another flowchart of a video memory processing method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a video memory processing device provided in an embodiment of this application; Figure 7 Another schematic diagram of a video memory processing device provided in an embodiment of this application; Figure 8Another schematic diagram of a video memory processing device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. In addition, the timing of the steps in the following method embodiments is only an example and not a strict limitation.

[0019] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to large language models or other models) comply with relevant laws and standards.

[0020] The following is a description of the terms used in the embodiments of this application: Application process: refers to an instance of a running application, which is the basic unit for resource allocation and scheduling by the operating system.

[0021] Currently, GPU memory resources are typically allocated at the physical GPU card level. When allocating the entire physical GPU card to a single task, if the task's memory requirements are significantly lower than the total GPU card memory resources, this results in wasted memory resources and low resource utilization. When allocating the entire physical GPU card to multiple tasks, the shared resources of the entire card can easily lead to memory contention among the tasks, thus affecting the execution efficiency of multiple tasks.

[0022] In view of this, this application provides a method for processing video memory, which solves the above problems through the following approach: A video memory controller subsystem is introduced into the operating system, and a correspondence is established between the video memory control groups it manages and the task container groups, thereby allocating an independent video memory resource quota for each task at the system level. When video memory corresponding to a task needs to be requested, the first video memory capacity is allocated based on the used video memory capacity of the application process belonging to the target video memory control group, under the constraint of the upper limit of the video memory capacity of the target video memory control group. After the allocation is completed, the video memory usage information of the target video memory control group is accurately updated based on the video memory allocation result. This essentially achieves fine-grained isolation and on-demand allocation of video memory, allowing a single GPU card to be securely shared by multiple tasks. This prevents resource contention between multiple tasks and avoids the waste of the entire card's resources being exclusively occupied by small tasks, thus improving the utilization rate of GPU video memory resources.

[0023] Figure 1 This is a flowchart illustrating a video memory processing method provided in an embodiment of this application. The method is applied to an application process, such as... Figure 1 As shown, the method includes the following steps: 101. When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to execute the following video memory allocation process: 1011. Obtain the video memory usage information of the target video memory control group to which the application process belongs by pre-registering the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0024] 1012. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result.

[0025] 1013. Update the memory usage information of the target memory control group based on the memory allocation results.

[0026] In practical applications, when the operating system starts or the GPU driver loads, the following initialization configuration operation is performed: 1. Register the memory controller subsystem with the operating system to serve as an independent unit for managing GPU memory resources.

[0027] 2. Identify and intercept the second memory allocation interface function registered by the GPU driver with the operating system. Create a new, generic first memory allocation interface function, and (using function pointers) encapsulate the second memory allocation interface function within the first memory allocation interface function. This redirects the operating system's call entry point for GPU memory operations from the original second memory allocation interface to the newly created first memory allocation interface, ensuring that subsequent memory allocation and release requests from application processes will first flow through the judgment and control logic of the first memory allocation interface function.

[0028] 3. After registration, the video memory controller subsystem has the ability to manage multiple video memory control groups (also known as cgroups). Each video memory control group corresponds to one or more application processes and is the basic unit for video memory resource isolation and statistics. Then, it creates and initializes its own resource management data for each video memory control group, including but not limited to: the maximum video memory capacity and the used video memory capacity. The maximum video memory capacity is used to set the maximum amount of video memory that the video memory control group can use; the initial value can be set to infinite or a default value. The used video memory capacity is used to count the total amount of video memory occupied by all application processes within the video memory control group.

[0029] It should be noted that the memory controller subsystem provides operation interfaces for the memory capacity limit, used memory capacity, and allocation results. The interface for the memory capacity limit allows users to dynamically configure and query the memory capacity limit, the interface for used memory capacity allows users to query the used memory capacity, and the interface for allocation results allows users to query the number of memory allocation failures. By providing these interfaces in the memory controller subsystem, users can easily query the used memory capacity, memory capacity limit, and number of memory allocation failures in real time. Furthermore, it supports dynamic adjustment of the memory capacity limit, improving user experience and subsequent operational flexibility.

[0030] When a user needs to perform a target task (such as a model inference task), they can issue a run command to the operating system via the command line. The operating system receives this command and then creates an application process to execute the command (i.e., starts the task). Following this, the operating system creates a target container group in response to the task's initiation. The memory controller subsystem, in response to the creation of the target container group, automatically or under configuration, generates a target memory control group bound to it. The newly created application process is assigned to this target container group and thus belongs to the corresponding target memory control group.

[0031] After a task starts, if an application process needs to request video memory during execution, it will initiate a video memory allocation request. This request triggers a call to the first video memory allocation interface function registered in the operating system. Specifically, this first video memory allocation interface function first queries the video memory controller subsystem to obtain video memory usage information for the target video memory control group to which the application process belongs. This information indicates the used video memory capacity of the application process belonging to the target video memory control group, under the constraint of the target video memory control group's upper limit. For example, this usage information may include the upper limit of video memory capacity and the used video memory capacity.

[0032] Subsequently, if the request for the first video memory capacity, based on the already used video memory capacity, will not result in exceeding the video memory capacity limit, then the second video memory allocation interface function is called to send a video memory allocation request corresponding to the first video memory capacity to the graphics processor driver. The second video memory allocation interface function is included in the first video memory allocation interface function, and the second video memory allocation interface function is the actual video memory allocation interface function of the graphics processor. The video memory allocation request includes the first video memory capacity.

[0033] In practice, a first video memory capacity is pre-accumulated based on the already used video memory capacity. If the pre-accumulated video memory capacity is less than or equal to the upper limit of video memory capacity, the allocation condition is determined to be met, and the second video memory allocation interface function is called to send a video memory allocation request to the graphics processor driver. The video memory allocation result fed back by the driver is received, which includes the actual allocated second video memory capacity. The first video memory capacity pre-accumulated based on the already used video memory capacity is adjusted to the second video memory capacity to update the already used video memory capacity. The second video memory capacity is determined based on the video memory allocation granularity of the graphics processor. It should be noted that in actual applications, the graphics processor driver may not allocate video memory according to any number of bytes requested by the application process, but rather according to a preset, fixed minimum unit (e.g., 0.1GB, 0.2GB, 0.4GB, etc.).

[0034] To make it easier to understand, we will use two scenarios as examples below. Suppose that the maximum video memory capacity of the target container group is 2GB, and the current used video memory capacity of the target container group is 1.2GB. Here, GB is also called gigabyte, which is a decimal unit of information measurement.

[0035] Scenario 1: Only one application process sends a video memory allocation request. Assuming the initial video memory allocation request requests 0.5GB, the first video memory capacity (0.5GB) is pre-accumulated based on the already used video memory capacity (1.2GB), resulting in a pre-accumulated video memory capacity (1.7GB). Then, this video memory capacity (1.7GB) is compared with the upper limit of video memory capacity (2GB), confirming that the video memory capacity (1.7GB) is less than the upper limit (2GB), satisfying the allocation condition. At this point, the actual video memory allocation interface function of the graphics processor (i.e., the second video memory allocation interface function) is called to send a video memory allocation request to the GPU driver, and the video memory allocation result is received from the driver (e.g., due to hardware granularity, 0.6GB is actually allocated). Afterwards, the application process adjusts the pre-accumulated first video memory capacity (0.5GB) to the second video memory capacity (0.6GB), thus updating the already used video memory capacity to 1.2GB + 0.6GB = 1.8GB.

[0036] Scenario 2: Two application processes in the target video memory control group simultaneously send video memory allocation requests. Assume application process 1 requests 0.3GB of first video memory, and application process 2 requests 0.4GB of second video memory, with application process 1 having a higher priority than application process 2. In this case, the two video memory allocation requests are pre-accumulated sequentially according to their priority from highest to lowest: 1. For application process 1: Based on the used video memory capacity (1.2GB), the first video memory capacity (0.3GB) is pre-accumulated to obtain the pre-accumulated video memory capacity (1.5GB), which is less than the upper limit of video memory capacity (2GB), thus satisfying the allocation condition.

[0037] 2. For application process 2: At this point, since the pre-accumulation operation of "application process 1" has taken effect (but the physical allocation may not be completed yet), the used video memory capacity can now be regarded as 1.5GB. Based on this, the first video memory capacity (0.4GB) is pre-accumulated to obtain the pre-accumulated video memory capacity (1.9GB), which is less than the upper limit of video memory capacity (2GB), thus satisfying the allocation condition.

[0038] Once the allocation conditions are met, the used video memory capacity can be updated based on the method described in Scenario 1 above, which will not be elaborated further here. It should be noted that without the "pre-accumulation" mechanism, application processes 1 and 2 might determine whether they can allocate memory based on the initial used video memory capacity (1.2GB). Although this would result in the final video memory capacity (1.9GB) not exceeding the limit, the concurrent states in between could cause management logic confusion. However, by using the aforementioned "pre-accumulation" mechanism, resource reservation can be completed instantly during the determination, ensuring the accuracy of resource allocation in a concurrent environment.

[0039] By determining that requesting the first memory capacity based on the used memory capacity will not exceed the memory capacity limit, the second memory allocation interface function is called to send a memory allocation request corresponding to the first memory capacity to the graphics processor driver, and the memory allocation result fed back by the driver is received. The used memory capacity is updated according to the second memory capacity in the memory allocation result. This realizes the allocation condition judgment in the memory allocation process. Only when the allocation condition (the request for the first memory capacity will not exceed the memory capacity limit) is the second memory allocation interface function called to call the actual memory allocation interface of the graphics processor driver. After the allocation is completed, the memory usage information of the target memory control group is accurately updated according to the actual allocated second memory capacity. This lays the foundation for multiple tasks to safely and efficiently share the memory resources of the same physical GPU card.

[0040] Furthermore, during this process, a first memory capacity is pre-accumulated based on the already used memory capacity. If the pre-accumulated memory capacity is less than or equal to the upper limit of memory capacity, the allocation condition is met. This ensures that the memory usage of any memory control group is strictly limited within its quota, preventing interference with the tasks of other memory control groups and improving the system stability of the multi-tasking shared environment. Additionally, by adjusting the pre-accumulated memory capacity to a second memory capacity to update the used memory capacity, the actual memory usage of the target memory control group and the GPU's physical memory is kept consistent at all times, ensuring the accuracy of memory resource statistics and allocation.

[0041] Furthermore, as an implementation method, if the difference between the updated used video memory capacity and the upper limit of video memory capacity is detected to be less than a set threshold, an alarm message is issued to indicate that the available video memory capacity is insufficient.

[0042] To facilitate understanding, continuing the example above, assume the threshold is set to 0.5GB, the updated used video memory is 1.7GB, and the maximum video memory capacity is 2GB. In practical applications, when the application process detects that the difference between the updated used video memory and the maximum video memory capacity (2GB - 1.7GB = 0.3GB) is less than the set threshold (0.5GB), it will issue an alarm message, such as "The target video memory control group has only 0.3GB of available video memory remaining, which is lower than the set threshold of 0.5GB." The alarm message can be sent in various ways, such as popping up a notification box with the alarm message in the monitoring display interface, or via SMS, email, etc., to the maintenance personnel. These methods are not listed here.

[0043] By issuing an alarm when the difference between the updated used video memory capacity and the upper limit of video memory capacity is less than a set threshold, a proactive approach can be taken. Specifically, maintenance personnel no longer need to wait for the target video memory control group to run out of memory. Instead, when the difference between the updated used video memory capacity and the upper limit of video memory capacity is less than the set threshold, they can proactively adjust the target video memory control group in advance based on the alarm information (for example, adjusting the upper limit of video memory capacity to 4GB) to ensure the smooth execution of tasks.

[0044] As another implementation method, if the updated used video memory capacity is detected to be greater than the proportion of the video memory capacity limit than the set proportion threshold, an alarm message is issued to indicate that the available video memory capacity is insufficient.

[0045] In practical implementation, for example, suppose the threshold is set to 0.5GB, the updated used video memory capacity is 1.7GB, and the upper limit of video memory capacity is 2GB. Then, in actual application, when the application process detects that the updated used video memory capacity (1.7GB) accounts for 85.2% of the upper limit of video memory capacity (2GB) more than the set percentage threshold (let's say 80%), an alarm message will be issued.

[0046] The above embodiments describe the specific execution process of the application process when it is determined that the allocation conditions are met. If the application for the first video memory capacity will exceed the upper limit of the video memory capacity based on the used video memory capacity, and it is determined that the allocation conditions are not met, then an allocation failure log record is generated.

[0047] In practice, the sum of the used video memory and the first video memory capacity can be compared with the upper limit of video memory capacity. If the sum of the used video memory and the first video memory capacity is greater than the upper limit of video memory capacity, the allocation condition is determined not to be met. For example, suppose the used video memory capacity is 1.7GB, the upper limit of video memory capacity is 2GB, and the first video memory capacity is 0.5GB. That is, the sum of the used video memory capacity and the first video memory capacity (1.7GB + 0.5GB = 2.2GB) is greater than the upper limit of video memory capacity (2GB), and the allocation condition is determined not to be met. At this time, an allocation failure log record is generated. This allocation failure log record may contain information about the failed video memory control group (used to record which video memory control group the failure occurred in), a resource snapshot at the moment of failure (used to record information such as the first video memory capacity, the used video memory capacity, the upper limit of video memory capacity, and the remaining video memory capacity), and the process identifier of the application process that initiated the video memory allocation request, etc. By generating an allocation failure log record when the allocation condition is not met, the troubleshooting speed of subsequent maintenance personnel can be improved, and the accuracy of fault root cause location can be guaranteed. It should be noted that, in order to improve job efficiency, in addition to generating an allocation failure log record when it is determined that the allocation conditions are not met, an error code can also be returned directly (for example, generating error code "0" directly when it is determined that the allocation conditions are not met). This is not limited here.

[0048] Based on the above, the video memory processing method provided in this application essentially achieves fine-grained isolation and on-demand allocation of video memory, enabling multiple tasks to share the video memory resources of the same physical GPU card without causing the entire card to be monopolized by a single task. This not only prevents resource contention between multiple tasks but also avoids the waste of the entire card's resources being monopolized by a small task, thereby improving the utilization rate of GPU video memory resources.

[0049] Figure 2 Another flowchart illustrating a video memory processing method provided in this application embodiment. This method is applied to an application process, such as... Figure 2 As shown, the method includes the following steps: 201. When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to execute the following video memory allocation process: 2011. By pre-registering the video memory controller subsystem to the operating system, the video memory usage information of the target video memory control group to which the application process belongs is obtained; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0050] 2012. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result.

[0051] 2013. Update the memory usage information of the target memory control group based on the memory allocation results.

[0052] 202. When it is necessary to release the third video memory capacity corresponding to the target task, call the first video memory release interface function registered in the operating system to release the third video memory capacity, and update the video memory usage information of the target control group based on the video memory release result.

[0053] For the specific execution process of step 201 and steps 2011-2013, please refer to the above embodiments, which will not be repeated here.

[0054] For step 202, assuming the target task is completed and a batch of video memory (corresponding to the third video memory capacity) needs to be released, the application process calls the first video memory release interface function registered in the operating system, and then calls the second video memory release interface function (i.e., the actual video memory release interface function of the graphics processor) encapsulated within it, sending the video memory release request corresponding to the third video memory capacity to the GPU driver. At this point, the operation instruction to the physical hardware (GPU) is completed, and the GPU driver will execute the actual video memory release operation.

[0055] Next, the application receives the video memory release result from the driver; if parsing the video memory release result confirms that the third video memory capacity was successfully released, then the video memory usage information of the target control group is updated, specifically: One implementation method is to obtain the memory usage information of the target memory control group to which the application process belongs through the memory controller subsystem, and receive the memory release result fed back by the driver through the application. If the memory release result is parsed and it is determined that the third memory capacity is successfully released, the memory usage information of the target memory control group is updated according to the memory usage information of the target memory control group and the third memory capacity.

[0056] In practice, the memory controller subsystem obtains the current memory usage information of the target memory control group to which the application process initiating the memory release request belongs, and calls the second memory release interface function to send a memory release request to the GPU driver. The GPU driver performs physical memory reclamation based on the memory release request and returns the memory release result after completion. If parsing the memory release result determines that the third memory capacity was successfully released, the memory usage information of the target memory control group is updated according to the memory usage information of the target memory control group and the third memory capacity; that is, the third memory capacity is subtracted from the used memory capacity.

[0057] For example, suppose the memory release request requests 0.3GB of third-party memory, and the target memory control group has 1.8GB of used memory. If the memory release result confirms that the third-party memory was successfully released, then the third-party memory (0.3GB) is subtracted from the used memory (1.8GB) to update the memory usage information of the target memory control group (i.e., the used memory is updated to 1.8GB - 0.3GB = 1.5GB).

[0058] If the analysis of the video memory release result determines that the release of the third video memory capacity failed, a release failure log record will be generated or a failure value will be generated directly.

[0059] By obtaining the memory usage information of the target memory control group to which the application process belongs, and confirming the successful release of the third memory capacity after parsing the memory release result, it is possible to ensure that the software-level memory resources are synchronized with the hardware physical operations. This avoids situations where the memory usage information of the target memory control group has been updated, but the actual release fails, leading to data inconsistency. Furthermore, updating the memory usage information of the target memory control group can be completed simply by subtracting the third memory capacity from the used memory capacity; the operation is simple and easy to implement.

[0060] As an alternative implementation, when the operating system receives a memory release request from an application process, it creates a release transaction record within the target memory control group. This record includes: the requested release capacity (i.e., the third memory capacity), the identifier of the initiating application process, a timestamp, and an initial status of "in progress." Simultaneously, the release amount is incremented in the target memory control group's "pre-release queue." Then, the second memory release interface function is called to send a memory release request to the GPU driver, causing the GPU to perform the actual memory release operation. If the GPU driver returns a successful release result, the corresponding release transaction record status is updated to "completed," and the record is removed from the pre-release queue, officially updating the memory usage information of the target memory control group. Conversely, if the GPU driver returns a failed release result, the transaction record status is updated to "failed," and the record is removed from the pre-release queue.

[0061] By responding to the request to release the third memory capacity, the first memory release interface function registered in the operating system is called to execute the above memory release process. This ensures that when a task releases memory, the quota of its memory control group is reduced. This portion of memory capacity can then be immediately used by other application processes within the same memory control group. This also replenishes the global free resource pool of the entire physical GPU, thereby effectively improving the utilization rate of GPU memory resources.

[0062] To facilitate understanding, the following will be combined with... Figure 3 The following is a detailed explanation of the overall implementation process of this plan: First, perform system initialization configuration: S1. Register the video memory controller subsystem with the operating system.

[0063] S2. Identify and intercept the second memory allocation interface function registered by the GPU driver with the operating system, create a new, general first memory allocation interface function and a first memory release interface function, and encapsulate the second memory allocation interface function within the first memory allocation interface function, and encapsulate the second memory release interface function within the first memory release interface function.

[0064] S3. Create and initialize dedicated resource management data for each memory control group, including but not limited to: memory capacity limit and used memory capacity.

[0065] Subsequently, when the application process needs to allocate the first amount of video memory corresponding to the target task, it performs the following operations: S4. Call the first video memory allocation interface function registered in the operating system to obtain the video memory usage information of the target video memory control group to which the application process belongs by pre-registering with the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0066] S5. If the request for the first video memory capacity, determined based on the used video memory capacity, will not result in exceeding the video memory capacity limit, then the second video memory allocation interface function is called to send a video memory allocation request corresponding to the first video memory capacity to the graphics processor driver. The second video memory allocation interface function is included in the first video memory allocation interface function, and the second video memory allocation interface function is the actual video memory allocation interface function of the graphics processor. The video memory allocation request includes the first video memory capacity.

[0067] S6. Receive the video memory allocation result fed back by the driver. The video memory allocation result includes the actual allocated second video memory capacity, which is determined based on the video memory allocation granularity of the graphics processor.

[0068] S7. Update the used video memory capacity based on the second video memory capacity.

[0069] When it is necessary to release the third video memory corresponding to the target task, the application process performs the following operations: S8. Call the second video memory release interface function to send a video memory release request corresponding to the third video memory capacity to the driver. The second video memory release interface function is included in the first video memory release interface function. The second video memory release interface function is the actual video memory release interface function of the graphics processor.

[0070] S9. Receive the video memory release result from the driver, and if the video memory release result is successfully parsed and the third video memory capacity is confirmed to be released, update the video memory usage information of the target control group.

[0071] It should be noted that after the system initialization configuration, you can allocate or release video memory separately, or allocate and release video memory simultaneously, or allocate video memory and then release it. There are no restrictions on this.

[0072] Figure 4 This is another flowchart illustrating a video memory processing method provided in an embodiment of this application. This method is applied to a graphics processor driver, such as... Figure 4 As shown, the method includes the following steps: 401. Obtain the video memory usage information of the target video memory control group to which the application process belongs. The video memory usage information is obtained by the application process when it needs to request the first video memory capacity corresponding to the target task, by calling the first video memory allocation interface function registered in the operating system and obtaining it through the video memory controller subsystem pre-registered in the operating system. The video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group. The video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0073] 402. Allocate the first video memory capacity according to the video memory usage information, and send the obtained video memory allocation result to the application process so that the application process can update the video memory usage information of the target video memory control group according to the video memory allocation result.

[0074] Optionally, before allocating the first video memory capacity according to the video memory usage information, the method further includes: receiving a video memory allocation request corresponding to the first video memory capacity sent by the application process by calling a second video memory allocation interface function, provided that the application process determines that the request for the first video memory capacity based on the used video memory capacity will not result in exceeding the upper limit of the video memory capacity. The second video memory allocation interface function is included in the first video memory allocation interface function, and the second video memory allocation interface function is the actual video memory allocation interface function of the graphics processor. The video memory allocation request includes the first video memory capacity.

[0075] Optionally, the step of allocating the first video memory capacity according to the video memory usage information and sending the obtained video memory allocation result to the application process includes: allocating the first video memory capacity based on the video memory allocation request to obtain a video memory allocation result; and sending the video memory allocation result to the application process, wherein the video memory allocation result includes the actually allocated second video memory capacity, and the second video memory capacity is determined based on the video memory allocation granularity of the graphics processor.

[0076] Optionally, the method further includes: receiving a video memory release request corresponding to the third video memory capacity sent by the application process through the second video memory release interface function; performing a video memory release operation based on the video memory release request to obtain a video memory release result; and feeding back the video memory release result to the application process so that the application process updates the video memory usage information of the target control group after parsing the video memory release result and determining that the third video memory capacity has been successfully released.

[0077] Figure 4 The method shown can perform the steps involved in the video memory processing method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0078] Figure 5 This is another flowchart illustrating a video memory processing method provided in an embodiment of this application. This method is applied to an application process on a server, such as... Figure 5 As shown, the method includes the following steps: 501. Receive the target task sent by the client.

[0079] 502. When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to perform the following video memory allocation process: 5021. By pre-registering the video memory controller subsystem in the operating system, obtain the video memory usage information of the target video memory control group to which the application process belongs; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0080] 5022. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result.

[0081] 5023. Update the memory usage information of the target memory control group based on the memory allocation results.

[0082] 5024. Process the target task according to the allocated video memory capacity and send the task processing results to the client.

[0083] Figure 5 The method shown can perform the steps involved in the video memory processing method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0084] Figure 6 This is a schematic diagram of a video memory processing device provided in an embodiment of this application. This device is applied to an application process, such as... Figure 6 As shown, the device includes: a calling module 61, an acquisition module 62, an allocation module 63, and an update module 64.

[0085] The calling module 61 is used to call the first video memory allocation interface function registered in the operating system when it is necessary to request the first video memory capacity corresponding to the target task, so that the acquisition module, the allocation module and the update module can perform the corresponding video memory allocation operation.

[0086] The acquisition module 62 is used to acquire video memory usage information of the target video memory control group to which the application process belongs by pre-registering with the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0087] The allocation module 63 is used to trigger the graphics processor driver to allocate the first video memory capacity according to the video memory usage information, so as to obtain the video memory allocation result.

[0088] The update module 64 is used to update the video memory usage information of the target video memory control group according to the video memory allocation result.

[0089] Optionally, the allocation module 63 is specifically configured to: if the application for the first video memory capacity, based on the used video memory capacity, will not result in exceeding the upper limit of the video memory capacity, then call a second video memory allocation interface function to send a video memory allocation request corresponding to the first video memory capacity to the graphics processor driver. The second video memory allocation interface function is included in the first video memory allocation interface function, and the second video memory allocation interface function is the actual video memory allocation interface function of the graphics processor. The video memory allocation request includes the first video memory capacity.

[0090] Optionally, the allocation module 63 is specifically configured to: receive the video memory allocation result fed back by the driver, the video memory allocation result including the actual allocated second video memory capacity, the second video memory capacity being determined based on the video memory allocation granularity of the graphics processor; and update the used video memory capacity according to the second video memory capacity.

[0091] Optionally, the device further includes: a sending module, configured to issue an alarm message indicating insufficient available video memory if the difference between the updated used video memory capacity and the upper limit of video memory capacity is detected to be less than a set threshold.

[0092] Optionally, the apparatus further includes a generation module, configured to generate an allocation failure log record if the application for determining the first video memory capacity based on the used video memory capacity would result in exceeding the video memory capacity limit.

[0093] Optionally, the update module 64 is further configured to: when it is necessary to release the third video memory capacity corresponding to the target task, call a first video memory release interface function registered in the operating system to release the third video memory capacity, and update the video memory usage information of the target control group based on the video memory release result; and call a second video memory release interface function to send a video memory release request corresponding to the third video memory capacity to the driver, wherein the second video memory release interface function is included in the first video memory release interface function, and the second video memory release interface function is the actual video memory release interface function of the graphics processor; receive the video memory release result fed back by the driver; and if parsing the video memory release result determines that the third video memory capacity has been successfully released, then update the video memory usage information of the target control group.

[0094] Optionally, the update module 64 is further configured to: obtain the memory usage information of the target memory control group to which the application process belongs through the memory controller subsystem; and update the memory usage information of the target memory control group according to the memory usage information of the target memory control group and the third memory capacity.

[0095] Optionally, the video memory usage information includes: the upper limit of video memory capacity and the used video memory capacity; the device further includes: a response module, used to respond to a data query request and perform at least one of the following operations through the following operation interfaces provided in the video memory controller subsystem: dynamically configuring and querying the upper limit of video memory capacity through the operation interface corresponding to the upper limit of video memory capacity; querying the used video memory capacity through the operation interface corresponding to the used video memory capacity; and querying the number of video memory allocation failures through the operation interface corresponding to the allocation result.

[0096] Figure 6The device shown can perform the steps involved in the video memory processing method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0097] Figure 7 This is another schematic diagram of a video memory processing device provided in an embodiment of this application. The device is applied to an application process in a server. The device includes: a receiving module 71, a calling module 72, an obtaining module 73, an allocation module 74, an updating module 75, and a sending module 76.

[0098] The receiving module 71 is used to receive the target task sent by the client.

[0099] The calling module 72 is used to call the first video memory allocation interface function registered in the operating system when it is necessary to apply for the first video memory capacity corresponding to the target task, so that the acquisition module, the allocation module, the update module and the sending module can perform the corresponding video memory allocation operation.

[0100] The acquisition module 73 is used to acquire video memory usage information of the target video memory control group to which the application process belongs by pre-registering with the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0101] The allocation module 74 is used to trigger the graphics processor driver to allocate the first video memory capacity according to the video memory usage information, so as to obtain the video memory allocation result.

[0102] The update module 75 is used to update the video memory usage information of the target video memory control group according to the video memory allocation result.

[0103] The sending module 76 is used to process the target task according to the allocated video memory capacity and send the task processing result to the client.

[0104] Figure 7 The device shown can perform the steps involved in the video memory processing method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0105] Figure 8 This is another schematic diagram of a video memory processing device provided in an embodiment of the present application. The device is applied to a driver program for a graphics processor and includes an acquisition module 81 and a sending module 82.

[0106] The acquisition module 81 is used to acquire video memory usage information of the target video memory control group to which the application process belongs. The video memory usage information is obtained by the application process when it needs to request the first video memory capacity corresponding to the target task, by calling the first video memory allocation interface function registered in the operating system and obtaining it through the video memory controller subsystem pre-registered in the operating system. The video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group. The video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group.

[0107] The sending module 82 is used to allocate the first video memory capacity according to the video memory usage information, and send the obtained video memory allocation result to the application process, so that the application process updates the video memory usage information of the target video memory control group according to the video memory allocation result.

[0108] Optionally, the device further includes: a receiving module, configured to receive a video memory allocation request corresponding to the first video memory capacity sent by the application process when it determines that the application process will not exceed the upper limit of the video memory capacity by calling a second video memory allocation interface function, wherein the second video memory allocation interface function is included in the first video memory allocation interface function and is the actual video memory allocation interface function of the graphics processor, and the video memory allocation request includes the first video memory capacity.

[0109] Optionally, the sending module 82 is specifically configured to: allocate the first video memory capacity based on the video memory allocation request to obtain a video memory allocation result; and send the video memory allocation result to the application process, wherein the video memory allocation result includes the actually allocated second video memory capacity, the second video memory capacity being determined based on the video memory allocation granularity of the graphics processor. It also receives a video memory release request corresponding to a third video memory capacity sent by the application process through a second video memory release interface function; performs a video memory release operation based on the video memory release request to obtain a video memory release result; and feeds back the video memory release result to the application process, so that the application process, upon parsing the video memory release result and determining that the third video memory capacity has been successfully released, updates the video memory usage information of the target control group.

[0110] Figure 8 The device shown can perform the steps involved in the video memory processing method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0111] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, in practice, this electronic device includes a memory 21 and a processor 22.

[0112] Memory 21 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0113] The processor 22, coupled to the memory 21, is used to execute the computer program in the memory 21 to implement the log processing method provided in the foregoing embodiments.

[0114] Furthermore, such as Figure 9 As shown, the electronic device also includes other components such as a communication component 23, a display 24, a power supply component 25, and an audio component 26. Figure 9 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 9 The components shown are as follows. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server device such as a conventional server, cloud server, or server array.

[0115] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0116] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0117] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0118] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0119] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0120] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium. Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0121] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for processing video memory, characterized in that, Applied to application processes, including: When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to perform the following video memory allocation process: The video memory usage information of the target video memory control group to which the application process belongs is obtained by pre-registering the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result. Update the memory usage information of the target memory control group based on the memory allocation results.

2. The method according to claim 1, characterized in that, The step of triggering the graphics processor driver to allocate the first video memory capacity based on the video memory usage information to obtain a video memory allocation result includes: If the request for the first video memory capacity, based on the already used video memory capacity, will not result in exceeding the video memory capacity limit, then the second video memory allocation interface function is invoked to send a video memory allocation request corresponding to the first video memory capacity to the graphics processor driver. The second video memory allocation interface function is included in the first video memory allocation interface function, and the second video memory allocation interface function is the actual video memory allocation interface function of the graphics processor. The video memory allocation request includes the first video memory capacity.

3. The method according to claim 2, characterized in that, The step of updating the memory usage information of the target memory control group according to the memory allocation result includes: The system receives the video memory allocation result fed back by the driver, the video memory allocation result including the actual allocated second video memory capacity, the second video memory capacity being determined based on the video memory allocation granularity of the graphics processor; The used video memory capacity is updated based on the second video memory capacity.

4. The method according to claim 3, characterized in that, The method further includes: If the difference between the updated used video memory capacity and the upper limit of video memory capacity is less than a set threshold, an alarm message indicating insufficient available video memory capacity will be issued.

5. The method according to claim 2, characterized in that, The method further includes: If the request for the first video memory capacity, based on the already used video memory capacity, would result in exceeding the video memory capacity limit, then an allocation failure log record is generated.

6. The method according to claim 1, characterized in that, The method further includes: When it is necessary to release the third video memory capacity corresponding to the target task, the first video memory release interface function registered in the operating system is called to release the third video memory capacity, and the video memory usage information of the target control group is updated based on the video memory release result.

7. The method according to claim 6, characterized in that, The process of calling the first video memory release interface function registered in the operating system to release the third video memory capacity, and updating the video memory usage information of the target control group based on the video memory release result, includes: The second video memory release interface function is called to send a video memory release request corresponding to the third video memory capacity to the driver. The second video memory release interface function is included in the first video memory release interface function, and the second video memory release function is the actual video memory release interface function of the graphics processor. Receive the video memory release result fed back by the driver; If the analysis of the video memory release result determines that the third video memory capacity was successfully released, then the video memory usage information of the target control group is updated.

8. The method according to claim 7, characterized in that, The updating of the video memory usage information of the target control group includes: The video memory controller subsystem obtains the video memory usage information of the target video memory control group to which the application process belongs. Update the memory usage information of the target memory control group based on the memory usage information of the target memory control group and the third memory capacity.

9. The method according to any one of claims 1-8, characterized in that, The video memory usage information includes: the maximum video memory capacity and the used video memory capacity; the method further includes: In response to a data query request, perform at least one of the following operations through the following operation interfaces provided in the video memory controller subsystem: The upper limit of video memory capacity can be dynamically configured and queried through the operation interface corresponding to the upper limit of video memory capacity. The used video memory capacity is queried through the operation interface corresponding to the used video memory capacity. The number of failed memory allocations can be queried through the operation interface corresponding to the allocation result.

10. A method for processing video memory, characterized in that, A driver applied to a graphics processor, the method comprising: The system receives a video memory allocation request, including a first video memory capacity, triggered by the video memory usage information of the target video memory control group to which the application process executing the target task belongs. The video memory usage information is obtained by the application process when it needs to request the first video memory capacity corresponding to the target task, by calling a first video memory allocation interface function registered in the operating system through a video memory controller subsystem pre-registered in the operating system. The video memory controller subsystem includes the target video memory control group, which is generated in response to the creation of a target container group, to which the application process belongs. The video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group, under the upper limit constraint of the video memory capacity of the target video memory control group. Perform the allocation operation for the first video memory capacity; The video memory allocation result is generated and fed back to the application process so that the application process can update the video memory usage information of the target video memory control group according to the video memory allocation result.

11. The method according to claim 10, characterized in that, The receiving of a memory allocation request containing a first memory capacity, triggered by the application process executing the target task based on memory usage information of its target memory control group, includes: If the application process receives a video memory allocation request corresponding to the first video memory capacity by calling a second video memory allocation interface function within the first video memory allocation interface function, provided that the request for the first video memory capacity will not exceed the upper limit of the video memory capacity based on the used video memory capacity, the second video memory allocation interface function is included in the first video memory allocation interface function and is the actual video memory allocation interface function of the graphics processor.

12. The method according to claim 10, characterized in that, The process of allocating the first video memory capacity includes: Based on the memory allocation granularity of the graphics processor, the first memory capacity is allocated to obtain a memory allocation result, which includes the actual allocated second memory capacity.

13. The method according to claim 10, characterized in that, Also includes: The application process receives a video memory release request corresponding to the third video memory capacity sent through the second video memory release interface function, and the second video memory release interface function is called in the first video memory release interface function registered in the operating system. Based on the aforementioned memory release request, a memory release operation is performed to obtain the memory release result. The video memory release result is fed back to the application process, so that the application process can update the video memory usage information of the target control group after parsing the video memory release result and determining that the third video memory capacity has been successfully released.

14. A method for processing video memory, characterized in that, The method, applied to an application process on a server, includes: Receive the target task sent by the client; When it is necessary to request the first video memory capacity corresponding to the target task, the first video memory allocation interface function registered in the operating system is called to perform the following video memory allocation process: The video memory usage information of the target video memory control group to which the application process belongs is obtained by pre-registering the video memory controller subsystem in the operating system; wherein, the video memory controller subsystem includes the target video memory control group generated in response to the creation of the target container group, and the application process belongs to the target container group; the video memory usage information indicates the used video memory capacity of the application process belonging to the target video memory control group under the upper limit constraint of the video memory capacity of the target video memory control group. Based on the video memory usage information, the graphics processor driver is triggered to allocate the first video memory capacity to obtain the video memory allocation result. Update the memory usage information of the target memory control group according to the memory allocation result; The target task is processed according to the allocated video memory capacity, and the task processing result is sent to the client.

15. The method according to claim 14, characterized in that, The step of triggering the graphics processor driver to allocate the first video memory capacity based on the video memory usage information to obtain a video memory allocation result includes: If the request for the first video memory capacity, based on the already used video memory capacity, will not result in exceeding the video memory capacity limit, then the second video memory allocation interface function is invoked to send a video memory allocation request corresponding to the first video memory capacity to the graphics processor driver. The second video memory allocation interface function is included in the first video memory allocation interface function, and the second video memory allocation interface function is the actual video memory allocation interface function of the graphics processor. The video memory allocation request includes the first video memory capacity.

16. An electronic device, characterized in that, include: The device includes a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the processor performs the method as described in any one of claims 1-9, or any one of claims 10-13, or any one of claims 14-15.

17. A non-transitory machine-readable storage medium, characterized in that, The non-transitory machine-readable storage medium stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-9, or any one of claims 10-13, or any one of claims 14-15.

18. A computer program product, characterized in that, include: A computer program, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-9, or any one of claims 10-13, or any one of claims 14-15.

Citation Information

Patent Citations

  • Video memory allocation method and device, electronic equipment and storage medium

    CN111400035A

  • Data processing method, device and equipment and readable storage medium

    CN113467958A

  • Dynamic regulation and control method for GPU (Graphic Processing Unit) resources of development machine, computer device and medium

    CN120803675A

  • Deep learning platform capable of resource management of graphic processing unit, and method for managing resource of graphic processing unit using the same

    KR102064882B1

  • Video memory allocation method, video memory request method, and device and storage medium

    WO2025044675A1