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

Abstract

The present disclosure relates to a graphics memory management method and device, a storage medium and a program product. The method comprises: creating a graphics API instance corresponding to a target application, wherein the graphics API instance is an instance of a specified graphics API; identifying a physical device in the system through the graphics API instance, and creating a logical device corresponding to the target application on the physical device; calling a function provided by the specified graphics API through the logical device, and applying for graphics memory for the target application based on a graphics memory request amount of the target application and at least two preset graphics memory allocation units. The present disclosure can achieve accurate control of graphics memory allocation based on a graphics API, and flexibly construct various graphics memory constraint scenarios. In this way, problems and aspects worth optimizing of a product can be exposed in advance during the product development stage, thereby reducing development costs and improving product stability.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and particularly relates to a graphics memory management method, a graphics memory management device, a nonvolatile computer readable storage medium and a computer program product. BACKGROUND

[0002] In the research and development process of GPU (Graphics Processing Unit, graphics processor) related products, product stability in the graphics memory constraint scenario is a key problem. At present, the industry usually relies on the problems exposed in the actual use process of the product to promote product improvement. However, this method has obvious limitations. Due to the complexity of the actual use scenario, the discovery of the problem is often lagging behind, and the positioning means is relatively insufficient. This leads to high cost and low efficiency when solving problems and optimizing products. SUMMARY

[0003] Therefore, the present disclosure provides a graphics memory management technical solution.

[0004] According to an aspect of the present disclosure, a graphics memory management method is provided, comprising:

[0005] creating a graphics API instance corresponding to a target application program, wherein the graphics API instance is an instance of a specified graphics API;

[0006] identifying a physical device in the system through the graphics API instance, and creating a logical device corresponding to the target application program on the physical device;

[0007] calling a function provided by the specified graphics API through the logical device, and applying graphics memory for the target application program based on the graphics memory request amount of the target application program and at least two preset graphics memory allocation units.

[0008] In a possible implementation, the calling of the function provided by the specified graphics API through the logical device, and the applying of graphics memory for the target application program based on the graphics memory request amount of the target application program and at least two preset graphics memory allocation units, comprises:

[0009] calling a resource creation function provided by the specified graphics API through the logical device to create a target resource for the target application program;

[0010] calling a graphics memory allocation function provided by the specified graphics API through the logical device to apply graphics memory for the target application program based on the graphics memory request amount of the target resource and at least two preset graphics memory allocation units.

[0011] In a possible implementation, the at least two preset graphic memory allocation units include a first preset graphic memory allocation unit and a second preset graphic memory allocation unit, and the first preset graphic memory allocation unit is greater than the second preset graphic memory allocation unit.

[0012] The function provided by the specified graphic API is called by the logic device to apply for graphic memory for the target application based on the graphic memory request amount of the target application and the at least two preset graphic memory allocation units, and the applying for graphic memory includes:

[0013] For the part of the graphic memory request amount of the target application that is greater than or equal to the first preset graphic memory allocation unit, the function provided by the specified graphic API is called by the logic device to apply for graphic memory for the target application based on the first preset graphic memory allocation unit, and for the part of the graphic memory request amount of the target application that is less than the first preset graphic memory allocation unit, the function provided by the specified graphic API is called by the logic device to apply for graphic memory for the target application based on the second preset graphic memory allocation unit.

[0014] In a possible implementation, for the part of the graphic memory request amount of the target application that is greater than or equal to the first preset graphic memory allocation unit, the function provided by the specified graphic API is called by the logic device to apply for graphic memory for the target application based on the first preset graphic memory allocation unit, and for the part of the graphic memory request amount of the target application that is less than the first preset graphic memory allocation unit, the function provided by the specified graphic API is called by the logic device to apply for graphic memory for the target application based on the second preset graphic memory allocation unit, and the applying for graphic memory includes:

[0015] In response to the graphic memory request amount of the target application being greater than or equal to the first preset graphic memory allocation unit, a first graphic memory allocation request is repeatedly generated based on the first preset graphic memory allocation unit by calling the function provided by the specified graphic API by the logic device, and graphic memory is applied for the target application based on the first graphic memory allocation request until the remaining graphic memory request amount of the target application is less than the first preset graphic memory allocation unit, and the graphic memory request amount of the first graphic memory allocation request is equal to the first preset graphic memory allocation unit.

[0016] In response to the remaining memory request amount of the target application program being less than the first preset memory allocation unit, the function provided by the specified graphics API is invoked by the logic device, a second memory allocation request is repeatedly generated based on the second preset memory allocation unit, and memory is applied for the target application program based on the second memory allocation request until the remaining memory request amount of the target application program is 0, wherein the memory request amount of the second memory allocation request is equal to the second preset memory allocation unit.

[0017] In a possible implementation, the type of memory applied for the target application program has host visibility and memory consistency.

[0018] In a possible implementation, the method further includes:

[0019] The memory allocated to the target application program is tracked using a dynamic array container.

[0020] In a possible implementation, the method further includes:

[0021] In response to the dynamic array container indicating that there is memory space that is no longer used by the target application program in the memory space allocated to the target application program, the memory space that is no longer used by the target application program is released.

[0022] In a possible implementation, the method further includes:

[0023] In response to the target application program ending, the logic device is destroyed, the target physical device is released, and the graphics API instance is destroyed.

[0024] In a possible implementation, the specified graphics API is Vulkan or Direct3D.

