Video memory access method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a video memory access method and device, electronic equipment, a storage medium and a program product, and relates to the field of computers. The kernel layer indicates the application layer to access the video memory of the target GPU through a direct mapping mechanism according to the target information, so as to realize low-delay and high-bandwidth video memory access; when the target size of the to-be-allocated video memory is larger than the target BAR space and smaller than or equal to the video memory size of the target GPU, the kernel layer indicates the application layer to access the video memory of the target GPU through the sliding window mapping mechanism through the target information, so that the function integrity is guaranteed. In this way, the system can adapt to BAR spaces and video memory configurations of different GPUs, and the overall performance of the system can be improved.

Description

Technical Field

[0001] This application belongs to the field of computers, and specifically relates to a video memory access method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] In high-performance computing systems based on the Peripheral Component Interconnect Express (PCIe) bus, the integration of multiple types of graphics processing units (GPUs) has become commonplace. These GPUs differ in hardware design, and the size of their base address register (BAR) spaces within the PCIe configuration space also varies. Currently, the system allocates fixed BAR spaces to different GPUs; some GPUs are configured with larger BAR spaces to support efficient memory mapping, while others are configured with smaller BAR spaces due to insufficient space.

[0003] However, this heterogeneity of hardware resources may affect the overall performance of the system. Summary of the Invention

[0004] Therefore, the purpose of this application is to provide a video memory access method, apparatus, electronic device, computer-readable storage medium, and computer program product, so that the system can adapt to the BAR space and video memory configuration of different GPUs.

[0005] The embodiments of this application are implemented as follows: In a first aspect, embodiments of this application provide a video memory access method applied at the application layer. The method includes: sending a request message to a kernel layer, the request message requesting a target size of unallocated video memory; receiving target information from the kernel layer; when the target information indicates that the target size is less than or equal to the size of a target BAR space, accessing the video memory of the target GPU through a direct mapping mechanism, wherein the direct mapping mechanism completely maps the GPU's video memory into the BAR space to access the video memory through a fixed address translation relationship; when the target information indicates that the target size is greater than the size of the target BAR space, and the target size is less than or equal to the size of the target GPU's video memory, accessing the target GPU's video memory through a sliding window mapping mechanism, wherein the sliding window mapping mechanism dynamically remaps a fixed-size BAR window to different regions of the video memory to access the entire video memory through a variable address translation relationship; wherein the target GPU is a GPU determined based on the request message, and the target BAR space is a BAR space already configured for the target GPU.

[0006] Based on the first aspect of the method, when the target size of the video memory to be allocated is less than or equal to the target BAR space, the video memory of the target GPU requested by the application layer can be completely mapped to the target BAR space. In this case, the application layer can access the video memory of the target GPU through a direct mapping mechanism to achieve low-latency, high-bandwidth video memory access. When the target size of the video memory to be allocated is greater than the target BAR space but less than or equal to the size of the target GPU's video memory, the video memory of the target GPU requested by the application layer cannot be completely mapped to the BAR space. In this case, the application layer can access the video memory of the target GPU through a sliding window mapping mechanism to ensure functional integrity. Compared to the system uniformly setting a mapping method (such as direct mapping or sliding window mapping) for all GPUs during initialization, this method can avoid the functional limitations of GPUs with smaller BAR spaces due to the inability to fully map video memory, and can also prevent the performance potential of GPUs with larger BAR spaces from being underutilized, thus avoiding the waste of the inherent low-latency access advantage of those GPUs. In this way, the system can adapt to the BAR space and video memory configurations of different GPUs, thereby improving the overall performance of the system. In addition, this method can increase the number of GPUs mounted on the system. For example, half of the BAR space originally configured in the system with the same size as the GPU memory can be allocated to the memory of other GPUs, thereby improving the overall computing power of the system.

[0007] In one possible implementation, the method in the first aspect further includes: if the target information indicates that the target size is greater than the target BAR space size and the target size is greater than the target GPU memory size, returning an error code to the requester who initiated the request message. This allows for timely notification to the requester that its request cannot be fulfilled, enabling the requester to adopt degradation strategies such as reducing resource requirements or using alternatives (e.g., system memory), improving application adaptability and user experience, and preventing the requester from waiting indefinitely, which could lead to unpredictable errors.

[0008] Secondly, embodiments of this application provide a video memory access method applied to a kernel interface. The method includes: receiving a request message from an application layer, the request message requesting a target size of video memory to be allocated; and in response to the request message, sending target information to the application layer. Wherein, if the target size is less than or equal to the size of a target BAR space, the target information instructs the application layer to access the video memory of the target GPU through a direct mapping mechanism, wherein the direct mapping mechanism completely maps the GPU's video memory into the BAR space to access the video memory through a fixed address translation relationship; if the target size is greater than the size of the target BAR space and the target size is less than or equal to the size of the target GPU's video memory, the target information instructs the application layer to access the target GPU's video memory through a sliding window mapping mechanism, wherein the sliding window mapping mechanism dynamically remaps a fixed-size BAR window to different regions of the video memory to access the entire video memory through a variable address translation relationship; the target BAR space is the BAR space configured for the target GPU, and the target GPU is the GPU determined based on the request message.

[0009] In one possible implementation, if the target size is greater than the target BAR space size and the target size is greater than the target GPU memory size, the target information is used to instruct the application layer to return an error code to the requester that initiated the request message.

[0010] In one possible implementation, the method further includes: obtaining the video memory size of the target GPU from the driver module corresponding to the target GPU by calling a first interface function. It is understood that the kernel interface can quickly and accurately obtain the video memory size of the target GPU from the driver module corresponding to the target GPU during initialization by calling the first interface function, thereby facilitating the subsequent determination of application-layer operations based on the video memory size of the target GPU.

[0011] Furthermore, the technical effects of the method described in the second aspect can also refer to the technical effects of the method described in the first aspect, and will not be repeated here.

[0012] Thirdly, embodiments of this application provide a video memory access method applied at the application layer. The method includes: receiving a request message for requesting a target capacity of video memory to be allocated; responding to the request message, obtaining the size of a target BAR space and the size of the video memory of a target GPU, wherein the target BAR space is a BAR space already configured for the target GPU, and the target GPU is a GPU determined based on the request message; when the target size is less than or equal to the size of the target BAR space, accessing the video memory of the target GPU through a direct mapping mechanism, wherein the direct mapping mechanism completely maps the GPU's video memory into the BAR space to access the video memory through a fixed address translation relationship; when the target size is greater than the size of the target BAR space and the target size is less than or equal to the size of the video memory of the target GPU, accessing the video memory of the target GPU through a sliding window mapping mechanism, wherein the sliding window mapping mechanism dynamically remaps a fixed-size BAR window to different regions of the video memory to access the entire video memory through a variable address translation relationship.