[0025] According to another aspect of the present disclosure, there is provided a memory management apparatus, comprising:

[0026] A creating module is configured to create a graphics API instance corresponding to a target application program, wherein the graphics API instance is an instance of a specified graphics API.

[0027] An identifying and creating module is configured to identify a physical device in a system through the graphics API instance, and create a logic device corresponding to the target application program on the physical device.

[0028] An applying module is configured to invoke a function provided by the specified graphics API through the logic device, apply memory for the target application program based on a memory request amount of the target application program and at least two preset memory allocation units.

[0029] In a possible implementation, the application module is configured to:

[0030] create a target resource for the target application by invoking a resource creation function provided by the specified graphics API via the logic device;

[0031] apply memory for the target application based on the memory request amount corresponding to the target resource and at least two preset memory allocation units by invoking a memory allocation function provided by the specified graphics API via the logic device.

[0032] In a possible implementation, the at least two preset memory allocation units include a first preset memory allocation unit and a second preset memory allocation unit, where the first preset memory allocation unit is greater than the second preset memory allocation unit.

[0033] The application module is configured to:

[0034] for a part of the memory request amount of the target application that is greater than or equal to the first preset memory allocation unit, apply memory for the target application based on the first preset memory allocation unit by invoking a function provided by the specified graphics API via the logic device, and for a part of the memory request amount of the target application that is less than the first preset memory allocation unit, apply memory for the target application based on the second preset memory allocation unit by invoking a function provided by the specified graphics API via the logic device.

[0035] In a possible implementation, the application module is configured to:

[0036] in response to the memory request amount of the target application being greater than or equal to the first preset memory allocation unit, repeatedly generate a first memory allocation request based on the first preset memory allocation unit by invoking a function provided by the specified graphics API via the logic device, and apply memory for the target application based on the first memory allocation request until the remaining memory request amount of the target application is less than the first preset memory allocation unit, where the memory request amount of the first memory allocation request is equal to the first preset memory allocation unit;

[0037] in response to the remaining memory request amount of the target application being less than the first preset memory allocation unit, repeatedly generate a second memory allocation request based on the second preset memory allocation unit by invoking a function provided by the specified graphics API via the logic device, and apply memory for the target application based on the second memory allocation request until the remaining memory request amount of the target application is 0, where the memory request amount of the second memory allocation request is equal to the second preset memory allocation unit.

[0038] In a possible implementation, the memory type applied for the target application program has host visibility and memory coherency.

[0039] In a possible implementation, the apparatus further includes:

[0040] a tracking module configured to track the memory allocated to the target application program using a dynamic array container.

[0041] In a possible implementation, the apparatus further includes:

[0042] a releasing module configured to release, in response to the dynamic array container indicating that there is memory space allocated to the target application program that is no longer used by the target application program, the memory space that is no longer used by the target application program.

[0043] In a possible implementation, the apparatus further includes:

[0044] a destroying and releasing module configured to, in response to the target application program ending, destroy the logical device, release the target physical device, and destroy the graphics API instance.

[0045] In a possible implementation, the specified graphics API is Vulkan or Direct3D.

[0046] According to another aspect of the present disclosure, there is provided an apparatus for managing memory, comprising a memory, a processor, and a computer program stored on the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0047] According to another aspect of the present disclosure, there is provided a non-volatile computer readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above method.

[0048] According to another aspect of the present disclosure, there is provided a computer program product comprising a computer program, or a non-volatile computer readable storage medium having a computer program carried thereon, wherein the computer program, when executed by a processor, implements the steps of the above method.

[0049] In this embodiment, a graphics API instance corresponding to the target application is created. This instance is a specified graphics API instance. Physical devices in the system are identified through this instance, and a logical device corresponding to the target application is created on the physical device. The logical device then calls functions provided by the specified graphics API to allocate video memory for the target application based on its video memory request volume and at least two preset video memory allocation units. This allows for precise control of video memory allocation based on the graphics API, enabling flexible construction of various video memory constraint scenarios. This approach not only allows for the early exposure of product problems and areas for optimization during the product development phase, thereby reducing development costs, improving product stability and market competitiveness, but also facilitates the reproduction of product problems in complex scenarios during product acceptance testing, enabling rapid identification and resolution of these issues and further improving product quality and reliability.

[0050] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0051] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0052] Figure 1 A flowchart illustrating the video memory management method provided in an embodiment of this disclosure is shown.

[0053] Figure 2 A schematic diagram of the video memory management method provided in an embodiment of this disclosure is shown.

[0054] Figure 3 A block diagram of a video memory management device provided in an embodiment of this disclosure is shown.

[0055] Figure 4 This is a block diagram illustrating a video memory management device 1900 according to an exemplary embodiment. Detailed Implementation

[0056] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0057] As used herein, the terms "comprise", "comprising", "have", "having", "include", "including", "contain", "containing", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but do not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof.

[0058] When an element is referred to as being "connected", "coupled", "responsive", or "in communication" with, to or with another element, it can be directly connected, coupled, responsive, or in communication with the other element, or intervening elements can be present.

[0059] Although the terms first, second, third, etc. can be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Thus, a first element / operation in some embodiments can be termed a second element / operation in other embodiments without departing from the teachings of the present inventive concept.

[0060] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any implementation described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

[0061] In addition, for the purpose of convenience and brevity, detailed descriptions of well-known devices, methods, procedures, components, circuits, and the like will not be described in detail herein. It will be apparent to those skilled in the art that the present disclosure can be practiced without some or all of these specific details. In some instances, certain process steps, methods, apparatus, and circuits have not been described in detail in order to avoid unnecessarily obscuring the contribution of the present disclosure.

[0062] In the related art, there is a lack of a simple and effective technical means that can discover potential problems in advance and optimize them during the product development stage. This lagging problem discovery method not only increases the development cost, but also may affect the market competitiveness and user experience of the product. In addition, due to the diversity and complexity of actual use scenarios, it is difficult to completely simulate and predict all possible problems during the development stage.

[0063] To solve the technical problems similar to the above, the embodiment of the disclosure provides a graphics memory management method, which comprises the following steps: creating a graphics API instance corresponding to a target application program, wherein the graphics API instance is an instance of a specified graphics API; identifying a physical device in a system through the graphics API instance; creating a logical device corresponding to the target application program on the physical device; and calling a function provided by the specified graphics API through the logical device, and applying graphics memory for the target application program based on a graphics memory request amount of the target application program and at least two preset graphics memory allocation units. Thus, the graphics memory allocation can be accurately controlled based on the graphics API, and various graphics memory constraint scenarios can be flexibly constructed. In this way, the product problems and aspects worth optimizing can be exposed in advance in the product development stage, thereby reducing the development cost, improving the product stability and market competitiveness, and reproducing the product problems in some complex scenarios in the product acceptance test stage, so as to facilitate and quickly locate and solve the problems, and further improve the quality and reliability of the product.

[0064] The graphics memory management method provided by the embodiment of the disclosure will be described in detail below with reference to the accompanying drawings.