[0013] Based on the third aspect of the method, when the target size of the video memory to be allocated is less than or equal to the target BAR space, the video memory of the target size can be completely mapped to the target BAR space. In this case, the application layer can access the video memory of the target GPU through a direct mapping mechanism to achieve low-latency, high-bandwidth video memory access. When the target size of the video memory to be allocated is greater than the target BAR space but less than or equal to the target GPU's video memory size, the video memory of the target GPU requested by the application layer cannot be completely mapped to the BAR space. In this case, the application layer can access the video memory of the target GPU through a sliding window mapping mechanism to ensure functional integrity. In this way, the system can adapt to the BAR space and video memory configuration of different GPUs, thus solving the problem of mismatch between the traditional single mapping strategy and heterogeneous hardware configuration.

[0014] In one possible implementation, the method described in the third aspect further includes: returning an error code to the requester that initiated the request message if the target size is larger than the target BAR space size and the target size is larger than the target GPU's video memory size. This prevents a single application from exhausting too much video memory resources, leading to system instability; and allows the requester to be promptly informed that the request cannot be fulfilled, enabling the requester to adopt degradation strategies such as reducing resource requirements or using alternatives (such as system memory), thereby improving application adaptability and user experience.

[0015] In one possible implementation, obtaining the size of the target BAR space and the target GPU's video memory size includes: calling a first interface function and obtaining a resource information structure returned by the first interface function; wherein, the first field of the resource information structure carries the target BAR space size, and the second field of the resource information structure carries the target GPU's video memory size. This merges the queries for two key hardware resources into a single atomic operation, improving query efficiency and ensuring the consistency of resource information, thus providing a reliable data foundation for system resource management. Furthermore, this method has good scalability, facilitating the subsequent addition of other hardware resource information.

[0016] In one possible implementation, the invocation of the first interface function includes: invoking the first interface function based on the input / output control (IOCTL) mechanism. This improves the flexibility in obtaining the size of the target BAR space and the target GPU's video memory.

[0017] Fourthly, embodiments of this application provide a video memory access method applied to the firmware of a target GPU. The method includes: configuring the identification information of the target GPU and the video memory size of the target GPU during firmware initialization; storing the identification information and the video memory size in a firmware storage area so that the driver of the target GPU can obtain the identification information and the video memory size during initialization.

[0018] Based on the method in the fourth aspect, storing the identification information and the video memory size in the firmware storage area enables the driver (side) of the target GPU to obtain the identification information and the video memory size during initialization, and facilitates the kernel interface to obtain the video memory size of the target GPU from the driver of the target GPU, so as to determine the subsequent operation of the application layer based on the video memory size of the target GPU when the application layer requests video memory from the kernel layer.

[0019] Fifthly, embodiments of this application provide a video memory access method applied to a driver module of a target GPU. The method includes: calling a second interface function, the input parameters of which include a device pointer and a memory pointer, the device pointer indicating the target GPU to be queried; obtaining the identification information of the target GPU from the return value of the second interface function; and obtaining the video memory size of the target GPU from the address pointed to by the memory pointer. The second interface function obtains resource data by accessing the firmware storage area of ​​the target GPU, and obtains the identification information and video memory size by parsing the resource data.

[0020] Based on the method in the fifth aspect, it can be seen that the driver module of the target GPU can quickly and accurately obtain the video memory size of the target GPU by calling the second interface function during driver initialization, thereby facilitating the kernel interface to obtain the video memory size of the target GPU from the driver module of the target GPU.

[0021] A sixth aspect provides a video memory access device. The device includes a module for performing the method in any possible implementation of any of the preceding aspects.

[0022] Furthermore, the technical effects of the video memory access device described in the sixth aspect can be referenced from the technical effects of the methods in any possible implementation of any of the above aspects, and will not be repeated here.

[0023] A seventh aspect provides an electronic device comprising: a processor and a memory connected together; wherein the memory is used to store a program, and the processor is used to invoke the program stored in the memory to execute a method as described in any of the possible implementations of any of the preceding aspects.

[0024] Eighthly, a computer-readable storage medium is provided that stores a computer program or instructions, which, when executed, cause a computer to perform the method in any possible implementation of any of the preceding aspects.

[0025] Ninthly, a computer program product is provided, the computer program product comprising: a computer program or instructions, which, when executed, cause the method in any possible implementation of any of the preceding aspects to be performed. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings.

[0027] Figure 1 A structural block diagram of the software system provided in the embodiments of this application; Figure 2 A flowchart illustrating the video memory access method provided in the embodiments of this application. Figure 1 ; Figure 3 A schematic diagram illustrating the operation of the GPU firmware module provided in an embodiment of this application; Figure 4 A schematic diagram of the application layer operation provided in the embodiments of this application. Figure 1 ; Figure 5 A schematic diagram illustrating the operation of the kernel interface provided in the embodiments of this application; Figure 6 A flowchart illustrating the video memory access method provided in the embodiments of this application. Figure 2 ; Figure 7 A schematic diagram of the application layer operation provided in the embodiments of this application. Figure 2 ; Figure 8 A schematic diagram of the application layer operation provided in the embodiments of this application. Figure 3 ; Figure 9 This is a schematic diagram of the structure of the video memory access device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] To facilitate understanding, the technical terms involved in this solution will be introduced below.

[0029] 1. Software System The software system of the electronic device described in this application can adopt a layered architecture. A layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. For example... Figure 1 As shown, in some embodiments, a software system (such as an operating system) can be divided into five layers, from top to bottom: application layer, application framework layer, system runtime library layer, hardware abstraction layer, and kernel layer.

[0030] The application layer, as the top layer for system-user interaction, contains a series of native applications, such as clock, calendar, gallery, and video. This layer responds to user actions and generates corresponding display and processing requirements.

[0031] The application framework layer provides application programming interface (API) services and a programming framework to the application layer. It includes components such as window management services and activity management services, and is responsible for application lifecycle management, UI rendering, and event dispatching.

[0032] The system runtime library layer provides core system libraries and runtime support to the upper layers. Among them, the surface manager is responsible for managing the display interface; the 3D graphics processing library and the 2D graphics engine provide support for graphics rendering; and the image compositing module and the display compositing module are specifically responsible for compositing multiple application layers and sending the final image to the display device.

[0033] The hardware abstraction layer can serve as a bridge connecting software and hardware, abstracting the underlying hardware driver interface into a unified software interface.

[0034] As the core of the operating system, the kernel layer directly manages and drives hardware devices. Through its provided kernel interfaces and device driver modules (such as driver modules for different types of GPUs), the kernel layer achieves unified scheduling and management of hardware resources. The kernel interface is a set of predefined programming interfaces provided by the kernel layer to higher layers (the hardware abstraction layer and higher) for accessing kernel functions and hardware resources. The GPU's device driver module is used to control and manage the GPU hardware, such as identifying the GPU device model, loading the corresponding driver, and completing hardware initialization configuration during system startup. Furthermore, in this application, the kernel layer may include device driver modules for various types of GPUs. And in this application, the device driver module may also be called a driver module or a device module, without limitation.

[0035] 2. Direct mapping mechanism Direct mapping is an access mechanism that linearly and completely maps the entire GPU memory into the system's physical address space. In other words, direct mapping maps the GPU's memory completely into the BAR (Browser Address Range) space, allowing access to the memory through a fixed address translation relationship.

[0036] In the direct mapping method, the system pre-maps the entire GPU memory space statically and linearly to a contiguous region in the central processing unit (CPU) physical address space, which constitutes the BAR space. When the application layer translates its virtual address into a CPU physical address, if the physical address falls within the pre-mapped BAR space, access to that address will be directly routed to the corresponding GPU memory location.

[0037] The advantage of direct mapping is that the access path is direct and the latency is extremely low, which can provide the GPU with the maximum instantaneous bandwidth. However, as the size of video memory increases, and this method requires an equivalent amount of system physical address space, it will quickly exhaust the limited system address resources in servers with multiple GPUs, constituting a serious scalability bottleneck.

[0038] 3. Sliding window mapping mechanism The sliding window mapping mechanism allocates a small, fixed-size BAR mapping window to the GPU's video memory, and dynamically switches the memory region mapped by this window to achieve access to the entire video memory. In other words, the sliding window mapping mechanism dynamically remaps a fixed-size BAR window to different regions of video memory, so as to access the entire video memory through variable address translation relationships.

[0039] In the sliding window mapping method, the system allocates a fixed-size mapping window for the GPU memory, which corresponds to a finite region in the CPU physical address space. When the application layer translates its virtual address into a CPU physical address, the address is first mapped into the currently active window range. If the memory location to be accessed exceeds the current window range, the driver needs to dynamically switch the window position to the target region through a remapping mechanism before accessing the target memory can be completed. In this application, the sliding window mapping method can refer to the application layer dynamically mapping the address space (i.e., the CPU-accessible physical address space to which the application layer translates its virtual address) to the BAR space through a sliding window mechanism, and then accessing the target GPU memory through the target BAR space.

[0040] While sliding window mapping greatly saves system address resources, it comes at the cost of introducing additional address translation and management overhead. In applications that require frequent random access to a large number of video memory addresses, this can lead to significant performance degradation and latency jitter.

[0041] It is understood that the above direct mapping mechanism and the above sliding window mapping mechanism can be understood by referring to the relevant introductions in the existing technology, and will not be repeated here.

[0042] Currently, the system can allocate fixed BAR space to different GPUs. For example, the system can allocate a larger BAR space to some GPUs, with the size of the BAR space equal to the size of the GPU's video memory; the system can allocate a smaller BAR space to other GPUs, with the size of the BAR space smaller than the size of the GPU's video memory. This heterogeneity in hardware resources can affect the overall performance of the system. For example, if all GPUs use a direct mapping mechanism, those with smaller BAR spaces will be limited in function because they cannot fully map their video memory; if all GPUs use a sliding window mapping mechanism, the performance potential of those with larger BAR spaces cannot be fully realized, and their inherent low-latency access advantage is wasted.

[0043] To address the aforementioned technical issues, this application proposes that when the target size of the allocated video memory is less than or equal to the target BAR space, the kernel layer can instruct the application layer to access the target GPU's video memory through a direct mapping mechanism via target information; when the target size of the allocated video memory is greater than the target BAR space but less than or equal to the target GPU's video memory size, the kernel layer can instruct the application layer to access the target GPU's video memory through a sliding window mapping mechanism via target information. Compared to the system uniformly setting a mapping method (such as direct mapping or sliding window mapping) for all GPUs during initialization, this method avoids the limitation of GPUs with smaller BAR spaces due to incomplete video memory mapping, and also avoids the underutilization of the performance potential of GPUs with larger BAR spaces, thus preventing the waste of their inherent low-latency access advantages. This allows the system to adapt to the BAR space and video memory configurations of different GPUs, thereby improving the overall system performance. Furthermore, this method can increase the number of GPUs mounted on the system, such as allocating half of the BAR space originally configured in the system to the same size as the GPU's video memory for use by other GPUs, thereby improving the overall computing power of the system.

[0044] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The following embodiments are provided as examples to more clearly illustrate the technical solutions of this application, and should not be used to limit the scope of protection of this application. Those skilled in the art will understand that, without conflict, the following embodiments and features can be combined with each other.

[0045] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, relational terms such as "first," "second," etc., in the description of this application are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0046] This application provides a method for accessing video memory, which can be applied to electronic devices (also known as host systems). The electronic device includes a hardware system (such as one containing a CPU and memory) and a software system running on it (such as...). Figure 1 (The software system shown). In this application, unless otherwise specified, "system" refers to the electronic device or the host system. The CPU of the electronic device communicates with one or more GPUs via a PCIe bus. These GPUs may be integrated internally within the electronic device or connected via PCIe expansion slots.

[0047] Please see Figure 2 , Figure 2 A flowchart illustrating a video memory access method provided in this application embodiment. Figure 1 The video memory access method includes: S201, the application layer sends a request message to the kernel layer. Correspondingly, the kernel layer (such as a kernel interface or a separately configured functional module within the kernel layer) receives the request message from the application layer.

[0048] For details on the application layer and kernel layer, please refer to the relevant introduction in "1. Software System" above, which will not be repeated here.

[0049] The above request message is used to request (or apply for) the target size of unallocated video memory.

[0050] The target size can be determined based on the amount of video memory required by the requester (i.e., a specific application scenario or instance). For example, in a video editing scenario, when a user plays a video sequence containing multiple video tracks, real-time effects, and motion graphics on the timeline, the requester can calculate the total amount of video memory required by analyzing the resource composition of the current timeline. This total amount of video memory is the target size of the video memory requested by the application layer from the kernel layer. The target size of the video memory to be allocated can be represented in bytes, address ranges, etc., without any restrictions.

[0051] The allocation of video memory can be determined by a coordination method within the system. In this case, when the application layer sends a request message to the kernel layer, the application layer does not instruct the kernel layer to allocate video memory from a specific GPU in the system. Instead, the system selects a GPU's video memory for the application layer based on the coordination method. This coordination method can be to select the GPU with the most remaining video memory in the current system, or the GPU with the lightest computational load in the current system, or other strategies, without limitation. It is understood that the specific implementation of the system selecting a GPU based on the coordination method can refer to existing technologies, and will not be elaborated here.

[0052] The allocation of video memory can also be indicated by the application layer. That is, the application layer can request video memory from the kernel layer for a specific GPU. In this case, the application layer can carry GPU identification information in the request message to indicate to the kernel layer the video memory of the GPU it is requesting.

[0053] In this embodiment of the application, the request message can be initiated by the request method and sent to the kernel layer through the application layer, so that the kernel layer can divide a region of a specified size in the target GPU (described below) and map it into the virtual address space of the application layer, so that the application layer can use the corresponding video memory resources by accessing the virtual address.

[0054] S202, In response to the request message, the kernel interface sends target information to the application layer. Correspondingly, the application layer receives the target information from the kernel interface.

[0055] After receiving a request message from the application layer, the kernel interface can obtain the size of the target BAR space configured for the target GPU and the size of the target GPU's video memory. Based on the relationship between the requested video memory to be allocated, the target BAR space, and the size of the target GPU's video memory, the kernel interface instructs the application layer on how to access the target GPU's video memory through the target BAR space. This will be explained in detail below.