[0065] Figure 1 A flowchart of the graphics memory management method provided by the embodiment of the disclosure is shown. In a possible implementation manner, the execution subject of the graphics memory management method can be a graphics memory management apparatus, for example, the graphics memory management method can be executed by a terminal device or a server or other electronic device. The terminal device can be a user equipment (User Equipment, UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (Personal Digital Assistant, PDA), a handheld device, a computing device, a vehicle-mounted device, or a wearable device, etc. In some possible implementation manners, the graphics memory management method can be realized by a processor calling computer readable instructions stored in a memory. As shown in Figure 1 The graphics memory management method comprises steps S11 to S13.

[0066] In step S11, a graphics API instance corresponding to a target application program is created, wherein the graphics API instance is an instance of a specified graphics API.

[0067] In step S12, a physical device in a system is identified through the graphics API instance, and a logical device corresponding to the target application program is created on the physical device.

[0068] In step S13, the function provided by the specified graphics API is invoked by the logic device to apply for the video memory for the target application based on the video memory request amount of the target application and at least two preset video memory allocation units.

[0069] In the embodiments of the present disclosure, the target application can be any application that needs video memory resources to run, such as an application that relies on a GPU (Graphics Processing Unit) for graphics rendering, calculation or other graphics-related tasks.

[0070] A graphics API (Application Programming Interface) instance is an entry for the target application to interact with graphics hardware. By creating a graphics API instance, the target application can access the functions of the graphics hardware, such as video memory allocation, graphics rendering, etc.

[0071] In the embodiments of the present disclosure, the specified graphics API can represent a graphics API that is determined in advance in the video memory management method and is used to implement the functions of video memory allocation and management.

[0072] In a possible implementation, the specified graphics API is Vulkan or Direct3D (D3D).

[0073] As an example of this implementation, the specified graphics API is Vulkan.

[0074] In Vulkan, the function for creating an instance is vkCreateInstance(). vkCreateInstance() is used to initialize a Vulkan instance, which is the basis for all subsequent operations in a Vulkan application. After successfully creating a Vulkan instance, the target application can further access the functions of the graphics hardware through the instance.

[0075] As another example of this implementation, the specified graphics API is Direct3D.

[0076] In Direct3D, the process of creating an instance usually involves creating a device (Device) and a device context (Device Context). By invoking the D3D11CreateDevice() function, a Direct3D device instance can be created, which is the core object for interacting with graphics hardware. After successfully creating a Direct3D device instance, the target application can perform graphics rendering and video memory management through the device instance.

[0077] Vulkan and Direct3D are both system-level graphics interfaces that can directly interact with GPU hardware, providing fine-grained control over video memory allocation. For example, Vulkan supports cross-platform use, allowing consistent video memory management strategies on multiple operating systems such as Windows, Linux, etc., while allowing developers to flexibly adjust video memory allocation strategies based on hardware characteristics, greatly improving resource utilization efficiency. Direct3D performs well on the Windows platform, providing efficient video memory management and graphics rendering capabilities, quickly responding to video memory requests and optimizing performance. In addition, both APIs support host visibility and memory consistency, reducing the synchronization complexity between CPU (Central Processing Unit) and GPU, further improving system stability and performance. Therefore, choosing Vulkan or Direct3D as the specified graphics API not only meets the diverse needs of video memory allocation for target application programs, but also enables efficient, flexible, and stable video memory management on different platforms.

[0078] In one possible implementation, users can choose to use Direct3D 11 (D3D11), Direct3D 12 (D3D12), or Vulkan as the specified graphics API according to their own needs. This flexibility not only allows developers to choose based on the performance needs of the target platform and application program, but also takes into account cross-platform compatibility and control capabilities over underlying hardware. For example, D3D11 and D3D12 are suitable for Windows platforms, providing simple-to-use and high-performance optimization features, respectively; while Vulkan supports cross-platform (such as Windows, Linux, etc.), and provides more underlying hardware control and efficient resource management capabilities. By allowing users to specify the API, different development needs and application scenarios can be better met.

[0079] In the embodiments of the present disclosure, a graphics API instance corresponding to the target application program can be created first, for example, by calling the vkCreateInstance() function of Vulkan or the D3D11CreateDevice() function of Direct3D, the target application program can initialize a graphics API instance. The graphics API instance provides a foundation for subsequent video memory allocation, resource management, and graphics rendering.

[0080] Through the graphics API instance, the available physical devices (such as GPUs) in the system can be identified, where the physical device is the actual hardware resource.

[0081] For example, in Vulkan, the identification of a physical device can be done by the following steps: enumerate the available physical devices in the system using the vkEnumeratePhysicalDevices() function; get the properties of each physical device (such as memory capacity, supported functions, etc.) using the vkGetPhysicalDeviceProperties() function.

[0082] For another example, in Direct3D, a physical device can be identified by the adapter specified when creating a device. The adapters in the system can be enumerated using IDXGIFactory::EnumAdapters1(), and a suitable adapter can be selected to create a Direct3D device.

[0083] In the embodiments of the present disclosure, after identifying the physical device, a logical device can be created on the selected physical device. The logical device is an abstraction layer between the target application and the physical device, and can be used to manage resources (such as buffers, textures, memory) and execute graphics commands.

[0084] For example, in Vulkan, a logical device can be created by the vkCreateDevice() function. When creating, the physical device and the required queue family and other characteristics can be specified.

[0085] For another example, in Direct3D, a logical device can be created by the D3D11CreateDevice() function. When creating, the adapter, device type, and function level can be specified.

[0086] In the embodiments of the present disclosure, the target application needs memory resources to store data (such as textures, vertex data, calculation results, etc.) during running. The target application can determine the total amount of memory to be applied, i.e., the memory request amount, according to its own running requirements. The memory request amount may vary depending on the scene, for example: a game scene may need a large amount of memory to store textures and models when loading; a data processing task may need a small memory block to store intermediate results; and the like.

[0087] The efficiency and flexibility of memory allocation directly affect the performance and user experience of the application. In order to better manage memory, the memory management method adopts at least two preset memory allocation units (such as 1 GB and 1 MB) to meet different memory size requirements. By adopting at least two preset memory allocation units, the memory allocation is allowed to be more flexible, which can meet large-scale memory requirements and accurately allocate small memory blocks.

[0088] In the embodiments of the present disclosure, the amount of video memory requested by the target application can be dynamically specified. That is, the target application can flexibly determine the required size of video memory at runtime according to actual needs, rather than relying on fixed preset values. In this way, the target application can dynamically adjust the allocation of video memory according to different scenarios, data volumes, or user operations, thereby more efficiently utilizing video memory resources and avoiding waste or deficiency. For example, a 3D game can dynamically calculate the required video memory according to the complexity of the current scene (such as the number of loaded textures, model size, etc.), and apply for video memory as needed, ensuring optimal performance and resource utilization efficiency on different devices.

[0089] In a possible implementation, the function provided by the specified graphics API is called by the logic device to apply for video memory for the target application based on the amount of video memory requested by the target application and at least two preset video memory allocation units, including: creating a target resource for the target application by calling a resource creation function provided by the specified graphics API through the logic device; and applying for video memory for the target application based on the amount of video memory requested by the target resource and at least two preset video memory allocation units by calling a video memory allocation function provided by the specified graphics API through the logic device.

[0090] In this implementation, the logic device can call a resource creation function provided by the specified graphics API to create a required graphics resource, i.e., a target resource, for the target application. The creation process of the target resource can explicitly determine the size, format, and other attributes of the target resource, thereby determining the corresponding amount of video memory requested.

[0091] For example, in Vulkan, a buffer resource can be created using the vkCreateBuffer() function. When creating, the size, purpose, and other attributes of the buffer need to be specified.

[0092] For another example, in Direct3D, a texture resource can be created using the ID3D11Device::CreateTexture2D() function. When creating, the width, height, format, and other attributes of the texture can be specified.

[0093] In this implementation, after the target resource is created, video memory can be allocated according to the amount of video memory requested by the target resource. The video memory allocation process can consider at least two preset video memory allocation units to flexibly meet the video memory requirements of different sizes. By calling a video memory allocation function provided by the specified graphics API through the logic device, video memory can be applied for the target application.

[0094] For example, in Vulkan, memory allocation can be done by the vkAllocateMemory() function, and the memory allocation can be based on the memory request of the resource and the preset memory allocation unit (e.g., 1 GB and 1 MB). For example, the properties of a buffer can be defined by a VkBufferCreateInfo structure. For example, the size of the buffer can be specified by bufferInfo.size = sizeInMB * 1024 * 1024, where sizeInMB * 1024 * 1024 represents the size in megabytes. After the buffer is created by the vkCreateBuffer(), the memory requirement (e.g., alignment requirement and memory type) of the buffer can be queried, for example, by the vkGetBufferMemoryRequirements(), and stored in a VkMemoryRequirements structure. Then, the size of the memory allocation (memRequirements.size) can be defined by a VkMemoryAllocateInfo structure, and the memory can be allocated by the vkAllocateMemory(). Finally, the allocated memory can be bound to the buffer by the vkBindBufferMemory() so that the buffer can store data.

[0095] For another example, in Direct3D, memory allocation can be done implicitly when a texture or other resource is created. For example, when a texture is created, Direct3D can automatically allocate memory based on the size and format of the texture. For example, the properties of the texture can be described by defining a D3D11_TEXTURE2D_DESC structure, such as format, width, and height. For example, the pixel format of the texture can be defined by d3d11TextureDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM; the width of the texture can be defined by d3d11TextureDesc.Width = TEXTURE_WIDTH; and the height of the texture can be defined by d3d11TextureDesc.Height = TEXTURE_HEIGHT.

[0096] In this implementation, in the memory management method, the target resource can be created for the target application by calling the resource creation related function provided by the specified graphics API through the logical device. Then, the memory can be applied for the target application by the memory allocation function based on the memory request of the target resource and the preset memory allocation unit. This process improves the flexibility and accuracy of memory management.

[0097] In a possible implementation, the at least two preset memory allocation units include a first preset memory allocation unit and a second preset memory allocation unit, where the first preset memory allocation unit is greater than the second preset memory allocation unit; and the applying, by the logic device, for memory of the target application based on the memory request amount of the target application and the at least two preset memory allocation units, includes: for a part of the memory request amount of the target application that is greater than or equal to the first preset memory allocation unit, applying, by the logic device, for memory of the target application based on the first preset memory allocation unit by invoking a function provided by the specified graphics API; and for a part of the memory request amount of the target application that is less than the first preset memory allocation unit, applying, by the logic device, for memory of the target application based on the second preset memory allocation unit by invoking the function provided by the specified graphics API.

[0098] In this implementation, a hierarchical memory allocation strategy is adopted, and the hierarchical memory allocation strategy is based on two preset memory allocation units: a first preset memory allocation unit and a second preset memory allocation unit, where the first preset memory allocation unit is greater than the second preset memory allocation unit.

[0099] In this implementation, for large memory requirements, using a larger allocation unit can reduce the number of allocation operations and improve allocation efficiency. For small memory requirements or the remaining part, using a smaller allocation unit can avoid memory waste and ensure the accuracy of memory allocation. By specifying the memory size in a parameterized manner, the target application can dynamically adjust the memory request amount according to actual requirements without fixed allocation units.

[0100] In a possible implementation, the part of the memory request amount of the target application that is greater than or equal to the first preset memory allocation unit is used to call a function provided by the specified graphics API by the logic device, and the memory is applied for the target application based on the first preset memory allocation unit, and the part of the memory request amount of the target application that is less than the first preset memory allocation unit is used to call a function provided by the specified graphics API by the logic device, and the memory is applied for the target application based on the second preset memory allocation unit, including: in response to the memory request amount of the target application being greater than or equal to the first preset memory allocation unit, repeatedly generating a first memory allocation request based on the first preset memory allocation unit by calling the function provided by the specified graphics API by the logic device, and applying for the memory for the target application based on the first memory allocation request, until the remaining memory request amount of the target application is less than the first preset memory allocation unit, wherein the memory request amount of the first memory allocation request is equal to the first preset memory allocation unit; in response to the remaining memory request amount of the target application being less than the first preset memory allocation unit, repeatedly generating a second memory allocation request based on the second preset memory allocation unit by calling the function provided by the specified graphics API by the logic device, and applying for the memory for the target application based on the second memory allocation request, until the remaining memory request amount of the target application is 0, wherein the memory request amount of the second memory allocation request is equal to the second preset memory allocation unit.

[0101] In an example, the first preset memory allocation unit can be 1 GB, and the second preset memory allocation unit can be 1 MB. In this example, for a memory request greater than or equal to 1 GB, the first preset memory allocation unit (1 GB) can be used for allocation in priority. By calling the function provided by the specified graphics API by the logic device, the memory can be repeatedly applied for in units of 1 GB until the remaining memory request amount is less than 1 GB. For the remaining part less than 1 GB, the second preset memory allocation unit (1 MB) can be switched to, and the memory allocation can be continued by calling the function provided by the specified graphics API by the logic device until the entire memory requirement of the target application is met.

[0102] By using the memory management strategy based on the hierarchical allocation unit, the memory requirement of the target application can be flexibly met, and the efficiency of memory allocation and the resource utilization rate can be improved.

[0103] In a possible implementation, the type of the memory applied for the target application has host visibility and memory consistency.

[0104] In this implementation, to ensure the memory consistency between the CPU and the GPU, a memory type with host visibility and memory coherency can be selected. That is, the allocated memory is not only visible to the GPU, but also can be directly accessed and modified by the CPU, thereby ensuring the consistency of the two in accessing and operating the memory. Although this strategy may sacrifice part of the performance, because host visibility and memory coherency usually introduce additional synchronization overhead, it significantly reduces the complexity of memory synchronization. This makes it easier to manage the memory, avoids errors caused by inconsistent memory, and also simplifies the collaboration process across the CPU and the GPU. Therefore, by selecting a memory type with host visibility and memory coherency, a more user-friendly memory management solution can be provided to developers while ensuring system stability.

[0105] In a possible implementation, the method further includes tracking the memory allocated to the target application using a dynamic array container.

[0106] In this implementation, a dynamic array container (such as std::vector in C++) can be used to track all memory resources allocated to the target application. This implementation can achieve comprehensive monitoring and management of memory resources by recording detailed information of each memory allocation (such as the address, size, and allocation time of the memory, etc.) in the dynamic array.

[0107] In a possible implementation, the method further includes, in response to the dynamic array container indicating that there is memory space that is no longer used by the target application in the memory space allocated to the target application, releasing the memory space that is no longer used by the target application.

[0108] In this implementation, when the dynamic array container detects that the target application no longer uses certain memory space, it can check the memory allocation information recorded in the dynamic array container to identify which memory regions have been released or no longer needed by the target application. Subsequently, a corresponding memory release function (such as vkFreeMemory() in Vulkan or the resource release interface in Direct3D) can be called to return these no longer used memory spaces to the memory management system. This process ensures efficient use of memory resources, while also improving the overall performance and stability of the system.

[0109] In a possible implementation, the method further includes, in response to the target application ending, destroying the logical device, releasing the target physical device, and destroying the graphics API instance.

[0110] In this implementation, when the target application ends, a series of cleanup operations can be performed to ensure proper resource release and system stability. These operations can include destroying logical devices, releasing physical devices, and destroying graphics API instances.

[0111] wherein the logical device is an abstraction layer between the target application and the physical device, used to manage resources and execute graphics commands. When the target application ends, the logical device is no longer needed, so it needs to be destroyed to release the resources and states associated with it.

[0112] The physical device represents the actual graphics hardware (such as GPU). At the end of the target application, the reference to the physical device needs to be released so that other applications can use the hardware resources while avoiding resource leaks.

[0113] The graphics API instance is an entry point between the target application and the graphics API, used to initialize the graphics environment and access graphics functions. When the target application no longer needs it, destroying the graphics API instance can release the system resources associated with it, ensuring the complete exit of the target application.

[0114] In this implementation, through these cleanup operations, it is ensured that all related resources are properly released when the target application ends, avoiding resource leaks and potential system instability.

[0115] The graphics memory management method provided by the embodiments of the present disclosure can be applied to the technical fields of computer graphics, GPU research and development, software testing, etc., without limitation.

[0116] The graphics memory management method provided by the embodiments of the present disclosure is described below through a specific application scenario. Figure 2 A schematic diagram of the graphics memory management method provided by the embodiments of the present disclosure is shown. As shown in Figure 2 The display management process can include:

[0117] Create instance: This is the starting step of the graphics memory management process, which involves creating a graphics API instance such as Direct3D or Vulkan instance. This graphics API instance is a bridge for the application to interact with graphics hardware, used for subsequent graphics memory management and resource creation.

[0118] Identify physical device, create logical device: In this step, the available physical devices (such as GPU) in the system can be identified through the graphics API instance, and a suitable physical device can be selected to create a logical device. The logical device is an abstraction layer between the application and the physical device, used to manage graphics memory and execute graphics commands.

[0119] Allocating video memory: After selecting the physical device and creating the logical device, the application can allocate the required video memory resources for the application by calling the video memory allocation function provided by the graphics API through the logical device. The size and type of video memory allocation depend on the application's needs.

[0120] Releasing video memory: When the application no longer needs certain video memory resources, it can release these resources by calling the video memory release function provided by the graphics API through the logical device. This helps to avoid video memory leaks and ensures that video memory resources can be used by other applications.

[0121] Destroying the logical device: When the application ends or no longer needs graphics functionality, the logical device can be destroyed. This step ensures that all resources related to the logical device, including video memory resources and other graphics resources, are properly released.

[0122] Releasing the physical device: After the logical device is destroyed, the reference to the physical device is also released. This step ensures that the physical device can be used by other applications or properly cleaned up when the system is shut down.

[0123] Destroying the instance: Finally, the graphics API instance is destroyed. This marks the end of the video memory management process and ensures that all resources related to the instance, including system resources and memory, are released.

[0124] It can be understood that the above-mentioned various method embodiments of the present disclosure can be combined with each other to form combined embodiments without violating the principle logic. Due to the limited space, the present disclosure will not be repeated. Those skilled in the art can understand that in the above-mentioned method of the specific embodiment, the specific execution order of each step should be determined according to its function and possible internal logic.

[0125] In addition, the present disclosure also provides a video memory management device, a non-volatile computer readable storage medium, and a computer program product, which can be used to implement any of the video memory management methods provided by the present disclosure. The corresponding technical solutions and technical effects can be referred to the corresponding description in the method part, and will not be repeated.

[0126] Figure 3 A block diagram of a video memory management device provided by an embodiment of the present disclosure is shown. As shown in Figure 3 The video memory management device includes:

[0127] A creating module 31 is configured to create a graphics API instance corresponding to a target application, wherein the graphics API instance is an instance of a specified graphics API;

[0128] An identifying and creating module 32 is configured to identify a physical device in a system through the graphics API instance, and create a logical device corresponding to the target application on the physical device.

[0129] The application module 33 is configured to, by invoking a function provided by the specified graphics API through the logic device, apply memory for the target application based on the memory request amount of the target application and at least two preset memory allocation units.

[0130] In a possible implementation, the application module 33 is configured to:

[0131] create a target resource for the target application by invoking a resource creation function provided by the specified graphics API through the logic device;

[0132] apply memory for the target application based on the memory request amount of the target resource and at least two preset memory allocation units by invoking a memory allocation function provided by the specified graphics API through the logic device.

[0133] In a possible implementation, the at least two preset memory allocation units include a first preset memory allocation unit and a second preset memory allocation unit, where the first preset memory allocation unit is greater than the second preset memory allocation unit.

[0134] The application module 33 is configured to:

[0135] for a part of the memory request amount of the target application that is greater than or equal to the first preset memory allocation unit, apply memory for the target application based on the first preset memory allocation unit by invoking a function provided by the specified graphics API through the logic device, and for a part of the memory request amount of the target application that is less than the first preset memory allocation unit, apply memory for the target application based on the second preset memory allocation unit by invoking a function provided by the specified graphics API through the logic device.

[0136] In a possible implementation, the application module 33 is configured to:

[0137] in response to the memory request amount of the target application being greater than or equal to the first preset memory allocation unit, repeatedly generate a first memory allocation request based on the first preset memory allocation unit by invoking a function provided by the specified graphics API through the logic device, and apply memory for the target application based on the first memory allocation request until the remaining memory request amount of the target application is less than the first preset memory allocation unit, where the memory request amount of the first memory allocation request is equal to the first preset memory allocation unit.

[0138] In response to the remaining memory request amount of the target application program being less than the first preset memory allocation unit, the logic device invokes a function provided by the specified graphics API, repeatedly generates a second memory allocation request based on the second preset memory allocation unit, and applies for memory for the target application program based on the second memory allocation request until the remaining memory request amount of the target application program is 0, wherein the memory request amount of the second memory allocation request is equal to the second preset memory allocation unit.

[0139] In a possible implementation, the type of memory applied for the target application program has host visibility and memory consistency.

[0140] In a possible implementation, the apparatus further includes:

[0141] A tracking module configured to track the memory allocated to the target application program using a dynamic array container.

[0142] In a possible implementation, the apparatus further includes:

[0143] A releasing module configured to, in response to the dynamic array container indicating that there is memory space that is no longer used by the target application program in the memory space allocated to the target application program, release the memory space that is no longer used by the target application program.

[0144] In a possible implementation, the apparatus further includes:

[0145] A destroying and releasing module configured to, in response to the target application program ending, destroy the logic device, release the target physical device, and destroy the graphics API instance.

[0146] In a possible implementation, the specified graphics API is Vulkan or Direct3D.

[0147] In some embodiments, the apparatus provided by the embodiments of the present disclosure has functions or includes modules that can be used to execute the methods described in the above method embodiments, and the specific implementation and technical effects can be referred to the description of the above method embodiments. For brevity, they will not be described here.

[0148] The embodiments of the present disclosure also provide an apparatus for memory management, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0149] The embodiments of the present disclosure also provide a non-volatile computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the steps of the above method.

[0150] The embodiment of the present disclosure further provides a computer program product, comprising a computer program or a nonvolatile computer readable storage medium carrying the computer program, and the computer program is executed by a processor to implement the steps of the above method.

[0151] Figure 4 is a block diagram of a video memory management device 1900 according to an exemplary embodiment. For example, the device 1900 can be provided as a server or terminal equipment. Referring to Figure 4 , the device 1900 comprises a processing component 1922, further comprising one or more processors, and a memory resource represented by a memory 1932, for storing instructions executable by the processing component 1922, such as an application program. The application program stored in the memory 1932 can comprise one or more than one module each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the above method.

[0152] The device 1900 can further comprise a power supply component 1926 configured to perform power management of the device 1900, a wired or wireless network interface 1950 configured to connect the device 1900 to a network, and an input output interface 1958 (I / O interface). The device 1900 can operate based on an operating system stored in the memory 1932, such as Windows Server TM , MacOS X TM , Unix TM , Linux TM , FreeBSD TM or the like.

[0153] In an exemplary embodiment, a nonvolatile computer readable storage medium is also provided, such as the memory 1932 comprising computer program instructions executable by the processing component 1922 of the device 1900 to complete the above method.

[0154] Computer readable storage media can be any media that can be read by a machine. Such media can include, but is not limited to, optical discs, magnetic discs, magnetic tapes, electronic memories, and / or any combination thereof. Computer readable storage media can be non-transitory, in that it can be a tangible medium. In some embodiments, computer readable storage media can be non-transitory, in that it can not be a signal per se. In other embodiments, computer readable storage media can be a transitory medium, in that it can be a signal. In some embodiments, computer readable storage media can be non-transitory, in that it can not be a signal per se, but can be a tangible medium. In other embodiments, computer readable storage media can be a transitory medium, in that it can be a signal. In some embodiments, computer readable storage media can be non-transitory, in that it can not be a signal per se, but can be a tangible medium. In other embodiments, computer readable storage media can be a transitory medium, in that it can be a signal.