[0056] In the first possible implementation, when the target size is less than or equal to the target BAR space size, the target information is used to instruct the application to access the target GPU's video memory through a direct mapping mechanism, which maps the GPU's video memory completely into the BAR space to access the video memory through a fixed address translation relationship.

[0057] The target BAR space is the BAR space already configured for the target GPU. It can be understood that BAR space allocation is completed during system startup by the system firmware (basic input / output system (BIOS) or unified extensible firmware interface (UEFI)) or the operating system kernel (such as the kernel layer) during the PCIe enumeration process, and BAR space allocation is a one-time event during system startup. In other words, the target BAR space is the BAR space configured for the target GPU during system startup.

[0058] The target GPU is determined based on the request message. In this embodiment, if the video memory to be allocated is determined by a coordination method in the system, the target GPU is the GPU determined by the system for the application layer through the coordination method; if the video memory to be allocated is indicated by the application layer, the target GPU is the GPU indicated by the application layer.

[0059] The target information can be an identifier, such as a success identifier. That is, the success identifier can instruct the application layer to access the target GPU's video memory through the target BAR space in the way that the address space is directly mapped to the BAR space.

[0060] The above direct mapping mechanism can be understood by referring to the relevant introduction in "2. Direct Mapping Method" above, and will not be repeated here.

[0061] In this embodiment, the kernel layer can compare the target size of the video memory requested by the application layer with the size of the target BAR space, or determine whether the target size is smaller than the size of the target BAR space. When the target size is less than or equal to the size of the target BAR space, the video memory of the target GPU requested by the application layer can be completely mapped to the target BAR space. In this case, the kernel interface can send target information to the application layer to instruct the application layer to access the video memory of the target GPU through a direct mapping mechanism. In other words, after receiving the target information, the application layer can access the video memory of the target GPU through a direct mapping mechanism based on the target information.

[0062] In the second possible implementation, when the target size is larger than the target BAR space size and the target size is smaller than or equal to the target GPU's video memory size, the target information is used to instruct the application layer to access the target GPU's video memory through a sliding window mapping mechanism. This sliding window mapping mechanism dynamically remaps a fixed-size BAR window to different regions of video memory, so as to access the entire video memory through a variable address translation relationship.

[0063] The target BAR space and target GPU can be found in the above-mentioned introductions, and will not be repeated here.

[0064] The target information can be identification information, such as an out-of-bar memory (BAR) flag. That is, the out-of-bar memory flag can instruct the application layer to access the target GPU's video memory through a sliding window mapping mechanism.

[0065] The sliding window mapping mechanism can be understood by referring to the relevant introduction in "3. Sliding Window Mapping Method" above, and will not be repeated here.

[0066] In this embodiment, when the target size of the video memory to be allocated is greater than the target BAR space but less than or equal to the target GPU's video memory size, the video memory of the target GPU requested by the application layer cannot be completely mapped to the BAR space. In this case, the kernel interface can send target information to the application layer to instruct the application layer to access the target GPU's video memory through a sliding window mapping mechanism. Furthermore, in this embodiment, the kernel layer can first compare the target size of the video memory to be allocated requested by the application layer with the size of the target BAR space. If the target size is greater than the target BAR space, it can then compare the target size with the target GPU's video memory size. Alternatively, it can determine whether the target size is less than the target GPU's video memory size, and if the target size is less than or equal to the target GPU's video memory size, it can send target information to the application layer.

[0067] As can be understood, the above content describes different ways in which the kernel layer instructs the application layer to access the target GPU's video memory through the target BAR space under different circumstances. In the two possible implementations described above (i.e., the first and second possible implementations), different target information can be set to instruct the application layer on different operations, namely, accessing the target GPU's video memory through a direct mapping mechanism or through a sliding window mapping mechanism. For example, in the first possible implementation, the target information can be represented as a first identifier, such as the success identifier mentioned above; in the second possible implementation, the target information can be represented as a second identifier, such as the out-of-BAR space identifier mentioned above. For the application layer, upon receiving the first identifier, it accesses the target GPU's video memory through the direct mapping mechanism; or, upon receiving the second identifier, it accesses the target GPU's video memory through the sliding window mapping mechanism.

[0068] In both possible implementations described above, where the allocated video memory is determined by a coordination method within the system, the kernel layer can also send the target GPU's identification information, such as its identifier (ID), to the application layer to indicate the video memory resources to be allocated to it. Upon receiving the target GPU's identification information from the kernel interface, the application layer can identify the target GPU and use its video memory. Furthermore, the target GPU's identification information can be sent together with the target information, or they can be sent sequentially, such as sending the target GPU's identification information first, followed by the target information, or vice versa; there are no restrictions.

[0069] S203, if the target information indicates that the target size is less than or equal to the target BAR space size, the application layer accesses the target GPU's video memory through a direct mapping mechanism; if the target information indicates that the target size is greater than the target BAR space size, and the target size is less than or equal to the target GPU's video memory size, the application layer accesses the target GPU's video memory through a sliding window mapping mechanism.

[0070] In other words, the application layer can perform different operations based on the different contents represented by the target information.

[0071] It is understandable that the kernel interface can send different target information to the application layer under different circumstances to instruct the application layer to perform different operations. For details, please refer to the relevant introduction in "S203" above, which will not be repeated here.

[0072] In summary, in this embodiment, when the target size of the video memory to be allocated is less than or equal to the target BAR space, the video memory of the target GPU requested by the application layer can be completely mapped to the target BAR space. In this case, the application layer can access the video memory of the target GPU through a direct mapping mechanism to achieve low-latency, high-bandwidth video memory access. When the target size of the video memory to be allocated is greater than the target BAR space but less than or equal to the size of the target GPU's video memory, the video memory of the target GPU requested by the application layer cannot be completely mapped to the BAR space. In this case, the application layer can access the video memory of the target GPU through a sliding window mapping mechanism to ensure functional integrity. This allows the system to adapt to the BAR space and video memory configurations of different GPUs, thus solving the problem of mismatch between traditional single mapping strategies and heterogeneous hardware configurations. Furthermore, by instructing the application layer to perform appropriate access operations under different circumstances, optimal utilization of hardware resources can be achieved.

[0073] Optionally, in conjunction with the above embodiments, when the target size is larger than the target BAR space size and the target size is larger than the target GPU memory size, the target information is used to instruct the application layer to return an error code to the requester who initiated the request message.

[0074] The target BAR space and target GPU can be found in the relevant introduction in "S202" above, and will not be repeated here.

[0075] The target information can be identification information, such as an out-of-membrane flag. In other words, the out-of-membrane flag can instruct the application layer to return an error code to the requester.

[0076] The requester can be a specific application scenario or a specific instance. For example, in a video editing scenario, when a user plays a specific video sequence instance containing multiple video tracks, real-time effects, and motion graphics on the timeline, that instance (or the processing logic corresponding to that instance) can act as the requester. The requester can analyze its resource composition, calculate the total amount of video memory required, and thereby drive the application layer to request the target size of video memory from the kernel layer.

[0077] Error codes can be used to indicate that a request for allocated video memory of the target size failed, or in other words, that the kernel layer did not provide allocated video memory of the target size. The specific representation of the error code can be flexibly set according to the actual situation and is not restricted.