[0155] The computer programs (or computer readable program instructions) described herein can be downloaded from a computer readable storage medium to respective computing / processing devices or external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions to storage media in respective computing / processing devices for execution.

[0156] Computer readable program instructions for carrying out operations of the present disclosure can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0157] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0158] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0159] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0160] The flow diagrams and the block diagrams in the drawings are presented to illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flow diagrams and the block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logic functions. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by dedicated hardware-based systems which perform the specified functions or acts, or combinations of hardware and software.

[0161] The computer program product can be realized by hardware, software or a combination thereof. In an optional embodiment, the computer program product is embodied as a computer storage medium. In another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (SDK) or the like.

[0162] The above description of various embodiments is directed to highlight the differences between various embodiments, and the same or similar parts can be referred to each other, and for brevity, will not be repeated herein.

[0163] If the technical solutions of the embodiments of the present disclosure involve personal information, the product applying the technical solutions of the embodiments of the present disclosure has been explicitly informed of the personal information processing rules before processing the personal information and has obtained the personal independent consent. If the technical solutions of the embodiments of the present disclosure involve sensitive personal information, the product applying the technical solutions of the embodiments of the present disclosure has obtained the personal independent consent before processing the sensitive personal information and at the same time meets the requirement of "explicit consent". For example, at the personal information collection device such as a camera, a clear and prominent mark is set to inform that the personal information collection range has been entered and the personal information will be collected. If the person voluntarily enters the collection range, it is regarded as the consent to collect the personal information. Or on the device for processing personal information, the personal information processing rules are informed by using obvious marks / information, and the personal authorization is obtained by means of pop-up information or asking the person to upload the personal information by himself / herself. The personal information processing rules can include the personal information processor, the processing purpose of personal information, the processing method, the type of processed personal information and the like.