[0078] In this embodiment, when the target size of the video memory to be allocated is greater than the target BAR space and greater than the target GPU's video memory size, the target GPU's video memory size cannot meet the target size of the video memory requested by the application layer. In this case, the application layer's request to allocate video memory fails. The kernel interface can send target information to the application layer to instruct it to return an error code to the requester, thus notifying the requester that the video memory allocation request has failed. This prevents a single application from exhausting too much video memory resources, leading to system instability; and it allows the requester to be promptly informed that the request cannot be fulfilled, enabling the requester to adopt degradation strategies such as reducing resource requirements or using alternatives (such as system memory), thereby improving application adaptability and user experience.

[0079] Furthermore, in this embodiment, the kernel layer can first compare the target size of the video memory to be allocated requested by the application layer with the size of the target BAR space. If the target size is greater than the size of the target BAR space, the kernel layer can then compare the target size with the video memory size of the target GPU. If the target size is greater than the video memory size of the target GPU, the kernel layer can send the target information to the application layer.

[0080] Furthermore, the above method may also include: when the target information indicates that the target size is greater than the target BAR space size, and the target size is greater than the target GPU memory size, the application layer returns an error code to the requester that initiated the request message.

[0081] In other words, after receiving the aforementioned target information, the application layer can return an error code to the requester who initiated the request message based on this target information. In this way, the requester can be notified in a timely manner that its request cannot be fulfilled, enabling the requester to take degradation strategies such as reducing resource requirements and using alternative solutions (such as system memory), thereby improving the application's adaptability and user experience, and avoiding the requester waiting indefinitely, which could lead to unpredictable errors.

[0082] Optionally, in conjunction with the above embodiments, the above method may further include: during the firmware initialization of the target GPU, configuring the identification information of the target GPU and the video memory size of the target GPU in the firmware storage area, so that the driver (i.e., the driver module) of the target GPU can obtain the identification information and the video memory size during initialization.

[0083] GPU firmware is a low-level software system that runs on a dedicated microcontroller in a GPU system. It sits between the hardware and the drivers and is the basic support layer for GPU functionality. The specific principles of GPU firmware can be found in existing technologies, and will not be elaborated here.

[0084] The identification information of the target GPU is used to indicate the target GPU, which can be the target GPU's ID, product identifier, etc.

[0085] The firmware storage area can be a (hardware) register, without any restrictions.

[0086] In this embodiment, the identification information of the target GPU and the video memory size of the target GPU are related. Storing the identification information and the video memory size in the firmware storage area enables the driver (side) of the target GPU to obtain the identification information and the video memory size during initialization, and facilitates the kernel interface to obtain the video memory size of the target GPU from the driver of the target GPU. This is used to determine the subsequent operations of the application layer based on the video memory size of the target GPU when the application layer requests video memory from the kernel layer.

[0087] It is understood that, in this embodiment, after configuring the target GPU's firmware with the target GPU's identification information and memory size, the target GPU may not store the memory size itself, but instead store a sequence number indicating the memory size. After obtaining the identification information and the sequence number, the target GPU's driver module can find the memory size based on the sequence number. In this embodiment, the correspondence between different sequence numbers and different memory sizes can be pre-set in the system.

[0088] Furthermore, when there are multiple GPUs in the system, the firmware of each GPU can configure the GPU's identification information and the GPU's video memory size, and store the identification information and the video memory size (or the sequence number used to indicate the video memory size) in the firmware storage area corresponding to the GPU.

[0089] Furthermore, the above method may also include: the driver module of the target GPU calling a second interface function, the input parameters of which include a device pointer and a memory pointer, the device pointer being used to indicate the target GPU to be queried; the driver module of the target GPU obtaining the identification information of the target GPU from the return value of the second interface function, and obtaining the video memory size of the target GPU from the address pointed to by the memory pointer; wherein, the second interface function obtains resource data by accessing the firmware storage area of ​​the target GPU, and obtains the identification information and video memory size of the target GPU by parsing the resource data.

[0090] The driver module of the target GPU can be understood as the driver side of the target GPU, and it can be understood as a driver instance that creates and manages the resources of the target GPU. The driver module of the target GPU resides in the kernel layer.

[0091] The second interface function can be an interface function pre-set in the driver module of the target GPU. The return value of this second interface function can be the identification information of the target GPU. The above-mentioned method of obtaining the target GPU's video memory size from the address pointed to by the memory pointer can be understood as: obtaining data (such as register data) from the address pointed to by the memory pointer, and obtaining the target GPU's video memory size by parsing this data.

[0092] In this embodiment of the application, the driver module of the target GPU can quickly and accurately obtain the video memory size of the target GPU by calling the second interface function during driver initialization, thereby facilitating the kernel interface to obtain the video memory size of the target GPU from the driver module of the target GPU.

[0093] It's understandable that when the target GPU's firmware stores a sequence number indicating the target GPU's video memory size, the data retrieved from the address pointed to by the memory pointer is parsed to obtain this sequence number. In this case, the target GPU's driver module can find the corresponding video memory size based on this sequence number, and this video memory size is the target GPU's video memory size.

[0094] Furthermore, when there are multiple GPUs in the system, the driver modules of each GPU can obtain the video memory size of that GPU in the manner described above.

[0095] Furthermore, when the system includes multiple types of GPUs, including standard cards and non-standard cards (also known as custom cards), in this case, the firmware of the non-standard card can be configured with its corresponding identification information, card identification number, and video memory size, and the card identification number, identification information, and video memory size can be stored in the firmware storage area corresponding to the non-standard card. For example, as shown... Figure 3As shown, during GPU firmware initialization, the GPU firmware module can first obtain the GPU's video memory size, then set the GPU's card identification number, i.e., set whether the GPU is a non-standard card, and finally configure the register bits according to the GPU's video memory size, i.e., store the GPU's video memory in the firmware storage area.

[0096] GPUs can be categorized by their product generations; for example, each generation of GPUs can be defined as a type. It is understood that GPUs of different types can also be configured according to other rules without restriction. In the embodiments of this application, standard or non-standard GPUs belonging to the same type have the same video memory size.

[0097] A standard GPU can be understood as a GPU that fully conforms to the specifications defined by industry standards organizations. A non-standard GPU can be understood as a GPU whose hardware design deviates from industry standard specifications. Furthermore, non-standard GPUs are typically customized according to customer requirements. It is understood that the distinction between standard and non-standard GPUs can be understood by referring to relevant descriptions in existing technologies; further details will not be elaborated upon here.

[0098] The card identification number can be used to distinguish between standard cards and non-standard cards; that is, standard cards and non-standard cards have different card identification numbers.

[0099] Typically, standard graphics cards store their corresponding video memory size in their firmware, while non-standard graphics cards do not store their corresponding video memory size in the system. Configuring the identification information and video memory size of the non-standard graphics card in its firmware and storing this information in the corresponding firmware storage area allows the kernel interface to easily obtain the video memory size of the non-standard graphics card from its driver.

[0100] In this embodiment, when the system includes multiple types of GPUs, including standard and non-standard GPUs, the GPU driver module can first determine the type of GPU during initialization, and obtain the GPU's card identification number, identification information, and register data containing the video memory size from the GPU firmware based on the second interface function. Then, the GPU driver module can determine whether the GPU is a standard or non-standard GPU based on the card identification number, and determine the method for parsing the register data based on the GPU type and whether the GPU is a standard or non-standard GPU. Finally, the register data is parsed based on this method to obtain the GPU's video memory size.

[0101] It is understandable that GPU type information can be pre-stored in registers, and the GPU driver module can determine the GPU type based on the type information read from these registers. The GPU type information can be stored in the same location or a different location than the GPU's identification information, card identifier, and video memory size.

[0102] Furthermore, the above content describes configuring the GPU's video memory size in the GPU firmware, and how the GPU driver module obtains the GPU's video memory size from the GPU firmware during driver initialization. After the GPU driver module obtains the GPU's video memory size, the kernel interface can obtain the GPU's video memory size from the GPU driver module.

[0103] For example, before the kernel interface sends the target information to the application layer, the above method may further include: obtaining the video memory size of the target GPU from the driver module corresponding to the target GPU by calling the first interface function.

[0104] During initialization, the kernel interface can quickly and accurately obtain the target GPU's video memory size from the driver module corresponding to the target GPU by calling the first interface function. This facilitates the subsequent determination of application layer operations based on the size of the target BAR space and the target GPU's video memory size.

[0105] Furthermore, when there are multiple GPUs in the system, the kernel interface can obtain the size of the BAR space and the size of the video memory of each GPU from the driver module of each GPU by calling the first interface function during initialization.

[0106] The kernel interface can also obtain the target BAR space size of the target GPU from the system during initialization. Furthermore, when multiple GPUs exist in the system, the kernel interface can obtain the BAR space size of each of these GPUs from the system.

[0107] It is understood that the above content describes the operation of the kernel interface obtaining the target GPU's video memory size and target BAR space size during initialization. In the embodiments of this application, the kernel interface may also omit the operation of obtaining the target GPU's video memory size and target BAR space size during initialization, and instead obtain the target BAR space size when it is needed, and the target GPU's video memory size when it is needed. For example, the kernel interface may obtain the target BAR space size when determining the relationship between the target size and the target BAR space size; if the target size is larger than the target BAR space size, it may obtain the target GPU's video memory size when determining the relationship between the target size and the target GPU's video memory size.

[0108] The above content describes the methods for accessing video memory. For example... Figure 4As shown, in this method, the application layer mainly sends a request message to the kernel layer and receives the target information returned by the kernel layer in response to the request message, and performs corresponding operations. For example, when the target information is a success flag, the application layer accesses the target GPU's video memory through a direct mapping mechanism; when the target information is a BAR space exceedance flag, the application layer accesses the target GPU's video memory through a sliding window mapping mechanism; when the target information is a video memory insufficiency flag, the application layer returns an error code to the requester.

[0109] like Figure 5 In this method, the kernel interface mainly operates during the initialization phase by obtaining the BAR space size of each GPU from the system and the video memory size of each GPU from its driver module. After receiving a request message from the application layer, the kernel interface first determines whether the target size carried in the request message is smaller than the target BAR space size. If the target size is less than or equal to the target BAR space size, it sends a success flag (i.e., the aforementioned target information) to the application layer, instructing the application to access the target GPU's video memory through a direct mapping mechanism. If the target size is greater than the target BAR space size, it determines whether the target size is less than the target GPU's video memory size. If the target size is less than or equal to the target GPU's video memory size, it sends an out-of-BAR space flag (i.e., the aforementioned target information) to the application layer, instructing the application layer to access the target GPU's video memory through a sliding window mapping mechanism. If the target size is greater than the target GPU's video memory size, it sends an insufficient video memory flag (i.e., the aforementioned target information) to the application layer, instructing the application layer to return an error code to the requester.

[0110] Please see Figure 6 , Figure 6 A flowchart illustrating a video memory access method provided in this application embodiment. Figure 2 The video memory access method includes: S601, the application layer receives the request message.

[0111] The request message is used to request the allocation of target capacity of video memory, and this request message is sent to the application layer by the requester (i.e., a specific application scenario or specific instance). It is understood that the above request message can be referred to the relevant description in the aforementioned "S201", and will not be repeated here.

[0112] S602, in response to the request message, the application layer obtains the size of the target BAR space and the size of the target GPU's video memory.

[0113] The target BAR space is the BAR space already configured for the target GPU. The target GPU is the GPU determined based on the request message. It can be understood that the target BAR space and target GPU can be referred to the relevant descriptions in the aforementioned "S202," and will not be repeated here.

[0114] The application layer can obtain the size of the target BAR space and the target GPU's video memory size from the kernel layer. For example, obtaining the target BAR space size and target GPU's video memory size can specifically include: calling a first interface function and obtaining the resource information structure returned by the first interface function; wherein, the first field of the resource information structure carries the target BAR space size, and the second field of the resource information structure carries the target GPU's video memory size.

[0115] In this embodiment, the first interface function can be a pre-defined interface function. By calling the first interface function, the application layer can simultaneously obtain the size of the target BAR space and the size of the target GPU's video memory. This method merges the queries for two key hardware resources into a single atomic operation, which not only improves query efficiency but also ensures the consistency of resource information, providing a reliable data foundation for system resource management. Furthermore, this method has good scalability, facilitating the subsequent addition of other hardware resource information.

[0116] When the first interface function is used at the application layer, the kernel interface can also return the function execution result to the application layer. After receiving the function execution result, the application layer can perform subsequent operations, such as using the size of the target BAR space and the size of the target GPU's video memory, if the function execution result indicates that the function execution was successful. If the function execution result indicates that the function execution failed, exception handling is performed, such as re-calling the first interface function.

[0117] Furthermore, the kernel interface can obtain the target GPU's video memory size and target BAR space size during initialization. In other words, when the system includes multiple GPUs, the kernel interface can obtain the video memory size and BAR space size of each GPU during initialization. For details, please refer to the aforementioned... Figure 2 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0118] Furthermore, the aforementioned invocation of the first interface function can specifically include: invoking the first interface function based on an input / output control (IOCTL) mechanism. This IOCTL mechanism can be found in existing technologies and will not be elaborated upon here. This improves the flexibility in obtaining the size of the target BAR space and the target GPU's video memory.

[0119] S603: When the target size is less than or equal to the target BAR space size, the target GPU's video memory is accessed through a direct mapping mechanism; when the target size is greater than the target BAR space size and less than or equal to the target GPU's video memory size, the target GPU's video memory is accessed through a sliding window mapping mechanism.

[0120] The direct mapping mechanism maps the GPU's video memory completely into the BAR space, so that the video memory can be accessed through a fixed address translation relationship. For details, please refer to the aforementioned introduction, which will not be repeated here.

[0121] The sliding window mapping mechanism uses a fixed-size BAR window to dynamically remap to different regions of video memory, so as to access the entire video memory through variable address translation relationships. For details, please refer to the aforementioned introduction, which will not be repeated here.