[0164] The above has described the embodiments of the present disclosure, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, practical application or improvement of the technology in the market, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A method for managing a video memory, the method comprising: The application comprises: creating a graphics API instance corresponding to the target application, wherein the graphics API instance is an instance of a specified graphics API; identifying physical devices available in the system through the graphics API instance, and selecting a physical device to create a logical device corresponding to the target application, the logical device being an abstraction layer between the target application and the physical device, and the physical device including a GPU; calling a function provided by the specified graphics API through the logical device, and applying memory for the target application based on a memory request amount of the target application and at least two preset memory allocation units.

2. The method of claim 1, wherein, The step of applying memory for the target application based on the memory request amount of the target application and the at least two preset memory allocation units comprises: calling a resource creation function provided by the specified graphics API through the logical device to create a target resource for the target application; calling a memory allocation function provided by the specified graphics API through the logical device to apply memory for the target application based on a memory request amount of the target resource and the at least two preset memory allocation units.

3. The method according to claim 1 or 2, characterized in that, The at least two preset memory allocation units include a first preset memory allocation unit and a second preset memory allocation unit, wherein the first preset memory allocation unit is greater than the second preset memory allocation unit. The step of applying memory for the target application based on the memory request amount of the target application and the at least two preset memory allocation units comprises: for a part of the memory request amount of the target application that is greater than or equal to the first preset memory allocation unit, applying memory for the target application based on the first preset memory allocation unit through the logical device and the function provided by the specified graphics API, and for a part of the memory request amount of the target application that is less than the first preset memory allocation unit, applying memory for the target application based on the second preset memory allocation unit through the logical device and the function provided by the specified graphics API.