[0122] After obtaining the size of the target BAR space and the target GPU's video memory size, the application layer can first compare the target size with the target BAR space size, or determine if the target size is smaller than the target BAR space size. If the target size is less than or equal to the target BAR space size, the application layer can access the target GPU's video memory through a direct mapping mechanism. If the target size is greater than the target BAR space size, the application layer can then compare the target size with the target GPU's video memory size, or determine if the target size is smaller than the target GPU's video memory size. If the target size is less than or equal to the target GPU's video memory size, the application layer can access the target GPU's video memory through a sliding window mapping mechanism.

[0123] In summary, in this embodiment, when the target size of the video memory to be allocated is less than or equal to the target BAR space, the video memory of the target size can be completely mapped to the target BAR space. In this case, the application layer can access the video memory of the target GPU through a direct mapping mechanism to achieve low-latency, high-bandwidth video memory access. When the target size of the video memory to be allocated is greater than the target BAR space but less than or equal to the video memory size of the target GPU, the video memory of the target GPU requested by the application layer cannot be completely mapped to the BAR space. In this case, the application layer can access the video memory of the target GPU through a sliding window mapping mechanism to ensure functional integrity. Thus, the system can adapt to the BAR space and video memory configurations of different GPUs, thereby solving the problem of mismatch between traditional single mapping strategies and heterogeneous hardware configurations.

[0124] Optionally, in conjunction with the above embodiments, the method may further include: returning an error code to the requester that initiated the request message when the target size is larger than the target BAR space size and the target size is larger than the target GPU memory size.

[0125] The requester and error code can be found in the previous section. Figure 2 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0126] In this embodiment, when the target size of the video memory to be allocated is larger than the target BAR space and larger than the target GPU's video memory size, the target GPU's video memory size cannot meet the requester's requested target size of the video memory to be allocated. In this case, the requester's request for video memory allocation fails, i.e., the application layer returns an error code to the requester. This prevents a single application from exhausting too much video memory resources, leading to system instability; and it allows the requester to be promptly informed that the request cannot be fulfilled, thus enabling the requester to adopt degradation strategies such as reducing resource requirements or using alternatives (such as system memory), improving application adaptability and user experience.

[0127] Optionally, in conjunction with the above embodiments, the method may further include configuring the target GPU's firmware with the target GPU's identification information and the target GPU's video memory size, and storing the identification information and the video memory size in the firmware storage area so that the target GPU's driver can obtain the identification information and the video memory size during initialization. For details, please refer to the foregoing. Figure 2 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0128] Furthermore, when there are multiple GPUs in the system, the firmware of each GPU can be configured with the GPU's identification information and the GPU's video memory size, and the identification information and video memory size are stored in the firmware storage area corresponding to the GPU.

[0129] Furthermore, the above method may also include: the driver module of the target GPU calling a second interface function, the input parameters of which include a device pointer and a memory pointer, the device pointer being used to indicate the target GPU to be queried; the driver module of the target GPU obtaining the identification information of the target GPU from the return value of the second interface function, and obtaining the video memory size of the target GPU from the address pointed to by the memory pointer; wherein, the second interface function obtains resource data by accessing the firmware storage area of ​​the target GPU, and obtains the identification information and video memory size of the target GPU by parsing the resource data, as detailed above. Figure 2 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0130] Furthermore, when there are multiple GPUs in the system, the driver modules of each GPU can obtain the video memory size of that GPU in the manner described above.

[0131] It is understandable that when a system includes multiple types of GPUs, including standard cards and non-standard cards (also known as custom cards), then for different types of non-standard cards, the corresponding identification information, card identification number, and video memory size can be configured on the firmware side of the non-standard card. The card identification number, identification information, and video memory size corresponding to the non-standard card can then be stored in the firmware storage area corresponding to the non-standard card. For details, please refer to the aforementioned... Figure 2 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0132] It's understandable. Figure 6 The illustrated embodiments and Figure 2 The embodiments shown are similar, except that: Figure 6 In the illustrated embodiment, the application layer obtains the size of the target BAR space and the size of the target GPU's video memory from the kernel layer, determines the size relationship between the video memory to be allocated and the target BAR space, and further determines the size relationship between the video memory to be allocated and the target GPU's video memory. Based on the determination results, the corresponding operation is performed directly. Figure 2 In the illustrated embodiment, the kernel interface obtains the size of the target BAR space and the size of the target GPU's video memory. Based on the application layer's request message, it determines the size relationship between the video memory to be allocated and the target BAR space, and further determines the size relationship between the video memory to be allocated and the target GPU's video memory. Based on the determination results, it instructs the corresponding operation of the application layer through the target information. The similarities can be referred to for mutual understanding, and will not be repeated here.

[0133] The above content describes the methods for accessing video memory. For example... Figure 7 and Figure 8 As shown, in this method, the application layer's operation mainly involves, after receiving the request message, calling a pre-packaged Member_get interface (i.e., the first interface function mentioned above) and passing a parameter pointer to the kernel space. This parameter pointer is used to receive data returned from the kernel layer. In the kernel layer, the corresponding Member_get interface receives this parameter pointer and stores the size of the target BAR space and the size of the target GPU's video memory into it. This allows the size of the target BAR space and the size of the target GPU's video memory to be passed from the kernel space to the user space. Finally, the kernel-space Member_get interface returns a function execution result (ret). This function execution result is returned to the user space via a system call, and then returned to the application layer by the user-space encapsulation function. This function execution result may indicate that the function execution was successful or failed.

[0134] When the function execution result indicates success, the application layer determines if the target size is smaller than the target BAR space size. If the target size is less than or equal to the target BAR space size, it accesses the target GPU's video memory through a direct mapping mechanism. If the target size is greater than the target BAR space size, the application layer determines if the target size is smaller than the target GPU's video memory size. If the target size is less than or equal to the target GPU's video memory size, it accesses the target GPU's video memory through a sliding window mapping mechanism. If the target size is greater than the target GPU's video memory size, it returns an error code to the requester.

[0135] Based on the same inventive concept, this application also provides a video memory access device 900. Please refer to [link to relevant documentation]. Figure 9 , Figure 9 This is a schematic diagram of a video memory access device 900 provided in an embodiment of this application. The video memory access device 900 includes a transceiver module 910 and a processing module 920. For ease of explanation, Figure 9 Only the main components of this video memory access device are shown.

[0136] The transceiver module 901 is used to perform the above. Figure 2 and Figure 6 The sending and receiving functions of the method shown are executed by the processing module 902. Figure 2 and Figure 6 The method shown includes functions other than sending and receiving.