4. The method of claim 3, wherein, The step of applying memory for the target application based on the memory request amount of the target application and the at least two preset memory allocation units comprises: for a part of the memory request amount of the target application that is greater than or equal to the first preset memory allocation unit, applying memory for the target application based on the first preset memory allocation unit through the logical device and the function provided by the specified graphics API, and for a part of the memory request amount of the target application that is less than the first preset memory allocation unit, applying memory for the target application based on the second preset memory allocation unit through the logical device and the function provided by the specified graphics API. In response to the memory request amount of the target application being greater than or equal to the first preset memory allocation unit, the function provided by the specified graphics API is called through the logical device, a first memory allocation request is repeatedly generated based on the first preset memory allocation unit, and memory is applied for the target application based on the first memory allocation request until the remaining memory request amount of the target application is less than the first preset memory allocation unit, wherein the memory request amount of the first memory allocation request is equal to the first preset memory allocation unit. In response to the remaining memory request amount of the target application being less than the first preset memory allocation unit, the function provided by the specified graphics API is called through the logical device, a second memory allocation request is repeatedly generated based on the second preset memory allocation unit, and memory is applied for the target application based on the second memory allocation request until the remaining memory request amount of the target application is 0, wherein the memory request amount of the second memory allocation request is equal to the second preset memory allocation unit.

5. The method according to claim 1 or 2, characterized in that, The type of memory applied for the target application has host visibility and memory consistency.

6. The method of claim 1 or 2, wherein, The method further comprises: Tracking the memory allocated to the target application using a dynamic array container.

7. The method of claim 6, wherein, The method further comprises: In response to the dynamic array container indicating that there is memory space that is no longer used by the target application in the memory space allocated to the target application, releasing the memory space that is no longer used by the target application.

8. The method of claim 1 or 2, wherein, The method further comprises: In response to the target application ending, destroying the logical device, releasing the target physical device, and destroying the graphics API instance.

9. The method of claim 1, wherein, The specified graphics API is Vulkan or Direct3D.

10. A video memory management device, comprising: Comprise: A creating module for creating a graphics API instance corresponding to a target application, wherein the graphics API instance is an instance of a specified graphics API; An identifying and creating module for identifying available physical devices in a system through the graphics API instance and selecting a physical device to create a logical device corresponding to the target application, the logical device being an abstraction layer between the target application and the physical device, and the physical device including a GPU; An applying module for calling a function provided by the specified graphics API through the logical device, applying memory for the target application based on a memory request amount of the target application and at least two preset memory allocation units.

11. A video memory management device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 9.

12. A non-transitory computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 9.

13. A computer program product comprising a computer program or a non-transitory computer readable storage medium bearing a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 9.

Images