[0137] Optionally, the transceiver module 902 may include a transmitting module ( Figure 9 (not shown in the image) and receiving module ( Figure 9 (Not shown in the image). The transmitting module implements the transmitting function of the video memory access device 900, and the receiving module implements the receiving function of the video memory access device 900.

[0138] Optionally, the video memory access device 900 may further include a storage module ( Figure 9 (Not shown in the image), this storage module stores programs or instructions. When the processing module 901 executes the program or instructions, the video memory access device 900 can perform the above-described method. Figure 2 and Figure 6 The methods shown include the functions of the application layer, kernel interface, GPU firmware, or GPU driver module.

[0139] In addition, the technical effects of the video memory access device 900 can be referenced. Figure 2 and Figure 6 The technical effects of the memory access method shown will not be elaborated here.

[0140] Please see Figure 10Based on the same inventive concept, this application also provides an electronic device 1000. Figure 10 This diagram illustrates a structural block diagram of an electronic device 1000 provided in an embodiment of this application. The electronic device 1000 includes: a transceiver 1010, a memory 1020, a communication bus 1030, and a processor 1040.

[0141] The transceiver 1010, the memory 1020, and the processor 1040 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses 1030 or signal lines. The transceiver 1010 is used to send and receive data. The memory 1020 is used to store computer programs, such as... Figure 9 The software functional module shown is the video memory access device 900. The video memory access device 900 includes at least one software functional module that can be stored in the memory 1020 in the form of software or firmware or embedded in the operating system (OS) of the electronic device 1000. The processor 1040 is used to execute executable modules stored in the memory 1020, such as the software functional module or computer program included in the video memory access device 900.

[0142] The memory 1020 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0143] The processor 1040 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), Network Processor (NP), Graphics Processing Unit (GPU), Accelerated Processing Unit (ACCU), Multimedia Application Processor (MAP), microprocessor, etc.; it can also be a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. Alternatively, the processor 1040 can also be any conventional processor.

[0144] Among them, the aforementioned electronic device 1000 includes, but is not limited to, devices based on the PCIe bus standard (i.e., PCIe devices).

[0145] This application also provides a computer-readable storage medium storing a program or instructions that, when executed, cause the above-described method to be performed.

[0146] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0147] This application also provides a computer program product comprising: a computer program or instructions that, when executed, cause the above-described method to be performed.

[0148] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0149] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0150] The above detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0151] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0152] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0153] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, laptop, server, or electronic device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0154] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for accessing video memory, characterized in that, Applied to the application layer, the method includes: Send a request message to the kernel layer, the request message being used to request unallocated video memory of the target size; Receive target information from the kernel layer; When the target information indicates that the target size is less than or equal to the size of the target base address register (BAR) space, the video memory of the target graphics processor (GPU) is accessed through a direct mapping mechanism. The direct mapping mechanism is to completely map the GPU's video memory into the BAR space so as to access the video memory through a fixed address translation relationship. When the target information indicates that the target size is greater than the target BAR space size and the target size is less than or equal to the target GPU's video memory size, the target GPU's video memory is accessed through a sliding window mapping mechanism. The sliding window mapping mechanism is to dynamically remap a fixed-size BAR window to different regions of the video memory so as to access the entire video memory through a variable address translation relationship. The target GPU is determined based on the request message, and the target BAR space is the BAR space configured for the target GPU.

2. The method according to claim 1, characterized in that, The method further includes: If the target information indicates that the target size is greater than the target BAR space size and the target size is greater than the target GPU memory size, an error code is returned to the requester who initiated the request message.

3. A method for accessing video memory, characterized in that, Applied to the kernel interface, the method includes: Receive a request message from the application layer, the request message being used to request unallocated video memory of the target size; In response to the request message, target information is sent to the application layer; Wherein, if the target size is less than or equal to the size of the target base address register (BAR) space, the target information is used to instruct the application layer to access the target GPU's video memory through a direct mapping mechanism. This direct mapping mechanism maps the GPU's video memory completely into the BAR space to access the video memory through a fixed address translation relationship. Where the target size is greater than the size of the target BAR space, and the target size is less than or equal to the size of the target GPU's video memory, the target information is used to instruct the application layer to access the target GPU's video memory through a sliding window mapping mechanism. This sliding window mapping mechanism dynamically remaps a fixed-size BAR window to different regions of the video memory to access the entire video memory through a variable address translation relationship. The target BAR space is the BAR space configured for the target GPU, and the target GPU is the GPU determined based on the request message.

4. The method according to claim 3, characterized in that, If the target size is greater than the target BAR space size and the target size is greater than the target GPU memory size, the target information is used to instruct the application layer to return an error code to the requester that initiated the request message.

5. The method according to claim 3 or 4, characterized in that, The method further includes: The memory size of the target GPU is obtained from the driver module corresponding to the target GPU by calling the first interface function.

6. A method for accessing video memory, characterized in that, Applied to the application layer, the method includes: Receive a request message, the request message being used to request the allocated video memory of the target capacity; In response to the request message, the size of the target base address register (BAR) space and the video memory size of the target graphics processor (GPU) are obtained, wherein the target BAR space is the BAR space configured for the target GPU, and the target GPU is the GPU determined based on the request message; When the target size is less than or equal to the target BAR space size, the target GPU's video memory is accessed through a direct mapping mechanism. The direct mapping mechanism maps the GPU's video memory completely into the BAR space so as to access the video memory through a fixed address translation relationship. When the target size is greater than the target BAR space size and the target size is less than or equal to the target GPU's video memory size, the target GPU's video memory is accessed through a sliding window mapping mechanism. The sliding window mapping mechanism is to dynamically remap a fixed-size BAR window to different regions of the video memory so as to access the entire video memory through a variable address translation relationship.

7. The method according to claim 6, characterized in that, The method further includes: If the target size is greater than the target BAR space size and the target size is greater than the target GPU memory size, an error code is returned to the requester who initiated the request message.

8. The method according to claim 6 or 7, characterized in that, The process of obtaining the size of the target BAR space and the size of the target GPU's video memory includes: Call the first interface function and obtain the resource information structure returned by the first interface function; wherein, the first field of the resource information structure carries the target BAR space size, and the second field of the resource information structure carries the target GPU memory size.

9. The method according to claim 8, characterized in that, The invocation of the first interface function includes: The first interface function is called based on the Input / Output Control (IOCTL) mechanism.

10. A method for accessing video memory, characterized in that, Firmware applied to a target graphics processing GPU, the method comprising: During firmware initialization of the target GPU, the identification information of the target GPU and the size of the target GPU's video memory are configured. The identification information and the video memory size are stored in the firmware storage area so that the driver of the target GPU can obtain the identification information and the video memory size during initialization.

11. A method for accessing video memory, characterized in that, A driver module applied to a target graphics processing unit (GPU), the method comprising: The second interface function is called, and the input parameters of the second interface function include a device pointer and a memory pointer, wherein the device pointer is used to indicate the target GPU to be queried; Obtain the identification information of the target GPU from the return value of the second interface function; Obtain the size of the target GPU's video memory from the address pointed to by the memory pointer; The second interface function obtains resource data by accessing the firmware storage area of ​​the target GPU, and obtains the identification information and video memory size by parsing the resource data.

12. A video memory access device, characterized in that, The apparatus includes a module for performing the method as described in any one of claims 1 to 11.

13. An electronic device, characterized in that, include: A memory and a processor, wherein the processor is connected to the memory; The memory is used to store programs; The processor is configured to invoke a program stored in the memory to perform the method as described in any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed, cause the method of any one of claims 1 to 11 to be performed.

Images